IPSec (tunnel mode) Site-To-Site VPN (IKE V1) between two Cisco routers

Today we will configure IPSec VPN between two Cisco routers. For phase-1 our underlying protocol will be IKE V1 and IPSec will be run in tunnel mode. In our previous example, the Cisco router was configured using policy mode.

What is actually the difference between IPSec - policy mode and tunnel mode? I will describe the difference in layman's terms. In policy mode, when to do the packet encryption is done by selecting appropriate traffic by means of ACLs (access control list) and we cannot run dynamic routing protocols over the tunnel. But in tunnel mode - we create a tunnel interface, packet encryption is done by routing (routes which have next-hop as tunnel interface will be encrypted) and we can easily run dynamic routing protocols over tunnel interface. The most obvious difference is that in tunnel mode we will create a VTI (virtual tunnel interface) over which our encrypted traffic will be forwarded.

 Let's move on to our network topology - 
IPSec Tunnel Mode VPN Topology


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 not assign any IP address to our tunnel VTIs. 192.168.30.0/30 network is reserved for a future example. If anyone is interested to test the setup with IP address assigned to the tunnel interface, they can surely use the above /30 network and achieve the same result. In our case we will be using "ip unnumbered" command from Cisco IOS.

Now we will configure our routers.

Site-A-Rtr configuration

Assign IP address to the physical interface.

interface GigabitEthernet0/7
 ip address 192.168.10.1 255.255.255.0
!
interface GigabitEthernet0/0
 ip address 172.16.51.1 255.255.255.0

Create the phase-1 policy.

crypto isakmp policy 10
 authentication pre-share
 encr aes --Encryption algorithm
 hash sha256 --Authentication algorithm
 group 14 --DH group
 lifetime 80000 --Key lifetime

Configure the pre-shared key for the IPSec peer.

crypto isakmp key test123 address 172.16.51.2 --Pre-shared key for the peer  

Configure phase-2 policy/transform-set.

crypto ipsec transform-set Transform-Site-B esp-aes esp-sha256-hmac
 mode tunnel --Phase-2 uses encryption AES and authentication SHA256

Instead of using crypto-map, we will create a IPSec profile and associate the transform-set with it.

crypto ipsec profile Profile-Site-B
 set transform-set Transform-Site-B --Associating transform-set with profile
 set pfs group14 --Uses PFS with DH group 14
 set security-association lifetime seconds 70000 --Key lifetime

Now we will create the tunnel interface. Important thing here is that the tunnel must have an IP address, we can assign an IP address to it or borrow an IP address from another interface using "ip unnumbered" command. Otherwise our static route for selecting which traffic will be encrypted will not come into the routing table.

interface Tunnel0
 description IPSec-Tunnel-To-Site-B
 tunnel mode ipsec ipv4 --Tunnel is ipsec encrypted, carries IPv4 payload
 tunnel protection ipsec profile Profile-Site-B --IPSec profile association
 tunnel source 172.16.51.1
 tunnel destination 172.16.51.2
 ip unnumbered GigabitEthernet0/0 --Borrowing an IP adress from GE0/0

Now we will select which traffic will be encrypted by means of creating a static route which has tunnel interface as outgoing interface.
ip route 192.168.20.0 255.255.255.0 Tunnel0

Site-B-Rtr configuration

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

interface GigabitEthernet0/7
 ip address 192.168.20.1 255.255.255.0
!
interface GigabitEthernet0/0
 ip address 172.16.51.2 255.255.255.0
!
crypto isakmp policy 10
 authentication pre-share
 encr aes
 hash sha256
 group 14
 lifetime 80000
!
crypto isakmp key test123 address 172.16.51.1    
!
crypto ipsec transform-set Transform-Site-A esp-aes esp-sha256-hmac 
 mode tunnel
!
crypto ipsec profile Profile-Site-A
 set transform-set Transform-Site-A 
 set pfs group14
 set security-association lifetime seconds 70000
!
interface Tunnel0
 description IPSec-Tunnel-To-Site-A
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile Profile-Site-A
 tunnel source 172.16.51.1
 tunnel destination 172.16.51.2
 ip unnumbered GigabitEthernet0/0
!
ip route 192.168.20.0 255.255.255.0 Tunnel0
! 

Verification
Let's start our verification -

We will send a simple ping command from Site-A-PC (192.168.10.2) to Site-B-PC (192.168.20.2).

S-A-PC> ping 192.168.20.2

 84 bytes from 192.168.20.2 icmp_seq=1 ttl=62 time=4.521 ms
84 bytes from 192.168.20.2 icmp_seq=2 ttl=62 time=4.451 ms
84 bytes from 192.168.20.2 icmp_seq=3 ttl=62 time=4.427 ms

We can see that our ping is going through. Now we will find out why the ping is going through. We will run some diagnostic command from Site-A-Rtr -

Site-A-Rtr#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0    172.16.51.1     YES manual up                    up      
GigabitEthernet0/7    192.168.10.1   YES manual up                    up      
Tunnel0                    172.16.51.1     YES TFTP     up                    up      

We can see that our tunnel interface is "UP" and it is using GE0/0's IP address because of the "ip unnumbered" command.

Site-A-Rtr#show ip route 
Gateway of last resort is not set

       172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.51.0/24 is directly connected, GigabitEthernet0/0
L        172.16.51.1/32 is directly connected, GigabitEthernet0/0
      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.10.0/24 is directly connected, GigabitEthernet0/7
L        192.168.10.1/32 is directly connected, GigabitEthernet0/7
S     192.168.20.0/24 is directly connected, Tunnel0

Our static route to Site-B network (192.168.20.0/24) is also in the routing table.

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.)

Site-A-Rtr#show crypto isakmp sa detail 
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       T - cTCP encapsulation, X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption
IPv4 Crypto ISAKMP SA

 C-id   Local              Remote          Status    Encr  Hash       Auth  DH 

1001  172.16.51.1   172.16.51.2    ACTIVE  aes    sha256   psk    14 


Site-A-Rtr#show crypto ipsec sa detail 

      local crypto endpt.: 172.16.51.1, remote crypto endpt.: 172.16.51.2
     plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
     current outbound spi: 0xF240396C(4064295276)
     PFS (Y/N): Y, DH group: group14

      inbound esp sas:
      spi: 0x70695424(1885951012)
        transform: esp-aes ,
        in use settings ={Tunnel, }
        conn id: 7, flow_id: SW:7, sibling_flags 80004070, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4282358/69852)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

      inbound ah sas:
      spi: 0x6ED23B7A(1859271546)
        transform: ah-sha256-hmac ,
        in use settings ={Tunnel, }
        conn id: 7, flow_id: SW:7, sibling_flags 80004070, crypto map: Tunnel0-head-0
        sa timing: remaining key lifetime (k/sec): (4282358/69852)
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

So, above example is called IPSec tunnel mode where we have a IPSec encapsulated tunnel interface and the routing is done over that interface.

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