It can be a bit fiddly to get the Linux FreeS/WAN IPSEC & IKE implementation to talk with the Cisco PIX so I've written a little tutorial to help. I guess it also serves as a bit of an introduction to the PIX OS too.
This example was tested on Debian Woody unstable with version 1.99-6 of the FreeS/WAN Linux kernal patch and userspace utilities on the Linux 2.4.21-rc6-ben0 kernel (powerpc).
The PIX is a PIX-501, 16 MB RAM, CPU Am5x86 133 MHz running firmware version 6.2(2)
In my test scenario I have 2 private networks: 10.0.0.0/24 connected to the PIX and 192.168.87.0/24 connected to Linux. The PIX and Linux are connected together over the "public" network 192.168.0.0/24.
The PIX has IPs 10.0.0.254 and 192.168.0.155 and Linux has IPs 192.168.87.5 and 192.168.0.108.
As long as the Cisco side is configured correctly (with the appropriate proposals) the freeswan side is almost default and therefore pretty simple. The full config is available here but I'll explain the important bits.
conn pix # The Linux box left=192.168.0.108 leftsubnet=192.168.87.0/24 # The Cisco PIX right=192.168.0.155 rightsubnet=10.0.0.0/24 # Pre-shared keys authby=secret # Turn perfect forwarding security off pfs=no # auto=start will bring this up when you start ipsec auto=add
Depending on your setup you may need the usual "next hop" options
leftnexthop=%defaultgateway for example) my as the two devices
were connected directly together in this example, I didn't need it. Check the
FreeS/WAN manual for further details as this isn't PIX specific.
You also need an ipsec.secrets config file with the pre-shared key in it.
192.168.0.108 192.168.0.155 : PSK "mypassword"
The PIX config is more fiddly. I'll go through it step by step and explain what and why. Only parts of this are necessary for the VPN config (for example, you don't need to have the same interface names!) but I'm going to cover it all anyway. (Note: I've wrapped some long config lines onto two lines (denoted by a \ at the end of the line). This needs to be typed in as one line.)
|nameif ethernet0 outside security0 nameif ethernet1 inside security100 enable password earthquake passwd california||Setup the interface names and access passwords.|
|hostname pix domain-name johnleach.co.uk||Setup hostname and domain name. This is important for rsa key generation. This example only uses rsa keys for ssh, but you'd need them if you did isakmp authentication by rsa.|
|access-list 100 permit ip \ 10.0.0.0 255.255.255.0 192.168.87.0 255.255.255.0||
This is a normal access list but we're going to use it in the crypto map, which
turns it into a "crypto access list". Anything permitted is encrypted and
anything denied is sent plain-text (unless hit by another access-list in a
different map). We don't need to bind this to an interface using an
|ip address outside 192.168.0.155 255.255.255.0 ip address inside 192.168.24.1 255.255.255.0||Set the IP address of this PIX|
|global (outside) 1 interface||Set the global IPs for the outside interface (for use with NAT). Rather than specify an IP address or range, we're just using the keyword "interface" which will auto-select it for us.|
|nat (inside) 0 access-list 100||Don't NAT any traffic destined over the IPSEC tunnel|
|nat (inside) 1 10.0.0.0 255.255.255.0 0 0||NAT everything else from the LAN|
|route outside 0.0.0.0 0.0.0.0 192.168.0.254 1||Setup our default route. This is a 3rd router with access to the Internet but we don't use it for IPSEC as our peer is on the same network.|
|sysopt connection permit-ipsec||As explained above, this allows traffic flagged as to be encrypted to bypass other access-lists and conduits. Without this, we'd need to write and apply some access-lists explicitly allowing the traffic across the PIX, which is wasteful if you've already configured a crypto access list.|
|crypto ipsec transform-set myset esp-3des esp-md5-hmac||Create a ipsec transform set. This defines what encryption and authentication algorithms you want to use. In this case we're using 3DES ESP with ESP MD5 HMAC authentication.|
|crypto map linkmap 10 ipsec-isakmp||FIXME|
|crypto map mymap 10 match address 100||Associate this map with the access list we wrote earlier defining which traffic we want to encrypt.|
|crypto map mymap 10 set peer 192.168.0.108||Define the other IPSEC endpoint (the Linux box).|
|crypto map mymap 10 set transform-set myset||Associate this map with the IPSEC transform set we defined earlier.|
|crypto map mymap interface outside||
Bind this map to the outside interface. You can bind only one map per
interface, but each map can have multiple entries (e.g: |
|isakmp enable outside||Enable the isakmp service (UDP port 500) on the outside interface.|
|isakmp key mypassword address 192.168.0.108 \ netmask 255.255.255.255 no-xauth no-config-mode||Specified a key and which peers to use it with. Disables extended authentication (TACACS, RADIUS etc.). Disables "config-mode" where the PIX would push a config (IPSEC policy, IP address, firewall settings etc.) to the client (Only the Cisco client software supports this).|
|isakmp identity address||
Use ip addresses as ID as opposed to |
|isakmp policy 10 authentication pre-share||
In this example we want to use a pre-shared key (password) rather than the
|isakmp policy 10 encryption 3des||
Use triple des for encryption. (Alternative is |
|isakmp policy 10 hash md5||
Again, in this example we use the md5 hash for authentication. Alternative is
|isakmp policy 10 group 2||
Use the group 2 Diffie-Hellman key exchange for IKE (1024-bit). Alternative is
|isakmp policy 10 lifetime 28800||Sets the key lifetime to 28800 seconds. This one is important as FreeS/WAN will only support key lifetime settings up to 28800 seconds. I believe the PIX default to be 86400 seconds. This will prevent the PIX and the Linux box agreeing on a key policy and things will fail, probably without useful error messages, so pay attention to this!|
|ssh 192.168.0.108 255.255.255.255 outside ssh 192.168.24.0 255.255.255.0 inside||
To allow remote management of the PIX, enable ssh from the Linux box on the
outside and ssh from any host on the inside range. You need to have generated
an rsa key (and saved it!) with the commands |
(July 2003) Daniel Meyer has informed me having a crypto ACL defining particular traffic for encryption will result in unnecessary SA's being created. He recommends defining the full network ranges (as with this example) in the crypto ACL, and then using normal ACLs to control what can flow between the networks. An added benefit of this is that packets containing sensitive information destined for the remote network, but not allowed by your policy, won't end up being sent to your default gateway, over the Internet. I'll try and make time to update the configs above with this in mind at some point.
$Date: 2004-11-12 10:05:55 +0000 (Fri, 12 Nov 2004) $
Copyright (c) John Leach <john at johnleach dot co dot uk >