Last updated on January 28, 2022
Blog ITA - Post 1
Complexity [ scale of 1 to 5 ]
4/5
Configurazione di una IPSec IKEv2 Site-to-Site VPN (VRF-Aware) attraverso l'uso di Static Virtual Tunnel Interfaces
Premessa
L’articolo nasce a seguito di una chiacchierata tecnica avuta con un caro collega e mentore – Andrea Virdi – sul tema IPSec S2S VPN.
In questo scenario si colloca questa mia breve digressione sulle VRF-Aware SVTIs tra due router Cisco (facendo ricorso al protocollo IKEv2).
Definizione di VTI
La Virtual Tunnel Interface (VTI) – introdotta nella release 12.3(14)T del Cisco IOS – e’ una interfaccia virtuale che supporta nativamente l’ IPsec tunneling.
Principali caratteristiche di una VTI:
- e’ una routable interface (feature quali load balancing e high availability sono affidate al routing protocol a cui si fa ricorso)
- supporta pre-encryption QoS
- supporta IPmc encryption (encryption del traffico multicast)
- non dispone di un interface keepalive (paragonabile al GRE keepalive tanto caro a molti network engineer. Anche in questo caso, ci si affida a meccanismi intrinseci al routing protocol utilizzato)
Le VTI possono essere configurate:
- Staticamente (SVTI) –> oggetto di questo articolo
- Dinamicamente (DVTI)
Topologia di Riferimento
Riporto qui in basso la topologia ricreata in laboratorio:
Alcune considerazioni:
- la VRF denominata “UNDERLAY” e’ la transport VRF (address-family ipv4)
- la VRF denominata “OVERLAY” e’ la overlay VRF (address-family ipv6)
- eBGP peering configurato tra le due VTI. L’advertisement delle loopback interfaces avviene – attraverso BGP – all’interno del tunnel
- le loopback interfaces hanno lo scopo di simulare il cosiddetto “interesting traffic”, ovvero il traffico che fluisce all’interno dell’IPSec tunnel. L’instradamento dei pacchetti avviene sulla base delle informazioni di routing presenti nella VRF denominata “OVERLAY”
- assegnazione degli indirizzi IPv4 conforme al RFC5737
- assegnazione degli indirizzi IPv6 conforme al RFC3849
- assegnazione degli AS number conforme al RFC5398
Configurazione
Step1 – Definizione delle VRF
Router R11
vrf definition OVERLAY
rd 64501:6
!
address-family ipv6
exit-address-family
!
vrf definition UNDERLAY
rd 64501:4
!
address-family ipv4
exit-address-family
Router R22
vrf definition OVERLAY
rd 64502:6
!
address-family ipv6
exit-address-family
!
vrf definition UNDERLAY
rd 64502:4
!
address-family ipv4
exit-address-family
Step2 – Configurazione dei parametri richiesti da IKEv2 ed IPSec
Sono sei le sezioni da configurare:
- IKEv2 Proposal
- IKEv2 Policy
- IKEv2 Keyring
- IKEv2 Profile
- IPSec Transform Set
- IPSec Profile
Il setup di R11 verra’ presentato in forma compatta.
Attraverso R22, invece, andremo ad isolare i comandi relativi ad ognuna delle sei sezioni sopra citate.
Router R11
crypto ikev2 proposal prop-1
encryption aes-cbc-256
integrity sha512
group 24
!
crypto ikev2 policy policy-1
match fvrf UNDERLAY
match address local 198.51.100.1
proposal prop-1
!
crypto ikev2 keyring keyring-1
peer R22
address 198.51.100.2 255.255.255.252
hostname R22
pre-shared-key PrSh_key2183
!
!
crypto ikev2 profile IKEv2-Profile-1
match fvrf UNDERLAY
match identity remote address 198.51.100.2 255.255.255.252
authentication local pre-share
authentication remote pre-share
keyring local keyring-1
!
crypto ipsec transform-set transform-1 esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile IPSEC-Profile-1
set transform-set transform-1
set ikev2-profile IKEv2-Profile-1
Router R22
## IKEv2 Proposal
crypto ikev2 proposal prop-1
encryption aes-cbc-256
integrity sha512
group 24
## IKEv2 Policy
crypto ikev2 policy policy-1
match fvrf UNDERLAY
match address local 198.51.100.2
proposal prop-1
## IKEv2 Keyring
crypto ikev2 keyring keyring-1
peer R11
address 198.51.100.1 255.255.255.252
hostname R11
pre-shared-key PrSh_key2183
## IKEv2 Profile
crypto ikev2 profile IKEv2-Profile-1
match fvrf UNDERLAY
match identity remote address 198.51.100.1 255.255.255.252
authentication local pre-share
authentication remote pre-share
keyring local keyring-1
## IPSec Transform Set
crypto ipsec transform-set transform-1 esp-aes 256 esp-sha-hmac
mode tunnel
## IPSec Profile
crypto ipsec profile IPSEC-Profile-1
set transform-set transform-1
set ikev2-profile IKEv2-Profile-1
Step3 – Configurazione delle interfacce dei router
Router R11
interface Loopback0
vrf forwarding OVERLAY
no ip address
ipv6 address 2001:DB8:DC11::1/128
!
interface Tunnel1
vrf forwarding OVERLAY
no ip address
ipv6 address FE80::1 link-local
ipv6 address 2001:DB8:ABCD::1/64
tunnel source 198.51.100.1
tunnel destination 198.51.100.2
tunnel key 777
tunnel vrf UNDERLAY
tunnel protection ipsec profile IPSEC-Profile-1
!
interface GigabitEthernet0/0
vrf forwarding UNDERLAY
ip address 198.51.100.1 255.255.255.252
Router R22
interface Loopback0
vrf forwarding OVERLAY
no ip address
ipv6 address 2001:DB8:DC22::1/128
!
interface Tunnel1
vrf forwarding OVERLAY
no ip address
ipv6 address FE80::2 link-local
ipv6 address 2001:DB8:ABCD::2/64
tunnel source 198.51.100.2
tunnel destination 198.51.100.1
tunnel key 777
tunnel vrf UNDERLAY
tunnel protection ipsec profile IPSEC-Profile-1
!
interface GigabitEthernet0/0
vrf forwarding UNDERLAY
ip address 198.51.100.2 255.255.255.252
Step4 – Configurazione di BGP nell’overlay VRF
Router R11
router bgp 64501
bgp router-id 203.0.113.11
bgp log-neighbor-changes
no bgp default ipv4-unicast
!
address-family ipv6 vrf OVERLAY
network 2001:DB8:DC11::1/128
neighbor 2001:DB8:ABCD::2 remote-as 64502
neighbor 2001:DB8:ABCD::2 activate
exit-address-family
Router R22
router bgp 64502
bgp router-id 203.0.113.22
bgp log-neighbor-changes
no bgp default ipv4-unicast
!
address-family ipv6 vrf OVERLAY
network 2001:DB8:DC22::1/128
neighbor 2001:DB8:ABCD::1 remote-as 64501
neighbor 2001:DB8:ABCD::1 activate
exit-address-family
Test di funzionalita’
Per verificare lo stato del tunnel, utilizziamo i seguenti comandi:
R11#show crypto ikev2 sa
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
1 198.51.100.1/500 198.51.100.2/500 UNDERLAY/OVERLAY READY
Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:24, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/19387 sec
R11#show crypto session remote 198.51.100.2 detail | b Int
Interface: Tunnel1
Profile: IKEv2-Profile-1
Uptime: 05:29:12
Session status: UP-ACTIVE
Peer: 198.51.100.2 port 500 fvrf: UNDERLAY ivrf: OVERLAY
Phase1_id: 198.51.100.2
Desc: (none)
Session ID: 21
IKEv2 SA: local 198.51.100.1/500 remote 198.51.100.2/500 Active
Capabilities:(none) connid:1 lifetime:18:30:48
IPSEC FLOW: permit 47 host 198.51.100.1 host 198.51.100.2
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 631 drop 0 life (KB/Sec) 4230388/933
Outbound: #pkts enc'ed 632 drop 0 life (KB/Sec) 4230388/933
Dal router R11, effettuiamo un ping test verso la loopback interface del router R22, verificando che il traffico fluisca correttamente all’interno del tunnel IPSec:
R11#sh ipv6 route vrf OVERLAY bgp | i DC22
B 2001:DB8:DC22::1/128 [20/0]
## Prima di effettuare il ping
R11#show crypto ipsec sa detail | i local|remote|encaps|decaps
Crypto map tag: Tunnel1-head-0, local addr 198.51.100.1
local ident (addr/mask/prot/port): (198.51.100.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (198.51.100.2/255.255.255.255/47/0)
#pkts encaps: 643, #pkts encrypt: 643, #pkts digest: 643
#pkts decaps: 642, #pkts decrypt: 642, #pkts verify: 642
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
local crypto endpt.: 198.51.100.1, remote crypto endpt.: 198.51.100.2
R11#ping vrf OVERLAY ipv6 2001:DB8:DC22::1 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 2001:DB8:DC22::1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 4/5/7 ms
## Dopo aver effettuato il ping
R11#show crypto ipsec sa detail | i local|remote|encaps|decaps
Crypto map tag: Tunnel1-head-0, local addr 198.51.100.1
local ident (addr/mask/prot/port): (198.51.100.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (198.51.100.2/255.255.255.255/47/0)
#pkts encaps: 743, #pkts encrypt: 743, #pkts digest: 743
#pkts decaps: 742, #pkts decrypt: 742, #pkts verify: 742
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
local crypto endpt.: 198.51.100.1, remote crypto endpt.: 198.51.100.2
Risulta evidente che:
- gli encaps/decaps counter sono incrementati a seguito del ping test
- encaps failed = 0
- decaps failed = 0
Il tunnel funziona correttamente !