9.IKEv2 Cisco ASA and strongSwan
In this lesson we’ll take a look how to configure an IPsec IKEv2 tunnel between a Cisco ASA Firewall and a Linux strongSwan server.
strongSwan is an IPsec VPN implementation on Linux which supports IKEv1 and IKEv2 and some EAP/mobility extensions. It’s well documented, maintained and supports Linux kernels 3.x and later.
For this example I’m using a Ubuntu 14.04 LTS server. Here’s the topology:
Above we have a small network with 4 devices. On the left side we have our strongSwan server, on the other side a Cisco ASA firewall. I’m using two routers called R1 and R2 as “hosts” so we have something to test the VPN. Let’s start with the strongSwan configuration!
1.strongSwan Configuration
strongSwan is in the default Ubuntu repositories so installing it is very simple. Just use apt-get to fetch and install it:
# apt-get install strongswanThe main configuration is done in the ipsec.conf file. Open your favorite text editor and edit it:
# vim /etc/ipsec.confThis is what the configuration should look like:
config setup
# strictcrlpolicy=yes
# uniqueids = no
conn %default
ikelifetime=1440m
keylife=60m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
authby=secret
conn ciscoasa
left=10.10.10.1
leftsubnet=192.168.1.0/24
leftid=10.10.10.1
right=10.10.10.2
rightsubnet=192.168.2.0/24
rightid=10.10.10.2
auto=add
ike=aes128-sha1-modp1536
esp=aes128-sha1
keyexchange=ikev2Let’s discuss these parameters so you know what we are dealing with. The first two items (strictcrlpolicy and uniqueids) are uncommented by default and we don’t have to worry about these. The first parameters are under the %default connection which means they apply to all connections unless overruled by a specific connection profile.
- ikelifetime=1440m: This is the IKE Phase 1 (ISAKMP) lifetime. In strongSwan this is configured in minutes. The default value equals 86400 seconds (1 day). This is a common value and also the default on our Cisco ASA Firewall.
- keylife=60m: This is the IKE Phase2 (IPsec) lifetime. Default strongSwan value is 60 minutes which is the same as our Cisco ASA Firewall’s 3600 seconds (1 hour).
- rekeymargin=3m: How long before the SA expiry should strongSwan attempt to negiotate the replacements. This is used so when a SA is about to expire, there is already a new SA so that we don’t have any downtime when the current SA expires. This is a local value, it doesn’t have to match with the other side.
- keyingtries=1: How many attempts should strongSwan make to negotiate a connection (or replacement) before giving up. This is a local value, doesn’t have to match with the other side.
- keyexchange=ikev1: The default is to use IKEv1, we will overule this with another connection profile.
- authby=secret: The default authentication method is to use pre-shared keys.
Now for our site-to-site VPN with the Cisco ASA Firewall we have another connection profile called “ciscoasa” with some more specific parameters:
- left=10.10.10.1: strongSwan sees itself as “left” so this is where we configure the IP address of strongSwan that we want to use for the IPsec VPN.
- leftsubnet=192.168.1.0/24: The subnet behind strongSwan that we want to reach through the VPN.
- leftid=10.10.10.1: how strongSwan should identify itself, this can be an IP address or a FQDN. We’ll use the IP address.
- right=10.10.10.2: the IP address of the Cisco ASA Firewall.
- rightsubnet=192.168.2.0/24: The subnet behind the Cisco ASA Firewall.
- rightid=10.10.10.2: the ID of the Cisco ASA Firewall.
- auto=add: This means that this connection is loaded when the IPSEC daemon starts but the tunnel isn’t built right away. The tunnel will be built as soon as there is traffic that should go through the tunnel. if you set this value to “start” then the tunnel will be built as soon as the daemon is started.
- ike=aes128-sha1-modp1536: The security parameters for IKE Phase 1, in this example we use AES 128-bit, SHA-1 and DH Group 5.
- esp=aes128-sha1: We use ESP, AES 128-bit and SHA-1 for Phase 2.
- keyexchange=ikev2: We want to use IKEv2 for this connection profile.
This completes the connection profile but we still have to configure the pre-shared keys. This is done in the ipsec.secrets file. Open your text editor:
# vim /etc/ipsec.secretsIKEv2 allows us to use a different pre-shared key for each peer, to keep it simple we’ll use the same key on both sides. Add this to the ipsec.secrets file:
10.10.10.1 : PSK "networklessons"
10.10.10.2 : PSK "networklessons"This completes the IPsec configuration. There’s still one thing left to do…by default, Ubuntu (or most Linux distributions) will not act as a router…it won’t forward IP packets from one interface to another. To enable this you have to use the following command:
# sysctl -w net.ipv4.ip_forward=1Forwarding is now activated. If you want to enable this at boot then you should add it to the sysctl.conf file. You can do it like this:
# echo "net.ipv4.ip_forward = 1" | tee -a /etc/sysctl.confEverything is now in place for strongSwan. Let’s start the IPsec daemon:
# ipsec start
Starting strongSwan 5.1.2 IPsec [starter]...Now we can work on the Cisco ASA…
2.Cisco ASA Configuration
In a previous lesson I covered the configuration of IKEv2 IPsec VPN between two Cisco ASA firewalls so I won’t explain all commands one by one again. First we’ll configure the interfaces:
ASA1(config)# interface e0/0
ASA1(config-if)# no shutdown
ASA1(config-if)# nameif INSIDE
ASA1(config-if)# ip address 192.168.2.254 255.255.255.0ASA1(config)# interface e0/1
ASA1(config-if)# no shutdown
ASA1(config-if)# nameif OUTSIDE
ASA1(config-if)# ip address 10.10.10.2 255.255.255.0Now we can configure the VPN settings. Let’s start with the IKEv2 policy:
ASA1(config)# crypto ikev2 policy 10
ASA1(config-ikev2-policy)# encryption aes
ASA1(config-ikev2-policy)# group 5
ASA1(config-ikev2-policy)# prf sha
ASA1(config-ikev2-policy)# lifetime seconds 86400This matches the settings of strongSwan (AES 128-bit, DH group 5 and SHA-1). Let’s configure the IPsec settings:
ASA1(config)# crypto ipsec ikev2 ipsec-proposal MY_PROPOSAL
ASA1(config-ipsec-proposal)# protocol esp encryption aes
ASA1(config-ipsec-proposal)# protocol esp integrity sha-1This also matches the IPsec settings of strongSwan, AES 128-bit and SHA-1. Let’s configure the access-list that matches the traffic that should go through the tunnel:
ASA1(config)# access-list LAN2_LAN1 extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0All traffic between 192.168.2.0 /24 and 192.168.1.0 /24 should go through the tunnel. Let’s combine everything from above in a crypto map:
ASA1(config)# crypto map MY_CRYPTO_MAP 1 match address LAN2_LAN1
ASA1(config)# crypto map MY_CRYPTO_MAP 1 set peer 10.10.10.1
ASA1(config)# crypto map MY_CRYPTO_MAP 1 set ikev2 ipsec-proposal MY_PROPOSAL
ASA1(config)# crypto map MY_CRYPTO_MAP interface OUTSIDEWe attach the access-list and IPsec settings to the crypto map, configure the remote peer (strongSwan) and enable it on the outside interface. Let’s configure the pre-shared keys now:
ASA1(config)# tunnel-group 10.10.10.1 type ipsec-l2l
ASA1(config)# tunnel-group 10.10.10.1 ipsec-attributes
ASA1(config-tunnel-ipsec)# ikev2 local-authentication pre-shared-key networklessons
ASA1(config-tunnel-ipsec)# ikev2 remote-authentication pre-shared-key networklessonsWe use the same pre-shared keys as what we configured on strongSwan. Last but not least, enable IKEv2 on the outside interface:
ASA1(config)# crypto ikev2 enable OUTSIDEAnd create a route so that the ASA knows how to reach the remote subnet behind strongSwan:
ASA1(config)# route OUTSIDE 192.168.1.0 255.255.255.0 10.10.10.1That takes care of the configuration. Let’s verify our work!
3.Verification
I’ll send a ping from R1 to R2, this should trigger the ASA to build the IPsec tunnel:
R1#ping 192.168.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 msI’m getting a reply so it seems to work. It’s possible that your first pings get a timeout since the tunnel has to be established first. Let’s verify our work now…
3.1.Cisco ASA Verification
On the ASA we have some useful commands:
ASA1# show crypto isakmp sa
There are no IKEv1 SAs
IKEv2 SAs:
Session-id:2, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote Status Role
10481561 10.10.10.2/500 10.10.10.1/500 READY INITIATOR
Encr: AES-CBC, keysize: 128, Hash: SHA96, DH Grp:5, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/784 sec
Child sa: local selector 192.168.2.0/0 - 192.168.2.255/65535
remote selector 192.168.1.0/0 - 192.168.1.255/65535
ESP spi in/out: 0x2d431feb/0xc9cf584dThis tells us that we we have a security association. Now let’s check the actual IPsec tunnel:
ASA1# show crypto ipsec sa
interface: OUTSIDE
Crypto map tag: MY_CRYPTO_MAP, seq num: 1, local addr: 10.10.10.2
access-list LAN2_LAN1 extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
current_peer: 10.10.10.1
#pkts encaps: 5956, #pkts encrypt: 5956, #pkts digest: 5956
#pkts decaps: 5940, #pkts decrypt: 5940, #pkts verify: 5940
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 5956, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 10.10.10.2/500, remote crypto endpt.: 10.10.10.1/500
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: C9CF584D
current inbound spi : 2D431FEB
inbound esp sas:
spi: 0x2D431FEB (759373803)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, }
slot: 0, conn_id: 8192, crypto-map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (kB/sec): (4284859/27965)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0xC9CF584D (3385808973)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, }
slot: 0, conn_id: 8192, crypto-map: MY_CRYPTO_MAP
sa timing: remaining key lifetime (kB/sec): (4054458/27965)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001Above you can see the actual number of packets that have been encrypted and decrypted. This proves that the tunnel is working. Let’s see what it looks like from strongSwan’s side.
3.2.strongSwan Verification
The ipsec command is where you should start. Take a look:
# ipsec statusall
Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-32-generic, x86_64):
uptime: 15 minutes, since Mar 25 18:09:26 2015
malloc: sbrk 1486848, mmap 0, used 335296, free 1151552
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pkcs1 pkcs7 pkcs8 pkcs12 pem openssl xcbc cmac hmac ctr ccm gcm attr kernel-netlink resolve socket-default stroke updown eap-identity addrblock
Listening IP addresses:
192.168.1.254
10.10.10.1
10.56.101.79
Connections:
ciscoasa: 10.10.10.1...10.10.10.2 IKEv2
ciscoasa: local: [10.10.10.1] uses pre-shared key authentication
ciscoasa: remote: [10.10.10.2] uses pre-shared key authentication
ciscoasa: child: 192.168.1.0/24 === 192.168.2.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
ciscoasa[1]: ESTABLISHED 14 minutes ago, 10.10.10.1[10.10.10.1]...10.10.10.2[10.10.10.2]
ciscoasa[1]: IKEv2 SPIs: 4f0dd82acee2d0d3_i b82d3399138ad623_r*, pre-shared key reauthentication in 23 hours
ciscoasa[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
ciscoasa{1}: INSTALLED, TUNNEL, ESP SPIs: c9cf584d_i 2d431feb_o
ciscoasa{1}: AES_CBC_128/HMAC_SHA1_96, 595600 bytes_i (5956 pkts, 226s ago), 594000 bytes_o (5940 pkts, 226s ago), rekeying in 7 hours
ciscoasa{1}: 192.168.1.0/24 === 192.168.2.0/24The ipsec statusall command tells us that we have a security association with the ASA, you can also see the number of packets that have been encrypted and decrypted. There’s also another command that is quite useful:
# ip -s xfrm policy
src 192.168.2.0/24 dst 192.168.1.0/24 uid 0
dir fwd action allow index 82 priority 1859 share any flag (0x00000000)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 0(sec), hard 0(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets)
add 2015-03-25 18:09:49 use 2015-03-25 18:20:46
tmpl src 10.10.10.2 dst 10.10.10.1
proto esp spi 0x00000000(0) reqid 1(0x00000001) mode tunnel
level required share any
enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
src 192.168.2.0/24 dst 192.168.1.0/24 uid 0
dir in action allow index 72 priority 1859 share any flag (0x00000000)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 0(sec), hard 0(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets)
add 2015-03-25 18:09:49 use -
tmpl src 10.10.10.2 dst 10.10.10.1
proto esp spi 0x00000000(0) reqid 1(0x00000001) mode tunnel
level required share any
enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
src 192.168.1.0/24 dst 192.168.2.0/24 uid 0
dir out action allow index 65 priority 1859 share any flag (0x00000000)
lifetime config:
limit: soft (INF)(bytes), hard (INF)(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 0(sec), hard 0(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets)
add 2015-03-25 18:09:49 use 2015-03-25 18:20:46
tmpl src 10.10.10.1 dst 10.10.10.2
proto esp spi 0x00000000(0) reqid 1(0x00000001) mode tunnel
level required share any
enc-mask ffffffff auth-mask ffffffff comp-mask ffffffffThis shows us the IPsec policy settings. As you can see traffic between 192.168.1.0 /24 and 192.168.2.0 /24 is allowed inbound, outbound and can be forwarded.
If you run into any issues. There are two useful places to check to debug strongSwan issues. The first one is a log file:
# cat /var/log/auth.logAny authentication errors will show up in this log file. Another nice trick is to start the tunnel on strongSwan manually as it will give you debug information on the terminal:
# ipsec up ciscoasa
/usr/sbin/ipsec: unknown IPsec command `ciscoasa' (`ipsec --help' for list)
root@strongswan:/home/vmware# ipsec up ciscoasa
initiating IKE_SA ciscoasa[1] to 10.10.10.2
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
sending packet: from 10.10.10.1[500] to 10.10.10.2[500] (1108 bytes)
received packet: from 10.10.10.2[500] to 10.10.10.1[500] (521 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No V V V N(NATD_S_IP) N(NATD_D_IP) V ]
received Cisco Delete Reason vendor ID
received Cisco Copyright (c) 2009 vendor ID
received unknown vendor ID: 43:49:53:43:4f:2d:47:52:45:2d:4d:4f:44:45:02
received FRAGMENTATION vendor ID
authentication of '10.10.10.1' (myself) with pre-shared key
establishing CHILD_SA ciscoasa
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(EAP_ONLY) ]
sending packet: from 10.10.10.1[4500] to 10.10.10.2[4500] (364 bytes)
received packet: from 10.10.10.2[4500] to 10.10.10.1[4500] (236 bytes)
parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
authentication of '10.10.10.2' with pre-shared key successful
IKE_SA ciscoasa[1] established between 10.10.10.1[10.10.10.1]...10.10.10.2[10.10.10.2]
scheduling reauthentication in 86163s
maximum IKE_SA lifetime 86343s
received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
connection 'ciscoasa' established successfullyUse the “ipsec up” command to establish the tunnel yourself. The example above is a tunnel that was established without any issues. If anything goes wrong, it will show up here.
That’s all I have for now. The only thing left to do on the Ubuntu server is configuring IPtables. Right now the server will forward anything, it would be wise to restrict incoming and forwarding traffic but that’s another story.
If you have any questions, feel free to leave a comment.
Comments
Post a Comment