IPSec (tunnel mode) Site-To-Site VPN (IKE V2) between two Cisco routers with dynamic routing (OSPF)

Now comes the next part in IPSec series. This time we will configure IPSec VPN between two Cisco routers. For phase-1 our underlying protocol will be IKEV2 and IPSec will be run in tunnel mode. And we will do the routing by using OSPF protocol.
Let's move on to our network topology - 

IPSec Tunnel Mode with IKEv2 and OSPF

 Even though the topology is straight forward, let's have a look at it. Traffic from 192.168.10.0/24 to 192.168.20.0/24 and vice versa will be encrypted by IPSec. For this example, we will assign IP address to our tunnel interface or VTIs. 192.168.30.0/30 network is reserved for that purpose. Then we have a loopback interface in each router which will be used as OSPF router-id.

Site-A-Rtr configuration

Assign IP address to the physical interface and loopback interface.

interface GigabitEthernet0/0
 ip address 172.16.51.1 255.255.255.0
!
interface GigabitEthernet0/7
 ip address 192.168.10.1 255.255.255.0
!
interface Loopback0
 ip address 192.168.5.1 255.255.255.255
!

For IKEv2 (phase-1) configuration, we need to configure a ikev2 keyring, ikev2 proposal, ikev2 policy and ikev2 profile. When these four configuration steps are done, we have a complete working phase-1 configuration based on IKEv2.

crypto ikev2 keyring Site-B_Ikev2Keyring
 peer Site-B_Peer
  address 172.16.51.2 --What is our peer address
  pre-shared-key test123 --The pre-shared key used for that peer
!
crypto ikev2 proposal Site-B_Ikev2Proposal 
 encryption aes-cbc-256 --Encryption algorithm
 integrity sha256  --Authentication algorithm
 group 15 --DH group
!
crypto ikev2 policy Site-B_Ikev2Policy 
 proposal Site-B_Ikev2Proposal --Binding the proposal with with policy
!
crypto ikev2 profile Site-B_Ikev2Profile
 match identity remote address 172.16.51.2 --Which peer is associated with the profile
 authentication local pre-share
 authentication remote pre-share
 keyring local Site-B_Ikev2Keyring --Which Keyring is used for phase-1 for the peer
 lifetime 80000 --Key lifetime
!

Now comes the IPSec (phase-2) configuration. It is almost same as before. Only one extra command is needed, where we associate the IKEv2 profile with the IPSec profile.

crypto ipsec transform-set Site-B_IpsecTransformSet esp-aes esp-sha256-hmac 
 mode tunnel
!
crypto ipsec profile Site-B_IpsecProfile
 set transform-set Site-B_IpsecTransformSet --Associating transform-set with profile
 set ikev2-profile Site-B_Ikev2Profile --Associating IKEv2 profile, the extra command
 set security-association lifetime seconds 70000
 set pfs group15
!
Now we will create the tunnel interface. This time around the tunnel interface will have it's own IP address. Then we will run ospf routing protocol over the tunnel interface.

The tunnel interface configuration -

interface Tunnel0
 description IPSec-Tunnel-To-Site-B
 ip address 192.168.30.1 255.255.255.252
 tunnel source 172.16.51.1
 tunnel destination 172.16.51.2 
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile Site-B_IpsecProfile
!

Now ospf routing configuration

router ospf 1
 router-id 192.168.5.1
 network 192.168.5.1 0.0.0.0 area 0
 network 192.168.10.0 0.0.0.255 area 0
 network 192.168.30.0 0.0.0.3 area 0
!         

Site-B-Rtr configuration

For Site-B-Rtr, the configuration is exactly same, just the IP addresses, proposal, policy, profile names etc. will be changed. Below is the full configuration from Site-B-Rtr -

interface GigabitEthernet0/0
 ip address 172.16.51.2 255.255.255.0
!
interface GigabitEthernet0/7
 ip address 192.168.20.1 255.255.255.0
!
interface Loopback0
 ip address 192.168.5.2 255.255.255.255
!
crypto ikev2 keyring Site-A_Ikev2Keyring
 peer Site-A_Peer
  address 172.16.51.1
  pre-shared-key test123
!
crypto ikev2 proposal Site-A_Ikev2Proposal 
 encryption aes-cbc-256
 integrity sha256
 group 15
!
crypto ikev2 policy Site-A_Ikev2Policy 
 proposal Site-A_Ikev2Proposal
!
crypto ikev2 profile Site-A_Ikev2Profile
 match identity remote address 172.16.51.1
 authentication local pre-share
 authentication remote pre-share
 keyring local Site-A_Keyring
 lifetime 80000
!
crypto ipsec transform-set Site-A_IpsecTransformSet esp-aes esp-sha256-hmac 
 mode tunnel
!
crypto ipsec profile Site-A_IpsecProfile
 set transform-set Site-A_IpsecTransformSet
 set ikev2-profile Site-A_Ikev2Profile
 set security-association lifetime seconds 70000
 set pfs group15
!
interface Tunnel0
 description IPSec-Tunnel-To-Site-A
 ip address 192.168.30.2 255.255.255.252
 tunnel source 172.16.51.2
 tunnel destination 172.16.51.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile Site-A_IpsecProfile
!
router ospf 1
 router-id 192.168.5.2
 network 192.168.5.2 0.0.0.0 area 0
 network 192.168.20.0 0.0.0.255 area 0
 network 192.168.30.0 0.0.0.3 area 0
!         

Verification

First we will have a look at the layer-3 status of the interface -

RTR-A#sh ip interface brief 
Interface                  IP-Address      OK?    Method Status     Protocol
GigabitEthernet0/0    172.16.51.1      YES  NVRAM  up          up      
GigabitEthernet0/7    192.168.10.1    YES  NVRAM  up          up      
Loopback0                192.168.5.1      YES  NVRAM  up          up      
Tunnel0                    192.168.30.1     YES NVRAM  up          up    

As layer-3 status looks good, then we can have a look at our routing table -

RTR-A#sh ip route ospf
Gateway of last resort is not set

      192.168.5.0/32 is subnetted, 2 subnets
O        192.168.5.2 [110/1001] via 192.168.30.2, 02:54:54, Tunnel0
O     192.168.20.0/24 [110/1001] via 192.168.30.2, 02:54:54, Tunnel0

Site-B's loopback network (192.168.5.2/32) and internal network (192.168.20.0/24) is in the routing table and those networks are learnt from OSPF.

With below commands we can also verify that traffic is encrypted and using proper phase-1 and phase-2 parameters (authentication, encryption, DH group, PFS etc.)

RTR-A#sh crypto ikev2 sa remote 172.16.51.2 detailed 

 IPv4 Crypto IKEv2  SA 



Tunnel-id Local                 Remote                fvrf/ivrf            Status 

1         172.16.51.1/500       172.16.51.2/500       none/none            READY  
      Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:15, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 80000/10557 sec
      CE id: 1003, Session-id: 2
      Status Description: Negotiation done
      Local spi: E92A796BFA9688DF       Remote spi: F7C86268F3372EF8
      Local id: 172.16.51.1
      Remote id: 172.16.51.2
      Local req msg id:  0              Remote req msg id:  2         
      Local next msg id: 0              Remote next msg id: 2         
      Local req queued:  0              Remote req queued:  2         
      Local window:      5              Remote window:      5         
      DPD configured for 0 seconds, retry 0
      Fragmentation not  configured.
      Extended Authentication not configured.
      NAT-T is not detected  
      Cisco Trust Security SGT is disabled
      Initiator of SA : No

RTR-A#sh crypto ipsec sa peer 172.16.51.2 detail

local crypto endpt.: 172.16.51.1, remote crypto endpt.: 172.16.51.2
     plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
     current outbound spi: 0x916C5D8(152487384)
     PFS (Y/N): Y, DH group: group15

inbound esp sas:
      spi: 0x90ADCEEF(2427309807)
        transform: esp-aes esp-sha256-hmac ,
        in use settings ={Tunnel, }
        conn id: 19, flow_id: SW:19, sibling_flags 80000040, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4247457/63182)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)


Debugging IKEv2 and IPSec

If we want to debug IKEv2 and IPSec transactions, we can use the below commands -

RTR-A#debug crypto condition peer ipv4 172.16.51.2
RTR-A#debug crypto ikev2 
RTR-A#debug crypto ipsec

If we want to get information regarding a crypto session for a specific remote peer, we can type the command below -

RTR-A#sh crypto session remote 172.16.51.2
Crypto session current status

Interface: Tunnel0
Profile: Site-B_Profile
Session status: UP-ACTIVE     
Peer: 172.16.51.2 port 500 
  Session ID: 3  
  IKEv2 SA: local 172.16.51.1/500 remote 172.16.51.2/500 Active 
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 
        Active SAs: 4, origin: crypto map

We can also reset the crypto session which will initiate the phase-1 and phase-2 negotiation from the beginning.

RTR-A#clear crypto session remote 172.16.51.2

And that's all for today. Next time around may be it is time for DMVPN or FLEXVPN. Until then stay tuned.

Location: Sundsvall, Sweden

Comments

Post a Comment

Popular posts from this blog

Fortigate firewall AAA Configuration for management with TACACS+ protocol and Cisco ISE

Image
In this blog I will write about how to implement AAA services in Fortigate firewalls using Cisco ISE as an authentication server with TACACS+ protocol. First good to know our limitations. AAA means - Authentication (supported by ISE TACACS+), Authorization (partially supported by ISE TACACS+; Fortigate implements Admin-Profiles; so what a user can/cannot do is defined locally in the firewall with "Admin Profiles"; ISE just instructs the firewall to allocate one of those profiles), Accounting (not supported; instead configure syslog to get accounting data, Fortigate firewalls generate syslog messages for configuration changes made by a user). Let's jump to our configuration. Our topology is very simple; one Fortigate firewall and Cisco ISE server connected with the same management network which looks like below -  01 - Network Topology We have a management network 192.168.199.0/24. The firewall is at  .230  and Cisco ISE is at  .49  IP address. We are running...
Read more

Stacking switches Part - VI (Dell OS10 VLT - Virtual Link Trunking)

Image
In this blog I will configure MLAG (multi chassis link aggregation) for Dell OS10 switches. As every other vendor choses a fancy name of their implementation of MLAG; Dell is no exception to this. Dell calls their implementation VLT - Virtual Link Trunking . Let's look at our network topology - Two Dell OS10 switches will run peering between them and will run VLT/MLAG between them. Two Debian 10 linux machine will be connected with LACP bonding with both switches. They will simulate the client connection. Our topology looks like below - 01 - Dell OS10 VLT Topology Let's look at some terminology before configuration - VLT peer – The two switches participating in VLT are peer to each other. In a VLT domain a maximum of two switches are allowed. VLT interconnect (VLTi) – VLTi synchronizes state information between VLT peers. It synchronizes layer 2 and layer 3 control-plane information. These state/control-plane information includes MAC table, ARP table, IPv6 neighbors etc. VLT ...
Read more

Network device configuration management with Oxidized (Basic)

Image
I always like to work with open source tools. As a network engineer, we need to maintain a device configuration management system where we take backup of configuration for different networking devices like routers, switches, firewalls etc. We want to have our backups ready so that we can restore a device configuration when a device fails or replace with new one or for auditing purpose to track recent configuration changes. Today I will talk about such a open source tools named - Oxidized. Interested readers can have a look at it's GitHub page . It is a network configuration management tool with support for diverse networking equipments. Oxidized is developed with programming language Ruby. It is very configurable, extensible and can be integrated with management tools like Librenms . I will do a two part blog about Oxidized. In this part I will cover basic setup of Oxidized and start taking configuration backup of networking equipments. Network Topology Our topology l...
Read more