IPSEC VPN between Ubuntu and Juniper SSG5

I managed to connect a Ubuntu 12.04 to the corporate network through a SSG5. My environment:

SSG5:

ScreenOS 6.2
public IP: 200.1.1.1
DMZ: 192.1.1.0/24, IP 192.1.1.1

Considerations & some conclusions:

NAT-Traversal required, and it works
Site-to-site (Ubuntu identified by static IP) and dial-up (identified by an email) both works
Policy based - network is simple, no needs for a tunnel interface; route based not tried but should work
IKE
- Ubuntu's identification:
  - Main mode + static IP ID: desired as it protects ID - that means static IP ID for Ubuntu desired. Although Ubuntu get dynamic private IP, it does not restart often so not much administrative burden;
  - Aggressive mode + dial-up OK - disclose ID not a big problem and this avoids the issue of Ubuntu getting dynamic IP
  - Both the above works and will give details below
- Authentication:
  - pre_shared_key: simple and works;
  - certificate: tried but I cannot get it working. racoon always complains "ERROR: Invalid CR type 0"; I think this is a ScreenOS problem since (1) I saw certificate request type 0 from ScreenOS (tcpdump) and (2) confirmed by someone else (see reference). certificate authentication is far more complex than pre_shared_key and more places could go wrong

Important Note:

On Ubuntu 14.04, ssh through IPSEC freezes when command outputs longer text. Solution is to adjust MTU of the Ubuntu outgoing interface to lower. In my case 1300.

See http://serverfault.com/questions/472902/ssh-session-through-an-ipsec-vpn-tunnel-freezes-when-command-outputs-longer-text

Commands (effect does not survive reboot):

sudo ip link set wlan0 mtu 1300

ip a s

References:

Someone's real experience, which I followed but simplified his configuration to only what is needed:

http://www.bluetrait.com/archive/2006/09/27/racoon-to-netscreen-vpn-dialup/

In fact this one is clearer:

http://www.prolixium.com/netscreenlinux

ScreenOS Reference Guide Volume 5: VPN

A very detailed guide to connect an OpenBSD to ScreenOS. Although OpenBSD uses a different IPSEC implementation, this Guide helps if I want to later work on a certificate authentication solution. It tells, at least, (1) Screen require CRL to authenticate (2) details for making certificates that work with ScreenOS (3) confirmation of the ScreenOS certificate request type 0 problem that I encountered

http://dl.packetstormsecurity.net/defcon10/dc10-eldridge-mobilevpn/obsd_ns_vpn.html

Man pages:

racoon.conf: http://netbsd.gw.com/cgi-bin/man-cgi?racoon.conf+5+NetBSD-current

setkey: http://www.freebsd.org/cgi/man.cgi?query=setkey&sektion=8

Main mode, Site-to-Site (identification by IP address) Configurations

Ubuntu:

an Amazon EC2 instance
behind NAT
runs ipsec-tools & racoon
private IP : 10.1.1.1
public IP (elastic IP): 180.1.1.1

SSG5 Set Up

Refer to ScreenOS manual "Site-to-Site VPN Configurations / Policy-Based Site-to-Site VPN, AutoKey IKE", the steps are numbered according to the manual but some configurations changed to make things work:

1. Interfaces: set up DMZ and Untrust interfaces and addresses, done

2. Addresses: set up named addresses for ease of reference, done

3. VPNs -> AutoKey Advanced -> Gateway -> new

This is creating IKE phase 1 set up
Name: x_gateway
Version: IKEv1
Remote gateway: Static IP Address / 180.1.1.1
- [comment] this corresponds to how SSG finds the gateway and identifies the remote peer; setting to Static IP Address, initiator should be from the remote ip and also the "my_identifier address" directive in racoon.conf set up should match;
- [comment] if initiator's IP does not match this configured address, log shows "Rejected an IKE packet on ethernet0/0 from xxx.xxx.xxx.xxx:500 to xxx.xxx.xxx.xxx:500 with cookies xxxxxxxxxxxxxxx and xxxxxxxxxxxx because There were no acceptable Phase 1 proposals."
- [comment] if initiator's IP match this configured address, but the address in "my_identifier address" directive in racoon.conf does not match up, log shows "Rejected an IKE packet on ethernet0/0 from xxx.xxx.xxx.xxx:4500 to xxx.xxx.xxx.xxx:4500 with cookies xxxxxxxxxxxxx and xxxxxxxxxxxxxxxx because Phase-1: no user configuration was found for the received IKE ID type: IP Address,1."
Advanced:
- Pre-shared-key: anything-you-want
- Security level: custom, pre-g2-3des-sha
- Mode: main
Enable NAT Traversal: select

VPNs -> AutoKey IKE -> new

This is creating phase 2 settings
Name: x_vpn
Remote gateway: predefined, x_gateway
Advanced:
- Security level: standard (refer to manual, standard means g2-esp-3des-sha and g2-esp-aes128-sha)
- Proxy ID:
  - Local: 192.1.1.0/24
  - Remote: 10.1.1.1/32
  - Service: any
  - [comment] it seems "proxy ID" is what Juniper calls it and I'm not quite sure what it really is; anyway, it's used in phase2 to identify tunnel, as multiple tunnels may exist between two ends; without manual configuration, proxy id could simply be a combination of local address/remote address/service;
  - [comment] without this proxy ID setting the connection will fail and ScreenOS complains "info Rejected an IKE packet on ethernet0/0 from 180.1.1.1:4500 to 200.1.1.1:4500 with cookies xxxxxxxxxx and xxxxxxxxxx because The peer sent a proxy ID that did not match the one in the SA config." and "IKE 180.1.1.1 Phase 2 msg ID xxxxx: Negotiations have failed."
  - [comment] guess what happened here: proxy ID is something in the standard but can be implemented differently; I cannot find a racoon configuration directive to set it; then racoon simply used its end IP (private) and sent over NAT to ScreenOS; ScreenOS identify Ubuntu with its public IP; so the mismatch and requirement of this manual setting;
  - References about Proxy ID:
    - http://www.fir3net.com/Netscreen/netscreen-proxy-ids.html
    - http://kb.juniper.net/InfoCenter/index?page=content&id=KB16008

4. Route: just setting default gateway in normal way, routing for VPN is not required in this policy based setting; done already

5. Policy:

name: any-name-you-like
source / dest addr: set up as needed (note: use source / destination of the the encapsulated traffic, i.e. private addresses)
service: as-you-need, or any
action: Tunnel
Tunnel: x_gateway
Modify matching bidirectional VPN policy: select
Position at top: select

Ubuntu Set Up

(1) Install necessary software

sudo apt-get install racoon ipsec-tools

On racoon configuration screen, select "direct" as advised.

(2) on EC2 management, set up security group rule to open UDP port 500 and 4500

(3) set up pre-shared-key, edit /etc/racoon/psk.txt, add the key (identical with the one given to server)

202.8.93.18    anything-you-want

(4) Set up security policy, edit /etc/ipsec-tools.conf as follows

flush;

spdflush;

spdadd 10.1.1.1/32 192.1.1.0/24 any -P out ipsec

     esp/tunnel/10.1.1.1-200.1.1.1/require;

spdadd 192.1.1.0/24 10.1.1.1/32 any -P in ipsec

     esp/tunnel/200.1.1.1-10.1.1.1/require;

This sets up secure policy for traffics, i.e. for incoming traffic checking if policy is conformed and for outgoing traffic act according to policy;

First set of address / range pairs is source / destination selector to match the packet to be inspected. Note addresses of the private (encapsulated) communication is used.

Then the policy part also include source/destination addresses of the end points of the tunnel. In this case, the private IP of Ubuntu (which behind NAT) is used since Ubuntu sees this as the end point. On the other end, public IP is used as SSG5 sits on Internet.

Refer to setkey manual for further details.

Execute the file:

sudo /usr/sbin/setkey -f /etc/ipsec-tools.conf

(5) Set up racoon, edit /etc/racoon/racoon.conf as follows (note this is for fixed IP!)

log notify;

path pre_shared_key "/etc/racoon/psk.txt";

path certificate "/etc/racoon/certs";

remote 200.1.1.1{

        exchange_mode main;

        nat_traversal on;

        my_identifier address 180.1.1.1;

        proposal {

                encryption_algorithm 3des;

                hash_algorithm sha1;

                authentication_method pre_shared_key;

                dh_group modp1024;

sainfo address 10.1.1.1/32 any address 192.1.1.0/24 any {

        pfs_group modp1024;

        encryption_algorithm 3des;

        authentication_algorithm hmac_sha1;

        compression_algorithm deflate;

The "remote" clause is for IKE phase 1, gateway identified by remote address, note the exchange mode, identification and proposal needs to match the settings on ScreenOS. NAT traversal should be on. "dh_group modp1024" corresponds to DH group "g2".

The "sainfo" clause is for phase 2, also the parameters need to match the ScreenOS phase 2 setting ("Standard" in this example).

Refer to racoon.conf manual page for further details.

Aggressive Mode, Dial-up Configurations

SSG5 Set Up

Refer to ScreenOS manual "Dial-up VPN / Dial-up / Policy based dial-up VPN, AutoKey IKE".

1. Interfaces: set up DMZ and Untrust interfaces and addresses, done

2. Addresses: set up named addresses for ease of reference, done

3. Objects -> Users -> Local -> New

Name: user_name
Status: enable
IKE User: select
Simple Identification: select
IKE ID type: U-FQDN
IKE Identification: any.email@that.you.like

4. VPNs -> AutoKey Advanced -> Gateway -> new

This is creating IKE phase 1 set up
Name: x_gateway
Version: IKEv1
Remote gateway: Dial-up user
User: select user_name
Advanced:
- Pre-shared-key: anything-you-want
- Security level: custom, pre-g2-3des-sha
- Mode: aggressive
Enable NAT Traversal: select

VPNs -> AutoKey IKE -> new

This is creating phase 2 settings
Name: x_vpn
Remote gateway: predefined, x_gateway
Advanced (in fact nothing changed here, just check to be sure):
- Security level: standard (refer to manual, standard means g2-esp-3des-sha and g2-esp-aes128-sha)

4. Route: just setting default gateway in normal way, routing for VPN is not required in this policy based setting; done already

5. Policy (untrust -> DMZ):

name: any-name-you-like
source: Dial-up VPN
destination: 192.1.1.0/24
- this is important, and if change to "any" will no longer work and ScreenOS complaints no policy matches the proxy ID
service: as-you-need, or any
action: Tunnel
Tunnel: x_gateway
Modify matching bidirectional VPN policy: not select
Position at top: select

Ubuntu Set Up

(1) - (4) : see above

Note: although default psk.txt has user fqdn sample, still the IP address designation works... not the user fqdn

(5) Set up racoon, edit /etc/racoon/racoon.conf as follows

Note: usage of "anonymous" for one or both addresses. Since I'm using dynamically assigned addresses it's convenient for me to use it for at least source address.

log notify;

path pre_shared_key "/etc/racoon/psk.txt";

path certificate "/etc/racoon/certs";

remote 200.1.1.1{

        exchange_mode aggressive;

        nat_traversal on;

        my_identifier user_fqdn "any.email@that.you.like";

        proposal {

                encryption_algorithm 3des;

                hash_algorithm sha1;

                authentication_method pre_shared_key;

                dh_group modp1024;

sainfo anonymous address 192.1.1.0/24 any {

        pfs_group modp1024;

        encryption_algorithm 3des;

        authentication_algorithm hmac_sha1;

        compression_algorithm deflate;

A simple script to deal with dynamic IP

Someone contributed some scripts for dealing with this:

http://nhaggin.freeshell.org/wireless-vpn-howto/ar01s06.html

Test and Start Up

Start racoon in foreground with command "sudo /usr/sbin/racoon -F -f /etc/racoon/racoon.conf"; now ping the remote gateway "ping 192.1.1.1" and then another machine in the remote LAN.

If things don't work, check

output from racoon; if necessary, change debug level to "debug2" in racoon.conf ("log debug2")
event log on ScreenOS
tcpdump, see what's happening on the wire (with -v or -vv for more information, with "port 500" to limit on racoon)
first try to find which section is wrong: phase 1? phase 2? policy?

If foreground testing is successful, start the daemon.

sudo service racoon start

If start fail, check if another racoon process is running and "killall racoon" if it exists.

Google Sites

Report abuse