dynamic IPSEC

[Kent Hauser]

Hi Mike,

Had any progress? I've also by stymied for a clean solution. Previously, I
used a simple SED script from executed from "/etc/ppp/ppp.linkup" to edit a
"setkeys" script which then negotiated with the office ascend router/gw & all
was VPN heaven. However, I now need to negotiate mobile(FreeBSD) to
static(FreeBSD) & that is proving problematic. Executing a SED script after
DHCP of mobile is easy, but it seems I also need to SED the static host's SPD
-- ie no wildcards allowed as in the ascend router situtation. Needless to
say, allowing "unauthenticated" hosts (read anyone) to modify the SPD on a
machine so that it can be authenticated strikes me as putting the cart before
the horse.

When I install a "wildcard" host (0.0.0.0) on the static side, racoon only
negotiates the mobile->static SAD...which is useless & expires. Seems to me
that racoon needs to update kernel SPDs with wildcards to support mobile
VPNs. At least that's all I've been able to come up with.

Have you found a silver bullet?

Cheers, Kent

[Christian Kratzer]

Hi,

Post by Kent Hauser
Hi Mike,
Had any progress? I've also by stymied for a clean solution. Previously, I
used a simple SED script from executed from "/etc/ppp/ppp.linkup" to edit a
"setkeys" script which then negotiated with the office ascend router/gw & all
was VPN heaven. However, I now need to negotiate mobile(FreeBSD) to
static(FreeBSD) & that is proving problematic. Executing a SED script after
DHCP of mobile is easy, but it seems I also need to SED the static host's SPD
-- ie no wildcards allowed as in the ascend router situtation. Needless to
say, allowing "unauthenticated" hosts (read anyone) to modify the SPD on a
machine so that it can be authenticated strikes me as putting the cart before
the horse.
When I install a "wildcard" host (0.0.0.0) on the static side, racoon only
negotiates the mobile->static SAD...which is useless & expires. Seems to me
that racoon needs to update kernel SPDs with wildcards to support mobile
VPNs. At least that's all I've been able to come up with.
Have you found a silver bullet?

Solution 1:

the silver bullet to allow roaming clients with dynamic address to connect to
your racoon is to have no policy at all defined for them and use an anonymous
section your racoon.conf with

generate_policy on;

This way your clients connect and racoon sets up any policy they request.

This is a bit ugly as you have to trust them not to screw up your policy but
seems to be the only solution currently availale with racoon.

You will also want to use certificates instead of preshared keys for
authentication unless you are comfortable with having a single preshared key
for all your roaming users.

Solution 2:

We have a setup where we have 3 offices each with dynamic ip's and freebsd
boxes as their gateways. The boxes all run scripts to register their dynamic
ip address at a colocated box with a static ip. The boxes also resolve each
others ip addresses every 5 minutes and generate a new ipsec.conf and install
it if it differs from the previous one. The system is now very stable and
we have ispec tunnels between all 3 offices.

If something changes they rewire themselves on the fly.


Greetings
Christian

[Kent Hauser]

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

[The Anarcat]

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

[Christian Kratzer]

Hi,

Post by The Anarcat
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: ***@cksoft.de
Phone: [phone] Open Software Solutions, Network Security
Fax: [phone] FreeBSD spoken here!

[Kent Hauser]

Sorry about the attachments. I did a repost on -questions immed after
orig posting which includes attachments.

Kent

Post by The Anarcat
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.

[Kent Hauser]

[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 ***@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 <<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.
#
# 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 "***@kame.net";
- peers_identifier user_fqdn "***@kame.net";
+ my_identifier user_fqdn "***@kent.tfd.com"
+ peers_identifier user_fqdn "***@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 "***@kame.net";
- peers_identifier user_fqdn "***@kame.net";
+ my_identifier user_fqdn "***@tfd.com"
+ #peers_identifier user_fqdn "***@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 ;
====

[Christian Kratzer]

Hi,

Post by Kent Hauser
Hi Mike,
Had any progress? I've also by stymied for a clean solution. Previously, I
used a simple SED script from executed from "/etc/ppp/ppp.linkup" to edit a
"setkeys" script which then negotiated with the office ascend router/gw & all
was VPN heaven. However, I now need to negotiate mobile(FreeBSD) to
static(FreeBSD) & that is proving problematic. Executing a SED script after
DHCP of mobile is easy, but it seems I also need to SED the static host's SPD
-- ie no wildcards allowed as in the ascend router situtation. Needless to
say, allowing "unauthenticated" hosts (read anyone) to modify the SPD on a
machine so that it can be authenticated strikes me as putting the cart before
the horse.
When I install a "wildcard" host (0.0.0.0) on the static side, racoon only
negotiates the mobile->static SAD...which is useless & expires. Seems to me
that racoon needs to update kernel SPDs with wildcards to support mobile
VPNs. At least that's all I've been able to come up with.
Have you found a silver bullet?

Solution 1:

the silver bullet to allow roaming clients with dynamic address to connect to
your racoon is to have no policy at all defined for them and use an anonymous
section your racoon.conf with

generate_policy on;

This way your clients connect and racoon sets up any policy they request.

This is a bit ugly as you have to trust them not to screw up your policy but
seems to be the only solution currently availale with racoon.

You will also want to use certificates instead of preshared keys for
authentication unless you are comfortable with having a single preshared key
for all your roaming users.

Solution 2:

We have a setup where we have 3 offices each with dynamic ip's and freebsd
boxes as their gateways. The boxes all run scripts to register their dynamic
ip address at a colocated box with a static ip. The boxes also resolve each
others ip addresses every 5 minutes and generate a new ipsec.conf and install
it if it differs from the previous one. The system is now very stable and
we have ispec tunnels between all 3 offices.

If something changes they rewire themselves on the fly.


Greetings
Christian