IKEv2 between IOS routers (SVTI – Static Virtual Tunnel Interface)

ios-ikev2-ike

Ok, let’s continue our IKEv2 saga… Last time we saw how to do do an IKEv2 tunnel between two IOS routers using crypto maps. This way of configuring IPSec tunnels is ok, but it evolved to SVTI or Static Virtual Tunnel Interface way. With this way, we don’t have crypto maps that ties all elements together, but rather GRE/IPSec tunnel between two IOS routers. This tunnel has two ends, represented with tunnel interfaces. Everything we want to encrypt, we just send to the tunnel interface. By using plain static route. As simple as that. No need to create or adjust crypto access control lists. Even better, we could establish routing protocol over this tunnel! Beside this, it is much easier to do filtering with ACLs by just applying them to the tunnel interface. Same goes with QoS. Pretty cool stuff. So, how do we configure this SVTI interfaces?

Here is our topology:

ikev2 SVTI 1

First, the IKEv2 stuff. It remains the same for several blogs now. For ROUTER-A:

crypto ikev2 proposal IKEv2_PROPOSAL
encryption aes-cbc-256 aes-cbc-192 3des
integrity sha512 sha256 md5
group 14 5 2
!
crypto ikev2 policy IKEv2_POLICY
proposal IKEv2_PROPOSAL
!
crypto ikev2 keyring IKEv2_KEYRING
peer ROUTER_B
address 1.1.1.2
pre-shared-key local keya-b
pre-shared-key remote keyb-a
!
crypto ikev2 profile IKEv2_PROFILE
match identity remote address 1.1.1.2 255.255.255.255
identity local address 1.1.1.1
authentication remote pre-share
authentication local pre-share
keyring local IKEv2_KEYRING
!
crypto ipsec transform-set IPSEC_TRANSFORM1 esp-aes 256 esp-sha512-hmac
mode tunnel
!
crypto ipsec profile IPSEC_PROFILE
set transform-set IPSEC_TRANSFORM1
set ikev2-profile IKEv2_PROFILE

This configuration is slightly different than our previous ones. I don’t mean for algorithms for parent and child tunnels. They are not important for our learning SVTIs. The most obvious difference is missing crypto map settings and presenting IPSec profile. This profile now ties all elements together, just as the crypto maps used to. IPSec profile activates IKEv2 and all elements by being applied to an SVTI interface. From ROUTER-A:

interface Tunnel0
ip address 192.168.12.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Serial5/0
tunnel mode ipsec ipv4
tunnel destination 1.1.1.2
tunnel protection ipsec profile IPSEC_PROFILE

It is almost like old plain GRE tunnel interfaces with the addition of two blue coloured lines. First line changes encapsulation from GRE to GRE/IPSec, and the second applies all IKEv2/IPSec elements we configured. Then we do the same on the  ROUTER-B:

interface Tunnel0
ip address 192.168.12.2 255.255.255.0
 ip access-group DENY_TELNET in
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Serial5/0
tunnel mode ipsec ipv4
tunnel destination 1.1.1.1
tunnel protection ipsec profile IPSEC_PROFILE

Now if we wanted some traffic to be encrypted from ROUTER-A to ROUTER-B, we just send this traffic to the tunnel. On ROUTER-A:

ip route 10.2.2.0 255.255.255.0 Tunnel0

And on ROUTER-B:

ip route 10.1.1.0 255.255.255.0 Tunnel0

Before we go and verify our settings, we may pay a little bit of attention to green line from the Tunnel0 interface configuration on ROUTER-B:

ip access-group DENY_TELNET in

This is very simple way of saying that we don’t want any telnet sessions to our server that is behind ROUTER-B. If we did crypto map way, we would need to create and apply VPN filter, as described in this blog. This could be annoying and prone to errors.

So, let’s verify…

First we need to make sure that the tunnel interface is up:

ROUTER_B#
ROUTER_B#show ip int brie | i Tunnel
Tunnel0                192.168.12.2    YES manual up                    up
ROUTER_B#

Then, we should verify that IKEv2 session is ok:

ROUTER_B#
ROUTER_B#show crypto 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:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/3207 sec

IPv6 Crypto IKEv2  SA

ROUTER_B#

And let’s check encrypted/decrypted packets:

ROUTER_B#
ROUTER_B#show crypto ipsec sa | i encap|decap
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
ROUTER_B#

Finally, let’s do a ping from PC to SERVER:

PC#
PC#ping 10.2.2.2

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

And let’s check number of protected packets again:

ROUTER_B#
ROUTER_B#show crypto ipsec sa | i encap|decap
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
ROUTER_B#

So, we are good. Now, while we are testing, let’s try telneting from PC to SERVER:

PC#
PC#telnet 10.2.2.2
Trying 10.2.2.2 …
% Destination unreachable; gateway or host down

PC#

No luck! That’s because the ACL applied on Tunnel0 interface is preventing us to do so.

Now, what’s even better than an ACL on a tunnel interface is ability to do a routing protocol across SVTI tunnel. First, let’s remove our static routes:

ROUTER_A(config)#
ROUTER_A(config)#no ip route 10.2.2.0 255.255.255.0 tunnel0
ROUTER_A(config)#

ROUTER_B(config)#
ROUTER_B(config)#no ip route 10.1.1.0 255.255.255.0 tunnel0
ROUTER_B(config)#

And exchange routes through the OSPF. First on ROUTER-A and then on ROUTER-B:

router ospf 1
network 10.1.1.0 0.0.0.255 area 0
network 192.168.12.0 0.0.0.255 area 0

router ospf 1
network 10.2.2.0 0.0.0.255 area 0
network 192.168.12.0 0.0.0.255 area 0

Now we can see on the ROUTER-A, for example, that the OSPF adjacency is formed, and that we have received routes from the other side:

*Jan 31 14:01:21.011: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.12.2 on Tunnel0 from LOADING to FULL, Loading Done
*Jan 31 14:01:21.163: %SYS-5-CONFIG_I: Configured from console by console

ROUTER_A#
ROUTER_A#show ip route ospf
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route, H – NHRP, l – LISP
+ – replicated route, % – next hop override

Gateway of last resort is 1.1.1.2 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O        10.2.2.0/24 [110/1001] via 192.168.12.2, 00:01:38, Tunnel0
ROUTER_A#

Cool, right?

Finally, our router’s configurations.

!
hostname ROUTER_A
!
crypto ikev2 proposal IKEv2_PROPOSAL
encryption aes-cbc-256 aes-cbc-192 3des
integrity sha512 sha256 md5
group 14 5 2
!
crypto ikev2 policy IKEv2_POLICY
proposal IKEv2_PROPOSAL
!
crypto ikev2 keyring IKEv2_KEYRING
peer ROUTER_B
address 1.1.1.2
pre-shared-key local keya-b
pre-shared-key remote keyb-a
!
crypto ikev2 profile IKEv2_PROFILE
match identity remote address 1.1.1.2 255.255.255.255
identity local address 1.1.1.1
authentication remote pre-share
authentication local pre-share
keyring local IKEv2_KEYRING
!
crypto ipsec transform-set IPSEC_TRANSFORM1 esp-aes 256 esp-sha512-hmac
mode tunnel
!
crypto ipsec profile IPSEC_PROFILE
set transform-set IPSEC_TRANSFORM1
set ikev2-profile IKEv2_PROFILE
!
interface Tunnel0
ip address 192.168.12.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Serial5/0
tunnel mode ipsec ipv4
tunnel destination 1.1.1.2
tunnel protection ipsec profile IPSEC_PROFILE
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
no ip route-cache
no shutdown
!
interface Serial5/0
ip address 1.1.1.1 255.255.255.0
no ip route-cache
no shutdown
!
ip route 0.0.0.0 0.0.0.0 1.1.1.2
ip route 10.2.2.0 255.255.255.0 Tunnel0
!
end

 

!
hostname ROUTER_B
!
crypto ikev2 proposal IKEv2_PROPOSAL
encryption aes-cbc-256 aes-cbc-192 3des
integrity sha512 sha256 md5
group 14 5 2
!
crypto ikev2 policy IKEv2_POLICY
proposal IKEv2_PROPOSAL
!
crypto ikev2 keyring IKEv2_KEYRING
peer ROUTER_B
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
!
crypto ipsec transform-set IPSEC_TRANSFORM1 esp-aes 256 esp-sha512-hmac
mode tunnel
!
crypto ipsec profile IPSEC_PROFILE
set transform-set IPSEC_TRANSFORM1
set ikev2-profile IKEv2_PROFILE
!
interface Tunnel0
ip address 192.168.12.2 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Serial5/0
tunnel mode ipsec ipv4
tunnel destination 1.1.1.1
tunnel protection ipsec profile IPSEC_PROFILE
!
interface FastEthernet0/0
ip address 10.2.2.1 255.255.255.0
no ip route-cache
no shutdown
!
interface Serial5/0
ip address 1.1.1.2 255.255.255.0
no ip route-cache
no shutdown
!
ip route 0.0.0.0 0.0.0.0 1.1.1.1
ip route 10.1.1.0 255.255.255.0 Tunnel0
!
end

 

Thanks for reading!

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

One Response to IKEv2 between IOS routers (SVTI – Static Virtual Tunnel Interface)

  1. Pingback: IKEv2 between IOS routers with certificate authentication | popravak

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