Warning Livedoc is no longer being updated and will be deprecated shortly. Please refer to https://documentation.tjhsst.edu.

IPSec VPN

From Livedoc - The Documentation Repository
Revision as of 21:43, 17 July 2008 by William Yang (talk | contribs) (Network details: Added sample Sun Ray server IP.)
Jump to: navigation, search

The primary Systems Lab VPN uses OpenVPN. An IPSec VPN server was set up to allow the use of the Sun Ray 2 series built-in VPN client so users can easily connect from home (in a roadwarrior configuration where we do not know the IP of the remote host). In addition, the VPN server is neither the subnet router nor the border router/internet gateway. It should be noted that connecting to the IPSec VPN from within the primary subnet and trying to access an address on the same primary subnet will not work. Chances are iptables can be configured to make this work, but this is absolutely unnecessary. If you are on the primary subnet, you should be using a direct connection to the Sun Ray servers.

Requirements

The Sun Ray VPN client was designed to be used with a Cisco EasyVPN (or sometimes called EzVPN) server. While there is no documented way to use any other VPN server, we have been able to set up a configuration which is compatible as EasyVPN is standards-compliant. The VPN server requires the following features:

  • Pre-shared key authentication
  • Aggressive mode connection
  • XAUTH
  • 3DES or AES encryption
  • MD5 or SHA1 hash algorithm
  • Mode config

Solaris IPSec currently does not support all of these features. The two Linux VPN servers identified as supporting these features are OpenSWAN and Racoon. However, the OpenSWAN keying daemon attempts to negotiate XAUTH after initiating IKE phase 2 negotiations, whereas the specification calls for XAUTH after completing IKE phase 1 but before beginning IKE phase 2. The VPN server was implemented on Debian lenny (etch does not contain a new enough racoon and/or ipsec-tools to support the above listed features) using ipsec-tools and racoon versions 0.7.2-1.

Network details

  • 198.38.16.0/21 is the primary internal subnet.
  • 1.2.3.4 will be the public IP address of the remote Sun Ray (if the actual Sun Ray is behind a NAT, then 1.2.3.4 will be the public IP address of the NAT router).
  • 198.38.16.154 is the IPSec VPN service IP.
  • 192.168.22.0/24 is the pool of addresses we've chosen to be assigned to connecting remote devices to present to the internal network.
  • 198.38.17.59 is a Sun Ray server.

Configuring the VPN server

  1. Install ipsec-tools and racoon.
  2. Enable IP forwarding.
    1. echo 1 >> /proc/sys/net/ipv4/ip4_forward
    2. edit /etc/sysctl.conf so that forwarding is enabled at boot.
  3. Set up your pre-shared key file (see "/etc/racoon/psk.txt" below). We use e-mail address for the PSK identifier, but should also be able to use non-punctuated words.
  4. Configure PAM for the racoon service, or just allow it to fall back on the "other" service.
  5. Set up the racoon configuration file (see "/etc/racoon/racoon.conf" below).
  6. Start racoon (/etc/init.d/racoon start).


Sample configuration files:

/etc/racoon/psk.txt

#groupid            groupkey
wyang@tjhsst.edu    secretpsk

/etc/racoon/racoon.conf

#Below line is not required for Sun Ray VPN to work.
path certificate "/etc/ssl/certs";
path pre_shared_key "/etc/racoon/psk.txt";

#This section restricts listening to the service IP; not strictly necessary.
listen {
	isakmp 198.38.16.154;
	isakmp_natt 198.38.16.154 [4500];
}

remote anonymous {
	exchange_mode aggressive;
	passive on;
	generate_policy on;
	nat_traversal on;
	ike_frag on;
	proposal {
		encryption_algorithm aes;
		hash_algorithm md5;
		authentication_method xauth_psk_server;
		dh_group 2;
	}
}

sainfo anonymous {
	encryption_algorithm aes;
	authentication_algorithm hmac_sha1;
	compression_algorithm deflate;
}

mode_cfg {
	network4 192.168.22.1;
	pool_size 254;
	#Below line is not required for Sun Ray VPN to work.
	split_network include 198.38.16.0/21;
	auth_source pam;
}


Logging for racoon occurs in /var/log/syslog. This is what a successful connection looks like:

Jul 17 20:09:10 vpnserver racoon: INFO: respond new phase 1 negotiation: 198.38.16.154[500]<=>1.2.3.4[500]
Jul 17 20:09:10 vpnserver racoon: INFO: begin Aggressive mode.
Jul 17 20:09:10 vpnserver racoon: INFO: received Vendor ID: RFC 3947
Jul 17 20:09:10 vpnserver racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
Jul 17 20:09:10 vpnserver racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jul 17 20:09:10 vpnserver racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Jul 17 20:09:10 vpnserver racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Jul 17 20:09:10 vpnserver racoon: INFO: received Vendor ID: CISCO-UNITY
Jul 17 20:09:10 vpnserver racoon: INFO: Selected NAT-T version: RFC 3947
Jul 17 20:09:10 vpnserver racoon: INFO: Adding remote and local NAT-D payloads.
Jul 17 20:09:10 vpnserver racoon: INFO: Hashing 1.2.3.4[500] with algo #1
Jul 17 20:09:10 vpnserver racoon: INFO: Hashing 198.38.16.154[500] with algo #1
Jul 17 20:09:10 vpnserver racoon: INFO: Adding xauth VID payload.
Jul 17 20:09:10 vpnserver racoon: INFO: NAT-T: ports changed to: 1.2.3.4[50341]<->198.38.16.154[4500]
Jul 17 20:09:10 vpnserver racoon: INFO: Hashing 198.38.16.154[4500] with algo #1
Jul 17 20:09:10 vpnserver racoon: INFO: NAT-D payload #0 verified
Jul 17 20:09:10 vpnserver racoon: INFO: Hashing 1.2.3.4[50341] with algo #1
Jul 17 20:09:10 vpnserver racoon: INFO: NAT-D payload #1 doesn't match
Jul 17 20:09:10 vpnserver racoon: WARNING: ignore INITIAL-CONTACT notification, because it is only accepted after phase1.
Jul 17 20:09:10 vpnserver racoon: INFO: NAT detected: PEER
Jul 17 20:09:10 vpnserver racoon: INFO: Sending Xauth request
Jul 17 20:09:10 vpnserver racoon: INFO: ISAKMP-SA established 198.38.16.154[4500]-1.2.3.4[50341] spi:dd210acdb6499143:ba2c78cce1c8f439
Jul 17 20:09:11 vpnserver racoon: INFO: Using port 0
Jul 17 20:09:11 vpnserver racoon: INFO: login succeeded for user "wyang"

At this point, the VPN status on the Sun Ray should read "PH1 agg I est" indication completion of IKE phase 1. After a brief pause, the Sun Ray will begin IKE phase 2 negotiation "PH2 quick I msg":

Jul 17 20:09:20 vpnserver racoon: INFO: respond new phase 2 negotiation: 198.38.16.154[4500]<=>1.2.3.4[50341]
Jul 17 20:09:20 vpnserver racoon: INFO: no policy found, try to generate the policy : 192.168.22.1/32[0] 0.0.0.0/0[0] proto=any dir=in
Jul 17 20:09:20 vpnserver racoon: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
Jul 17 20:09:20 vpnserver racoon: INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
Jul 17 20:09:21 vpnserver racoon: INFO: IPsec-SA established: ESP/Tunnel 1.2.3.4[50341]->198.38.16.154[4500] spi=25604673(0x186b241)
Jul 17 20:09:21 vpnserver racoon: INFO: IPsec-SA established: ESP/Tunnel 198.38.16.154[4500]->1.2.3.4[50341] spi=12811916(0xc37e8c)
Jul 17 20:09:21 vpnserver racoon: ERROR: such policy does not already exist: "192.168.22.1/32[0] 0.0.0.0/0[0] proto=any dir=in"
Jul 17 20:09:21 vpnserver racoon: ERROR: such policy does not already exist: "192.168.22.1/32[0] 0.0.0.0/0[0] proto=any dir=fwd"
Jul 17 20:09:21 vpnserver racoon: ERROR: such policy does not already exist: "0.0.0.0/0[0] 192.168.22.1/32[0] proto=any dir=out"

The last three messages are not actually errors. They simply indicate that there was no predefined policy. After IKE phase 2 the Sun Ray should briefly read "PH2 quick I est" before attempting to connect to the Sun Ray server.

Configuring routing

Packets coming from VPN clients will originate from 192.168.22.0/24. While the Sun Ray will be able to send packets to other systems on the network, it will not be able to receive replies unless the appropriate routes are set up as only the VPN server knows where 192.168.22.0/24 actually is. Since our primary subnet has a Cisco IOS switch/router, we simply access our switch and add the following route:

ip route 192.168.22.0 255.255.255.0 198.38.16.154

If you don't have a router on the subnet you want the Sun Rays to access, you will need to add a route to each Sun Ray server. For example, if we did not have a central router on our subnet (assuming that somehow the Sun Ray is still able to connect to the VPN server), we would run this command on each Sun Ray server:

route add 192.168.22.0/24 198.38.16.154

Configuring the Sun Ray client

You will first need to load the client with a GUI firmware version. The steps to do that will not be covered here.

  1. Access the menu by pressing Stop-M or Stop-S. On a non-Sun keyboard, Ctrl-Break can be used in place of Stop (so Ctrl-Break-M).
  2. Under "Servers", enter the IP of one of your Sun Ray servers (198.38.17.59). Broadcasting for a Sun Ray server will not work over the VPN tunnel. Firmware and Log Host may be left blank. Save change and exit to the main menu.
  3. Under "VPN/IPsec":
    1. Set enable to on.
    2. Set peer to the VPN server (198.38.16.154).
    3. Set group to the groupid that you set in the psk.txt file on the VPN server (wyang@tjhsst.edu).
    4. Set group key as indicated in the psk.txt file (secretpsk).
    5. Set username and password to a user that can succesfully authenticate via PAM.
    6. Save changes and return to the main menu.
  4. Exit the main menu. The Sun Ray should now power cycle and begin attempting to connect to your VPN server.

Byline

This document was authored by 2006-08 Sun Technology Coordinator William Yang. Special thanks to Lee Burton and Brandon Vargo for their technical advice, and also to Stephen (Trey) Repetski and Matt Green for their help with testing.