Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Cisco ASA IKEv2 PKI Site-Site VPN
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 126.96.36.199 255.255.255.0 ! access-list 100 extended permit ip 188.8.131.52 255.255.255.0 184.108.40.206 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
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