IKEv2 between ASA firewall and IOS router

asa-ikev2-ios-2

In previous blog we saw hot to do a site to site IPSec VPN between two Cisco ASA devices. Using IKEv2 for policies negotiations and tunnel establishment. Now, we will change our scenario a bit so that “Company B” uses Cisco IOS router instead of ASA firewall. So, the scenario is as follows:

asa-ikev2-ios

The configuration of ASA-A firewall that belongs to “Company A” remains unchanged, so we will show here only ROUTER-B configuration. Let’s break it to individual steps. First, let’s take a look at the following diagram depicting the steps needed and their order.

ipsec steps diagram final

According to our schema, we first define a key ring:

!
crypto ikev2 keyring IKEv2_KEYRING
peer ASA-A
address 1.1.1.1
pre-shared-key local keyb-a
pre-shared-key remote keya-b
!

Inside the keyring, we give a descriptive name to all of our peers, in this case only ASA-A, and then we state the peer’s address and pre-share keys. Yes, it is plural. Similar to the ASA-A configuration, we can have one key for authenticating one way, and another key for the opposite direction.

Following our diagram, next is IKEv2 proposal. It is called policy in the ASA-A, but servers the same purpose. Here is our proposal:

crypto ikev2 proposal IKEv2_PROPOSAL
encryption aes-cbc-256
integrity sha512
group 5

Very similar to that of ASA-A. We could have more than one algorithm for both encryption and integrity listed, as long as there is a match on the other side. Same goes for Diffie-Hellman group. We are trying to match the parameters given on ASA-A. Next, the profile:

!
crypto ikev2 profile IKEv2_PROFILE
match identity remote address 1.1.1.1 255.255.255.255
identity local address 1.1.1.2
authentication remote pre-share
authentication local pre-share
keyring local IKEv2_KEYRING
!

Lots of stuff here. First, in order to use this profile, the remote identity, which is the IP address in our case, must match. If we want to respond back, we will identify ourselves also with the IP address. Because we can now use different keys for authentication, but also different mechanisms, we state those mechanism here. We could authenticate this peer with pre-shared key, while expect other peer to use digital certificate. For now we want it to be simple. Finaly, if we are using keys for authentication, we must state where our keys are stored.

As for IKEv2 policy, it is very simple. It only ties itself to the proposal:

crypto ikev2 policy IKEv2_POLICY
proposal IKEv2_PROPOSAL

We are pretty much over with IKE settings. Now it’s time for IPSec configuration. First we define crypto ACL:

ip access-list extended COMPANY_B_A_CRYPTO
permit ip 10.100.2.0 0.0.0.3 10.100.1.0 0.0.0.3

This ACL mirrors the one defined on ASA-A. Then, we create the transform set. This is the way of saying how we want our data plane to be protected. It’s a fancy way of saying what do we want to use for encrypting our data and what we want to use for integrity checking. Again, these parameters must match those defined on our peer:

crypto ipsec transform-set IPSEC_TSET1 esp-aes 256 esp-sha-hmac

We are almost there. Let’s define our crypto map which we will attach to the outside interface:

crypto map IKEv2_MAP 1000 ipsec-isakmp
set peer 1.1.1.1
set transform-set IPSEC_TSET1
match address COMPANY_B_A_CRYPTO

Crypto maps are our old friends, so we know them well. We specify that the crypto map entry with the sequence number of 1000 will be used for peer 1.1.1.1. We also specify what traffic will be encrypted and by which means.

Finally, we tie this crypto map to an interface. This crypto map hold all sections together:

interface FastEthernet0/0
crypto map IKEv2_MAP

Ok, we are done. There is only one thing wrong with this configuration – it does not work! Why is that? Well, it’s kinda crypto-geek-stuff, and has something to do with the PRF (Pseudo-Random Functions). Without going too much into math, these functions are used for generating keying material for protecting our data. Both sides must agree on them. Let’s look our ASA-A IKEv2 policy. This is what we typed in:

crypto ikev2 policy 1000
encryption aes-256
integrity sha512
group 5

And this is what it actually looks like:

crypto ikev2 policy 1000
encryption aes-256
integrity sha512
group 5
prf sha
lifetime seconds 86400

We did not add the green line, but this default won’t break anything. We also did not add the red line, but this WILL break everything. This line says that we want to use SHA1 for our pseudo random function. Please note that there is a difference between integrity functions and PRF. From the RFC4306 – Internet Key Exchange (IKEv2) Protocol document:

“In the context of the IKE_SA, four cryptographic algorithms are negotiated: an encryption algorithm, and integrity protection algorithm, a Diffie-Hellman group, and a pseudo -random function (prf).”

So, with our ASA-A, we have those four algorithms stated. But let’s take a look at our ROUTER-B:

crypto ikev2 proposal IKEv2_PROPOSAL
encryption aes-cbc-256
integrity sha512
group 5

We specified only three of required algorithms. Not because we are lazy, or don’t know how to our jobs, but because we can’t specify anything else. Let’s take a look at the help on our router for defining a IKEv2 proposal:

IKEv2 Proposal commands:
encryption  Set encryption algorithm(s) for proposal
exit        Exit from IKEv2 proposal configuration mode
group       Set the Diffie-Hellman group(s)
integrity   Set integrity hash algorithm(s) for proposal
no          Negate a command or set its defaults

So, no PRF. The catch here is that the IOS router uses whatever is specified as an integrity algorithm for pseudo-random function algorithm as well. In order to make our configuration work, we actually need a fix on the ASA-A. We need to equalize the PRF on the ASA-A with the integrity algorithm selected on the IOS router. Like this:

crypto ikev2 policy 1000
encryption aes-256
integrity sha512
group 5
prf sha512
lifetime seconds 86400

So now our configuration should work. Let’s verify…

R1#
R1#ping 10.100.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.100.2.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 12/20/28 ms
R1#

ASA-A#
ASA-A# show cry ikev2 sa

IKEv2 SAs:

Session-id:11, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id                 Local                Remote     Status         Role
227050047           1.1.1.1/500           1.1.1.2/500      READY    INITIATOR
Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp:5, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/23 sec
Child sa: local selector  10.100.1.0/0 – 10.100.1.3/65535
remote selector 10.100.2.0/0 – 10.100.2.3/65535
ESP spi in/out: 0x89413c76/0xa3a132d3
ASA-A#

ROUTER-B#
ROUTER-B#show cry ikev2 sa
IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         1.1.1.2/500           1.1.1.1/500           none/none            READY
Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp:5, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/121 sec

IPv6 Crypto IKEv2  SA

ROUTER-B#

ASA-A#
ASA-A# show crypto ipsec sa | i encap|decap
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
ASA-A#

ROUTER-B#
ROUTER-B#show crypto ipsec sa | i encap|decap
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
ROUTER-B#

We have ASA-A’s config in the previous blog, and here is our ROUTER-B’s config. Blue lines are those we added and are VPN related. Next time we will cover the only combination left, which is IOS-to-IOS.

Thanks for reading.

 

!
hostname ROUTER-B
!
boot-start-marker
boot-end-marker
!
no aaa new-model
no ip icmp rate-limit unreachable
!
no ip domain lookup
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
crypto ikev2 proposal IKEv2_PROPOSAL
encryption aes-cbc-256
integrity sha512
group 5
!
crypto ikev2 policy IKEv2_POLICY
proposal IKEv2_PROPOSAL
!
crypto ikev2 keyring IKEv2_KEYRING
peer ASA-A
address 1.1.1.1
pre-shared-key local keyb-a
pre-shared-key remote keya-b
!
!
crypto ikev2 profile IKEv2_PROFILE
match identity remote address 1.1.1.1 255.255.255.255
identity local address 1.1.1.2
authentication remote pre-share
authentication local pre-share
keyring local IKEv2_KEYRING
!
ip tcp synwait-time 5
ip ssh version 1
!
crypto ipsec transform-set IPSEC_TSET1 esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto map IKEv2_MAP 1000 ipsec-isakmp
set peer 1.1.1.1
set transform-set IPSEC_TSET1
match address COMPANY_B_A_CRYPTO
!
interface FastEthernet0/0
ip address 1.1.1.2 255.255.255.0
ip nat outside
speed auto
duplex auto
crypto map IKEv2_MAP
no shutdown
!
interface FastEthernet0/1
ip address 10.100.2.2 255.255.255.252
ip nat inside
speed auto
duplex auto
no shutdown
!
ip nat pool NAT_POOL 192.168.2.1 192.168.2.10 netmask 255.255.255.0
ip nat inside source list NAT_LIST pool NAT_POOL overload
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip route 0.0.0.0 0.0.0.0 1.1.1.1
ip route 192.168.2.0 255.255.255.0 10.100.2.1
!
ip access-list extended COMPANY_B_A_CRYPTO
permit ip 10.100.2.0 0.0.0.3 10.100.1.0 0.0.0.3
!
ip access-list extended NAT_LIST
deny ip 10.100.2.0 0.0.0.3 10.100.1.0 0.0.0.3
permit ip any any
!
!
control-plane
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
stopbits 1
line vty 0 4
login
!
!
end

 

Advertisements
This entry was posted in ASA, Cisco, IOS, VPN and tagged , , , , , . Bookmark the permalink.

5 Responses to IKEv2 between ASA firewall and IOS router

  1. Pingback: IKEv2 between two IOS routers (crypto map way) | popravak

  2. Mark says:

    I don’t see where the “ikev2 profile IKEv2_PROFILE” is referenced . Is it meant to be referred to in the crypto map?

    • Sasa says:

      It is called with “match identity” statement.

      • mfan says:

        Crypto Map configuration is incomplete –

        crypto map IKEv2_MAP 1000 ipsec-isakmp
        set peer 1.1.1.1
        set transform-set IPSEC_TSET1
        set ikev2-profile IKEv2_PROFILE
        match address COMPANY_B_A_CRYPTO

  3. Pingback: Cisco- IKEV2 | Journey OF THE WSS FOR ACD

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s