dynamic IPSEC: Holy grail sighted

Kent Hauser kent.hauser at verizon.net
Sat Aug 16 02:29:21 PDT 2003


Thanks to some pointers from Christian Kratzer, I am now able to join the 
office VPN from a random WiFi hotspot. With the configuration files changes 
detailed below, from a public WiFi hotspot I can now use this 3 step 
procedure to login to the office VPN.

1) While at hotspot, boot up my -STABLE laptop.
2) Insert wireless card.
3) "rsh server"

This procedure works for a DHCP assigned private address translated by NAT at 
the  hotspot to an unknown public address. The office VPN server is also 
behind a NAT firewall & uses private network addresses with a *dynamically* 
assigned public address. In other words, it's about as a complicated as you 
can get (I think).

Three pieces of software must be configured for this to work. First "racoon" 
is used to exchange keys and security policies. Second, "DHCP" is configured 
to install security policies & alias the remote's interface with the remote's 
VPN address. Finally, the office router is setup to use DDNS (see dyndns.org) 
so that the office dynamic IP address can be found from a  fixed DNS name.

First racoon configuration. The office router must be programmed to pass port 
500 to the server for racoon negotiation. The office server is set to 
"listen" and "generate policy". This means that the policy proposed by the 
remote is inserted in the server's tables. There is a question of trust 
involved here I will not address. Also, my example uses "shared private 
keys", but there are plenty of examples of cert-based racoon, etc. The mods 
for my remote racoon conf are merely timers.

Second, DHCP on the remote is configured using "/etc/dhcp-exit-hooks" and 
"/etc/dhcp.conf". The file  "/etc/dhcp-exit-hooks" is executed by DHCP 
whenever an address is assigned. My "dhcp-exit-hooks" script (below) is a 
poorly written combination "perl" & "sh" script which translated DNS names to 
numbers & creates a security policy which is installed in the kernel by 
"setkey". I did the perl part in perl so that I could translate DNS names to 
numbers for setkey (see above: my server public address has static name but 
dynamic number). The "server" definitions at the head of the script should 
probably go in "/etc/rc.conf" in a production environment.

Finally, DHCP is also configured to alias the private VPN address on the WiFi 
interface. This causes the kernel to use the correct source address on VPN 
packets. In a production environment, the "dhcp-exit-hooks" script should 
probably set up a GIF interface for this purpose to eliminate the need for 
the "dhcp.conf" file. 

After all this is done, "setkey -PD" on the remote shows packets from the 
remote's VPN address to the VPN network travelling thru a tunnel from the 
WiFi dynamic address to the office's public address. A "setkey -PD" on the 
server show packets from the VPN network to the remote passing thru a tunnel 
from the server's private address to the WiFi hotspot's public address 
(obviously racoon magic). AH & ESP are negotiated. I haven't checked if the 
server sets up a proxy arp for the remote -- but this is standard VPN fare.

One final thing. Everything's screwed up if the WiFi hotspot chooses the same 
private network address as the office VPN. FWIW, I would recommend VPNs use 
the reserved class-B addresses (172.16->171.31) instead of the more common 
192.168 & 10 (both of which I've seen in hotspots & hotels). I've never seen 
an address in the Class-B range assigned by a public server.

That's it. Comments appreciated. And if anyone knows perl & wants to clean up 
my mess, pls send me a copy.

Cheers. Kent
-------------- next part --------------
# $FreeBSD: src/etc/dhclient.conf,v 2001/12/14 11:44:31 rwatson Exp $
#	This file is required by the ISC DHCP client.
#	See ``man 5 dhclient.conf'' for details.
#	In most cases an empty file is sufficient for most people as the
#	defaults are usually fine.
alias {
	interface "wi0";

More information about the freebsd-questions mailing list