← IKEv2 between two IOS routers (crypto map way)

IKEv2 between IOS routers with certificate authentication →

IKEv2 between IOS routers (SVTI – Static Virtual

Tunnel Interface)
Posted on January 31, 2015by Sasa

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:

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!

https://popravak.wordpress.com/2011/11/07/cisco-ios-vpn-filter/