cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
15827
Views
25
Helpful
2
Comments
golly_wog
Level 1
Level 1

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.

asa.jpg

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

Comments
Marcin Latosiewicz
Cisco Employee
Cisco Employee

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

Suran Fernando
Level 1
Level 1

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. 

Getting Started

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: