From the team that bought you the FreeSwanToCiscoPix mini-HOWTO, comes... FreeSwan to a Cisco837 ADSL router!

Configuring an IPSec VPN between FreeSwan and a Cisco ADSL (827/837) router

The situation has changed somewhat: this configuration is designed for using a FreeS/WAN machine as a head end VPN concentrator for a number of Cisco ADSL routers at branch offices. In this example, the IPSec head end sits behind a Nokia M1122, so some NAT workarounds are included. These will be marked and easy to work around.

1. Compile a kernel with IPSec support

This is nicely covered on the IPSecInstallation page. A Debian summary
apt-get install kernel-patch-freeswan cd /usr/src/linux export PATCH_THE_KERNEL=yes make-kpkg --revision=ipsec.1.0 kernel_image

2. Get FreeS/WAN

apt-get install freeswan

FreeS/WAN has gone the way of the dodo, so you would be well advised to use OpenSwan instead. Until Debian Sarge is released, FreeS/WAN it is.

3. Configure FreeS/WAN

Here is my FreeS/WAN configuration and explanation.

# /etc/ipsec.conf - FreeS/WAN IPsec configuration file

# basic configuration
config setup
        # Debug-logging controls:  "none" for (almost) none, "all" for lots.

# turn off opportunistic encryption

conn block

conn private

conn private-or-clear

conn clear-or-private

conn clear

conn packetdefault

# The tunnel starts here

conn headend-office1
      type=             tunnel
      leftnexthop=      %defaultroute
      right=            %any
      esp=              3des-md5-96
      keyexchange=      ike
      pfs=              yes
      auto=             add
      authby=           secret
      auth=             esp

The interfaces line tells ipsec to use the same IP address as the interface that the default route is on: this is similar to "ipsec0:eth0" that some configurations recommend, but this works in the general case. When setting your connection up, you might want to set klips (the Kernel level IP Security) and pluto (the IPSEC keying Daemon) logging to "all".

The connection is named headend-office1 and is of type (ESP) tunnel.

The Linux machine is hidden behind a NAT device providing internet access, so we tell FreeS/WAN about the firewall's external IP, not the external IP of the NAT box. So we end up with a network that will eventually look like this:[Cisco ADSL router]===

Note in this example, we don't know very much at all about our network - the 837's are on dynamic IP, so we have no idea at the Linux end what the right side IP addresses will be. For this tunnel we know the right hand subnet to allow, so we specify that - to add more connections, we would have to add more conn blocks.

  • esp sets the ESP parameters. This must be the same encryption and hashing algorithm you specify in your crypto map/isakmp config on the Cisco below. (Else it plain won't work.)
  • keyexchange sets IKE (Internet Key Exchange) and can be set to nothing else.
  • pfs is PerfectForwardSecrecy. This is set 'yes' because we also enabled it on the Cisco end.
  • auto specifies the behaivour when ipsec starts - in this case, it is 'start the connection' - you can set 'add' to add the connection to pluto but not start the tunnel.

Next you need an ipsec.secrets file:

# This file holds shared secrets or RSA private keys for inter-Pluto
# authentication.  See ipsec_pluto(8)? manpage, and HTML documentation.

# You might have an RSA key here depending on if you installed from a .deb
# If you do, you might need to remove it %any: PSK "supersecretpassphrase"

This file contains the pre-shared secret, a password for the connection that is known at both ends. It should be really really long. While it is possible to use RSA sigs between a Cisco and FreeS/WAN, general opinion suggests it doesn't always work, so we will opt for the less secure but more practical option. Note that we haven't specified who can use this PSK - we can't, as we're effectively in a RoadWarrior configuration; we don't know the IP of the office1 end. This is specified with %any.

4. Configure firewalling

On your external interface, enable port 500 UDP (the ISAKMP port), and protocol 50 (IPSEC ESP).

When you succeed, you are going to have incoming packets reinjected onto the ipsec0 interface, so remember to set up firewalling on this interface too!

Remember in this example that I am pinholing 500/UDP and protocol 50 on an external internet access device, so if you're doing that too, time to pinhole some ports.

5. Configuring the Cisco ADSL router

Make sure you have a 3DES firmware on your ADSL router - Free/Open/Swan doesn't support single DES unless you tell it to go into ultra-unsecure-mode!

Log into, enable and configuration mode. You will need lines very similar to these:

! Access lists.  This one make sure that traffic destined between
! networks isn't natted.
access-list NO-NAT remark Traffic to NAT
access-list NO-NAT deny   ip
access-list NO-NAT permit ip any
! This access list permits traffic for the tunneled network
access-list FREESWAN-VPN permit ip
access-list FREESWAN-VPN permit ip
access-list FREESWAN-VPN deny   ip any any
! don't nat traffic on the NO-NAT access list
ip nat inside source list NO-NAT interface Dialer0 overload
! Create a transformation set (encryption & hash) to select 3DES and MD5
crypto ipsec transform-set tr-3des-md5 esp-3des esp-md5-hmac
! Enable the keying protocol [ISAKMP] with no extended auth and the Cisco not
! pushing config down (which it should only do to its own VPN client)
crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
 lifetime 28800
! Specify the passphrase here:
crypto isakmp key 0 supersecretpassphrase address no-xauth

! Create a crypto map called 'cm-cryptomap', to set the IP of the other end,
! and which transformation set to use.
crypto map cm-cryptomap 1 ipsec-isakmp
 set peer
 set transform-set tr-3des-md5
 match address FREESWAN-VPN
 set pfs group2
! Apply the crypto map to the Dialer0 (ADSL) interface
interface Dialer0
 crypto map cm-cryptomap

Check Cisco's reference for IPSec network commands if you need more details.

6. Start the tunnel

At the head (left) end, this tunnel can't connect out; remember we dont know what IP the right hand end is on. So, when you start FreeS/WAN, it will automatically add the connection and wait for the right end to connect.

The tunnel will come up automatically from the Cisco, when you're trying to use it. To force a reconnect try clear crypto sa

7. Ping & use

From a machine on the Cisco network, try pinging something on the network at the left end: ping You should get responses. You can also ping from the right end to the left (a good test, is can a machine on the left network ping the Cisco's internal IP.)

There we go - one working FreeS/WAN to Cisco 837. If you have any questions, contact details are on my Wiki page.

8. Debugging

The ipsec0 interface should have the same IP address as the interface through which you contact your default gateway (possibly ppp0). This is how it's meant to be.

FreeS/WAN end

Turn logging on (klips/pluto to 'all'). Then watch the syslog scroll by with tail -f. Remember, the ISAKMP part is done by pluto and the IPSEC SA part is done by klips, so you might want to grep on those names. Make sure you get ISAKMP working first, then IPSEC.

You can see how your connection is going using ipsec auto --status

You can always tcpdump(8) eth1 on your Linux box, or whatever the connection you are duplicating for your ipsec0 interface. Check that traffic is going both ways.

Cisco end

On the 837, set debug crypto isakmp and debug crypto ipsec. If you're on a console you should see the debug information; if not, type ter mon to monitor it; and ter no mon to turn it off again.

Things to watch out for

  • Before you start debugging double check that you've opened the right things on the right firewalls.
  • Don't try and use identities (left-id or crypto identity); it breaks things.
  • Manually try and add your FreeS/WAN connection to see any errors you might have in your config.
  • Pings from your FreeS/WAN machine to the other end will use the external interface, which isn't part of the range thats allowed on your tunnel. Use a machine behind the network, or if you really need to be able to connect out from the server to the other end, you'll need another connection block with leftsubnet=(external IP).

9. Conclusion

Email on these issues are welcome. It took a long time to figure out and if you can get something as a result of this, I'd be happy. Thanks to everyone who has got in touch and said that they've managed to make their system work as a result of the PIX guide; I hope this is as useful.

Thanks especially to GreigMcGill for thinking that this would be a 2 second Thursday afternoon job and instead giving me something solid to write about :)

-- CraigBox