From owner-freebsd-questions@FreeBSD.ORG Sat Aug 16 02:47:35 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DF9337B401 for ; Sat, 16 Aug 2003 02:47:35 -0700 (PDT) Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5747B43FBF for ; Sat, 16 Aug 2003 02:47:34 -0700 (PDT) (envelope-from kent.hauser@verizon.net) Received: from hnl ([4.3.107.135]) by pop016.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030816094733.ZJXL10125.pop016.verizon.net@hnl>; Sat, 16 Aug 2003 04:47:33 -0500 From: Kent Hauser To: Christian Kratzer Date: Fri, 15 Aug 2003 23:47:31 -1000 User-Agent: KMail/1.5.3 References: <200308110011.58180.kent.hauser@verizon.net> <20030811141505.M85450@majakka.cksoft.de> In-Reply-To: <20030811141505.M85450@majakka.cksoft.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308152347.31837.kent.hauser@verizon.net> X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [4.3.107.135] at Sat, 16 Aug 2003 04:47:32 -0500 cc: questions@freebsd.org cc: Mike Tancsa Subject: dynamic IPSEC: Holy grail sighted X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 09:47:35 -0000 [This is a repost as attachments dont seem to work to the list] Hi, 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 ===== /etc/dhlient-exit-hooks #!/bin/sh # script dhclient-exit-hooks 8/14/03 kent.hauser@verizon.net . /etc/rc.conf #new_ip_address="192.168.3.50" #export new_ip_address export SERVER_PUBLIC="my-server.dyndns.org" export SERVER_PRIVATE="my-server" export MOBILE_PRIVATE="$hostname" export MOBILE_PUBLIC="$new_ip_address" export MOBILE_NETSIZE=24 perl -w </tmp/spd"); printf SETKEY "spdadd %s %s any -P out ", \$MV, \$SV; printf SETKEY "ipsec esp/tunnel/%s-%s/use;\n", \$MP,\$SP; printf SETKEY "spdadd %s %s any -P in ", \$SV, \$MV; printf SETKEY "ipsec esp/tunnel/%s-%s/use;\n", \$SP, \$MP; close SETKEY; exit 0; __END__ EOF /usr/sbin/setkey -f /tmp/spd exit 0 ===== /etc/dhclient.conf # $FreeBSD: src/etc/dhclient.conf,v 1.2.2.1 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"; fixed-address 192.168.101.50; } ===== remote.diffs --- racoon.conf.dist Wed Aug 13 19:04:24 2003 +++ remote.clean Fri Aug 15 22:45:35 2003 @@ -56,12 +56,12 @@ situation identity_only; #my_identifier address; - my_identifier user_fqdn "sakane@kame.net"; - peers_identifier user_fqdn "sakane@kame.net"; + my_identifier user_fqdn "kent@kent.tfd.com" + peers_identifier user_fqdn "kent@tfd.com"; #certificate_type x509 "mycert" "mypriv"; nonce_size 16; - lifetime time 1 min; # sec,min,hour + lifetime time 60 min; # sec,min,hour initial_contact on; support_mip6 on; proposal_check obey; # obey, strict or claim @@ -99,7 +99,7 @@ sainfo anonymous { pfs_group 1; - lifetime time 30 sec; + lifetime time 30 min; encryption_algorithm 3des ; authentication_algorithm hmac_sha1; compression_algorithm deflate ; ======= server.diffs --- racoon.conf.dist Wed Aug 13 19:04:24 2003 +++ racoon.clean Fri Aug 15 22:40:33 2003 @@ -56,15 +56,17 @@ situation identity_only; #my_identifier address; - my_identifier user_fqdn "sakane@kame.net"; - peers_identifier user_fqdn "sakane@kame.net"; + my_identifier user_fqdn "kent@tfd.com" + #peers_identifier user_fqdn "sakane@kame.net"; #certificate_type x509 "mycert" "mypriv"; nonce_size 16; - lifetime time 1 min; # sec,min,hour - initial_contact on; - support_mip6 on; - proposal_check obey; # obey, strict or claim + lifetime time 60 min; # sec,min,hour + initial_contact off; + passive on; + generate_policy on; +# support_mip6 on; +# proposal_check obey; # obey, strict or claim proposal { encryption_algorithm 3des; @@ -99,7 +101,7 @@ sainfo anonymous { pfs_group 1; - lifetime time 30 sec; + lifetime time 30 min; encryption_algorithm 3des ; authentication_algorithm hmac_sha1; compression_algorithm deflate ; ====