dynamic IPSEC: Holy grail sighted
I have a router/ FreeBSd with a network on the other side with a Dynamic IP. At the other end is a static IP router/ FreeBsd box. I was using a manually keyed encryption, now I have the racoon to do the key negotiation. I can change the static gif0 interfaces at the VPn dynamic router using the dhclient-exit-loop. But what about the server gif0 interface. The gif0 tunnel attributes want the VPN's router address, and I would need an exit-hook from racoon to set this up, more then just setting the SPD keys. Any idea where to latch that from. I'v though about watchdogs (check the SPD keys), but is there a better way. Michael Kreykenbohm ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dynamic IPSEC: Holy grail sighted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't some of the attachments you intended to send (raccoon.conf? perl script?) didn't get through the list. I would be very interested to read those, if you don't mind sharing them... Thanks, A. - -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker http://www.ad-mad.co.uk/quotes/freespeech.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QN3FttcWHAnWiGcRAja5AJwMWEMcfsicge5wcDWDFKzr1KM6XgCeOKCt hYopeXiF05aDncMzGA1ecBQ= =zeyM -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dynamic IPSEC: Holy grail sighted
Hi, On Mon, 18 Aug 2003, The Anarcat wrote: I don't some of the attachments you intended to send (raccoon.conf? perl script?) didn't get through the list. I would be very interested to read those, if you don't mind sharing them... we run following scripts 1. run lookup-peers.sh from cron every 3 minutes to resolve the peers listed in /usr/local/etc/peers.in 2. diff the results to the results fo the previous run and run update-ipsec.sh if changed to generate new ipsec.conf ipsec.conf.m4 using the m4 macro processor ( yes we use m4 for just about everything ;-) ) 3. update-ipsec.sh installs the new policy but purposely keeps the already handshaked associations in place so as not to hang connections unnecessarily you also need something else to update your dnsdns setup. This is left as an excercise to the reader. The following scripts are freshly pasted out of our live setup and somewhat obfuscated so there might still be something missing. Especially the ipsec.conf.m4 will need adapting to your setup and to the specific host in question. Greetings Christian --- peers.in --- peera peera.yourfavourite-dyndns-provider.com peerb peerb.yourfavourite-dyndns-provider.com peerc peerc.yourfavourite-dyndns-provider.com --- peers.in --- --- lookup-peers.sh #!/bin/sh SRC=/usr/local/etc/peers.in DST=/tmp/peers.m4 TMP=/tmp/peers.tmp DYNINT=tun0 AWK=/usr/bin/awk IFCONFIG=/sbin/ifconfig HOST=/usr/local/bin/host if [ -f $TMP ]; then rm $TMP fi MYIP=`$IFCONFIG $DYNINT | $AWK '/inet /{ print $2 }'` echo define(\`MYIP',\`$MYIP')dnl $TMP while read name host; do addr=`$HOST -W 3 $host | awk '/address/{ print $4 }` if [ -n $addr ]; then echo define(\`$name',\`$addr')dnl $TMP fi done $SRC if [ ! -f $DST ]; then touch $DST fi diff $DST $TMP 2 /dev/null /dev/null if [ $? -ne 0 ]; then # ip addresses of peers changed mv $TMP $DST # trigger actions here /usr/local/libexec/update-ipsec.sh fi --- lookup-peers.sh --- update-ipsec.sh --- #!/bin/sh /usr/bin/m4 /etc/ipsec.conf.m4 /etc/ipsec.conf /usr/sbin/setkey -f /etc/ipsec.conf --- update-ipsec.sh --- --- ipsec.conf.m4 --- (on host1) define(`SRCNET1',`192.168.1.0/24') define(`DSTNET2',`192.168.2.0/24') define(`DSTNET3',`192.168.3.0/24') # flush policy spdflush; # vpn tunnel from hosta to hostb spdadd SRCNET1 DSTNET2 any -P out ipsec esp/tunnel/MYIP-hostb/require ; spdadd DSTNET2 SRCNET1 any -P in ipsec esp/tunnel/hostb-MYIP/require ; # vpn tunnel from hosta to hostc spdadd SRCNET1 DSTNET3 any -P out ipsec esp/tunnel/MYIP-hostc/require ; spdadd DSTNET3 SRCNET1 any -P in ipsec esp/tunnel/hostc-MYIP/require ; --- ipsec.conf.m4 --- Greetings Christian -- CK Software GmbH Christian Kratzer, Schwarzwaldstr. 31, 71131 Jettingen Email: [EMAIL PROTECTED] Phone: +49 7452 889-135Open Software Solutions, Network Security Fax: +49 7452 889-136FreeBSD spoken here! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dynamic IPSEC: Holy grail sighted
Sorry about the attachments. I did a repost on -questions immed after orig posting which includes attachments. Kent I don't some of the attachments you intended to send (raccoon.conf? perl script?) didn't get through the list. I would be very interested to read those, if you don't mind sharing them... Thanks, A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
dynamic IPSEC: Holy grail sighted
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 # $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; } ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
dynamic IPSEC: Holy grail sighted
[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 [EMAIL PROTECTED] . /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 EOF #!/usr/bin/perl sub get_addr { my \$addr = gethostbyname shift (@_); my (\$a,\$b,\$c,\$d) = unpack ('C4',\$addr); return sprintf %d.%d.%d.%d,\$a,\$b,\$c,\$d; } \$SP = get_addr ($SERVER_PUBLIC); \$SV = get_addr ($SERVER_PRIVATE); \$MP = get_addr ($MOBILE_PUBLIC); \$MV = get_addr ($MOBILE_PRIVATE); if ($MOBILE_NETSIZE) { \$SV = sprintf %s/%d, \$SV, $MOBILE_NETSIZE; } system setkey -FP; system setkey -F; ; dont know why I can't pipe to process. Oh well. ;open (SETKEY, | /usr/sbin/setkey -c); open (SETKEY, /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. # #