From owner-freebsd-security@FreeBSD.ORG Sat Aug 16 02:29:21 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 388E537B401; Sat, 16 Aug 2003 02:29:21 -0700 (PDT) Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1975943F85; Sat, 16 Aug 2003 02:29:20 -0700 (PDT) (envelope-from kent.hauser@verizon.net) Received: from hnl ([4.3.107.135]) by out003.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030816092918.XGGI29617.out003.verizon.net@hnl>; Sat, 16 Aug 2003 04:29:18 -0500 From: Kent Hauser To: Christian Kratzer Date: Fri, 15 Aug 2003 23:29:17 -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: Multipart/Mixed; boundary="Boundary-00=_tlfP/ZcdoJePGyf" Message-Id: <200308152329.17393.kent.hauser@verizon.net> X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [4.3.107.135] at Sat, 16 Aug 2003 04:29:18 -0500 X-Mailman-Approved-At: Mon, 18 Aug 2003 07:00:07 -0700 X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: security@freebsd.org cc: questions@freebsd.org Subject: dynamic IPSEC: Holy grail sighted X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2003 09:29:21 -0000 --Boundary-00=_tlfP/ZcdoJePGyf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --Boundary-00=_tlfP/ZcdoJePGyf Content-Type: text/plain; charset="iso-8859-1"; name="dhclient.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="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; } --Boundary-00=_tlfP/ZcdoJePGyf--