03-05-2011 09:16 AM - edited 03-08-2019 06:39 PM
Cisco ASA IKEv2 PKI Site-Site VPN
Hi
For the last couple of weeks I’ve been trying to get a IKEv2 site-to-site VPN working between a 2921 running 15.13T and an ASA running 8.4.1. After spending long into the night tearing my hair out, I’ve found out that it’s not working due to a bug, seems that the ASA doesn’t like authenticating the digital signature of the IOS device... I can’t believe that Cisco released ASA 8.4.1 without testing this with it’s own products…
One thing I did learn in my troublesome experience is that the ASA currently (8..4.1), does not support the transport of certs using http, as defined in RFC 5996 “Implementations MUST support the HTTP [HTTP] method for hash-and-URL lookup. The behavior of other URL methods [URLS] is not currently specified, and such methods SHOULD NOT be used in the absence of a document specifying them.“
Once the bug with IOS – ASA IKEv2 using PKI is fixed, assuming that the ASA still doesn’t support HTTP Certs, then the IOS device should disable sending these using the command no crypto ikev2 http-url cert
To create the IKEv2 PKI VPN between two ASA’s I used the following setup, both ASA’s have a default route to each other. Router R1 has a default route of ASA1, with router R2 having a default route of ASA2. The CA server was a 2921 setup to automatically grant certs. The CA was setup as a NTP Master, so both ASA’s could sync time. Although I haven’t shown it, both ASA’s were authenticated and enrolled to the CA, to gain a PKI certificate.
The following relevant code is off the devices
ASA1(config)# sh run
!
interface Ethernet0/0
nameif outside
security-level 0
ip address 172.16.1.10 255.255.255.0
!
interface Ethernet0/1
nameif inside
security-level 100
ip address 1.1.1.1 255.255.255.0
!
access-list 100 extended permit ip 1.1.1.0 255.255.255.0 2.2.2.0 255.255.255.0
route outside 0.0.0.0 0.0.0.0 172.16.1.20 1
crypto ipsec ikev2 ipsec-proposal prop1
protocol esp encryption 3des
protocol esp integrity sha-1
crypto map mymap 10 match address 100
crypto map mymap 10 set peer 172.16.1.20
crypto map mymap 10 set ikev2 ipsec-proposal prop1
crypto map mymap 10 set trustpoint CA
crypto map mymap interface outside
crypto ca trustpoint CA
enrollment url http://172.16.1.1:80
crypto ikev2 policy 10
encryption aes
integrity sha
group 5
prf sha
lifetime seconds 86400
crypto ikev2 enable outside
ntp server 172.16.1.1
tunnel-group 172.16.1.20 type ipsec-l2l
tunnel-group 172.16.1.20 ipsec-attributes
ikev2 remote-authentication certificate
ikev2 local-authentication certificate CA
!
ASA2(config)# sh run
: Saved
:
ASA Version 8.4(1)
!
hostname ASA2
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Ethernet0/0
nameif outside
security-level 0
ip address 172.16.1.20 255.255.255.0
!
interface Ethernet0/1
nameif inside
security-level 100
ip address 2.2.2.1 255.255.255.0
!
access-list 100 extended permit ip 2.2.2.0 255.255.255.0 1.1.1.0 255.255.255.0
route outside 0.0.0.0 0.0.0.0 172.16.1.10 1
crypto ipsec ikev2 ipsec-proposal prop1
protocol esp encryption 3des
protocol esp integrity sha-1
crypto map mymap 10 match address 100
crypto map mymap 10 set peer 172.16.1.10
crypto map mymap 10 set ikev2 ipsec-proposal prop1
crypto map mymap 10 set trustpoint CA
crypto map mymap interface outside
crypto ca trustpoint CA
enrollment url http://172.16.1.1:80
crl configure
crypto ikev2 policy 10
encryption aes
integrity sha
group 5
prf sha
lifetime seconds 86400
crypto ikev2 enable outside
ntp server 172.16.1.1
tunnel-group 172.16.1.10 type ipsec-l2l
tunnel-group 172.16.1.10 ipsec-attributes
ikev2 remote-authentication certificate
ikev2 local-authentication certificate CA
!
Once interesting traffic was sent to initiate the VPN, the IKEv2 tunnel was built, this can be seen below;
ASA1(config)# sh crypto ikev2 sa detail
IKEv2 SAs:
Session-id:1, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote Status Role
2783320215 172.16.1.10/500 172.16.1.20/500 READY RESPONDER
Encr: AES-CBC, keysize: 128, Hash: SHA96, DH Grp:5, Auth sign: RSA, Auth verify: RSA
Life/Active Time: 86400/94 sec
Session-id: 1
Status Description: Negotiation done
Local spi: E20EE7647CF3B613 Remote spi: 24694BEFF9BA836B
Local id: hostname=ASA1
Remote id: hostname=ASA2
Local req mess id: 1 Remote req mess id: 3
Local next mess id: 1 Remote next mess id: 3
Local req queued: 1 Remote req queued: 3
Local window: 1 Remote window: 1
DPD configured for 10 seconds, retry 2
NAT-T is not detected
Child sa: local selector 1.1.1.0/0 - 1.1.1.255/65535
remote selector 2.2.2.0/0 - 2.2.2.255/65535
ESP spi in/out: 0x7f862e62/0x819dc0ef
AH spi in/out: 0x0/0x0
CPI in/out: 0x0/0x0
Encr: 3DES, esp_hmac: SHA96
ah_hmac: None, comp: IPCOMP_NONE, mode tunnel
From the above output we can tell that ASA2 must have initiated the setup o the VPN as ASA1 is the RESPONDER.
The IPSEC tunnel is exactly the same as in an IKEv1 established tunnel;
ASA1(config)# sh crypto ipsec sa detail
interface: outside
Crypto map tag: mymap, seq num: 10, local addr: 172.16.1.10
access-list 100 extended permit ip 1.1.1.0 255.255.255.0 2.2.2.0 255.255.255.0
local ident (addr/mask/prot/port): (1.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (2.2.2.0/255.255.255.0/0/0)
current_peer: 172.16.1.20
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 5, #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
#pkts no sa (send): 0, #pkts invalid sa (rcv): 0
#pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0
#pkts invalid prot (rcv): 0, #pkts verify failed: 0
#pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 0
#pkts invalid pad (rcv): 0,
#pkts invalid ip version (rcv): 0,
#pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0
#pkts replay failed (rcv): 0
#pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0
#pkts internal err (send): 0, #pkts internal err (rcv): 0
local crypto endpt.: 172.16.1.10/500, remote crypto endpt.: 172.16.1.20/500
path mtu 1500, ipsec overhead 58, media mtu 1500
current outbound spi: 819DC0EF
current inbound spi : 7F862E62
inbound esp sas:
spi: 0x7F862E62 (2139500130)
transform: esp-3des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 4096, crypto-map: mymap
sa timing: remaining key lifetime (kB/sec): (4101119/28638)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x000007FF
outbound esp sas:
spi: 0x819DC0EF (2174599407)
transform: esp-3des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 4096, crypto-map: mymap
sa timing: remaining key lifetime (kB/sec): (4239359/28638)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
It’s well known that IKEv1 is vulnerable to a DOS attack, whereby an attacker can send many IKE phase 1 packets that can exhaust a devices resources, this is documented below
http://www.cisco.com/en/US/products/products_security_response09186a00806f33d4.html
I now wanted to test the cookie-challenge feature of IKEv2, this mitigates this attack by sending back a cookie challenge and storing no state on the device, this is explained below
http://www.it-book.co.uk/814/cisco-ike-version-2-site-to-site-vpn-using-psk
I enabled the following command on ASA1
crypto ikev2 cookie-challenge always
I thought that enabling cookie challenge would mitigate the IKE DOS vulnerability; however my findings below make interesting reading…
I captured an initial IKEv2 packet (KE_INIT_SA, from ASA2 to ASA1 and replayed this using tcpreplay, ASA1 would correctly reply to the packet with a cookie challenge packet, the following are the syslog from ASA1 when it receives a IKE_INIT_SA
Mar 04 2011 11:07:55: %ASA-5-750002: Local:172.16.1.10:500 Remote:172.16.1.20:500 Username:Unknown Received a IKE_INIT_SA request
Mar 04 2011 11:07:55: %ASA-5-750004: Local:172.16.1.10:500 Remote:172.16.1.20:500 Username:Unknown Sending COOKIE challenge to throttle possible DoS
I decided to send 100000 packets to see how much ASA1 could handle, these were sent in in 9.11 Seconds, running @ 41.83Mbps (10965.19 pps)
As you can see the IKEv2 daemon was nailed!
ASA1(config)# sh processes cpu-usage sorted
PC Thread 5Sec 1Min 5Min Process
0x081362ad 0xd71b3fa0 88.9% 21.0% 4.8% IKEv2 Daemon
I then crafted a IKE_INIT_SA packet to appear to come from another IKEv2 host (172.16.1.30), destined to ASA1, I replayed this 100000 times with the same result – the IKEv2 daemon being nailed, this was although there was no entry in the crypto map.
So it seems that if you enable IKEv2, it would be a good idea to only allow IKE traffic from known peers. Here’s a neat trick I was taught by the Cisco Firewall legend, David White Jnr…
We create an ACL on ASA1 to only allow IKE packets from ASA2, all other IKE traffic will be dropped. A standard ACL applied to an interface will only block traffic moving through the ASA, not to the ASA itself, however we can filter traffic to the device itself by amending the control-plane command to the end of the line. Note: In testing sometimes I need to bounce the ASA after applying this code for it to take effect
access-list 150 extended permit udp host 172.16.1.20 eq isakmp host 172.16.1.10 eq isakmp
access-list 150 extended deny udp any eq isakmp host 172.16.1.10 eq isakmp
access-list 150 extended permit ip any any
access-group 150 in interface outside control-plane
The above command will drop any non-legit IKE traffic to ASA1.
I now replay 100000 copies of the IKE_INIT_SA packet from 172.16.1.30 to ASA1, which results in the packets being dropped before they hit the CPU, I believe that the Dispatch Unit is what takes packets off the wire. Here we can see that the IKEv2 daemon is not effected by rouge packets.
ASA1(config)# sh processes cpu-usage sorted
PC Thread 5Sec 1Min 5Min Process
0x081ecc51 0xd71c0f3c 65.6% 5.3% 1.1% Dispatch Unit
0x08e5f07c 0xd71b9c58 6.3% 0.5% 0.1% Logger
Attached is the pcap that I replayed from ASA2 to ASA1
Golly Wog,
Excelent stuff, gave it a "Exteremly helpful" :-)
Can I make a suggestion to use "quote" function for all command outputs? Makes it a bit more readable (IMO).
I'd also leave links to referenced on the internet.
Marcin
Hi Golly
It would be useful, if you could provide the details of the bug as I am facing similar situation right now, as I ca not establish a VPN tunnel between ASA5515 and Cisco881 router. However mine is slightly different from yours as the problem I have is the router rejects the remote identity presented by ASA in its digital certificate Cisco doesnt have much details about this problem.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: