Different approaches to IPSec Communication between Cisco Routers

This is my first post on my new blog, and I’ll start by examining some different approaches to enable IPSec communication between Cisco Routers, starting from the oldest one to the most recent ones.

Scenario Schermata 2014-11-05 alle 21.38.37

R1 and R2 are connected with their FastEthernet 0/0 interfaces. We simulate two LANs on each router with the interface FastEthernet 0/1 (which is connected to nothing, but has the no keepalive statement activated in order to keep it up as if it was connected). Routers have also a Loopback 0 defined and it’s used as router-id for OSPF routing protocol, which in turn is used between the two routers to have full IP reachability of the above aforementioned interfaces.

Requirement: enable secure communication over the link between the two routers between LAN 10.1.0.1/24 and 10.2.0.1/24.

Note about ESP encryption: I’ve used null encryption in order to allow me to do packet traces with Wireshark and show you the encapsulated headers.

1. Using CRYPTO MAP on Fa0/0 interface for policy-based IPSec Encryption

The first method consists in applying a crypto-map on Fa0/0 instructing the router to encrypt the traffic that matches the PROXIES ACL that sets the remote and local proxy to 10.1.0.0/24 and the remote proxy to 10.2.0.0/24 on R1 and vice versa on R2. The two encryption peers are 172.16.0.1 and 172.16.0.2.

R1 configuration 

crypto isakmp policy 1
 encr aes
 hash sha256
 authentication pre-share
 group 2
crypto isakmp key cisco address 172.16.0.2
!
crypto ipsec transform-set TSET esp-null esp-sha-hmac
!
crypto map CMAP 1 ipsec-isakmp
 set peer 172.16.0.2
 set transform-set TSET
 match address PROXIES
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 172.16.0.1 255.255.255.252
 crypto map CMAP
!
interface FastEthernet0/1
 ip address 10.1.0.1 255.255.255.0
 no keepalive
!
router ospf 1
 network 1.1.1.1 0.0.0.0 area 0
 network 10.1.0.1 0.0.0.0 area 0
 network 172.16.0.1 0.0.0.0 area 0
!
ip access-list extended PROXIES
 permit ip 10.1.0.0 0.0.0.255 10.2.0.0 0.0.0.255

R2 configuration

crypto isakmp policy 1
 encr aes
 hash sha
 authentication pre-share
 group 2
crypto isakmp key cisco address 172.16.0.1
!
crypto ipsec transform-set TSET esp-null esp-sha-hmac
!
crypto map CMAP 1 ipsec-isakmp
 set peer 172.16.0.1
 set transform-set TSET
 match address PROXIES
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 172.16.0.2 255.255.255.252
 crypto map CMAP
!
interface FastEthernet0/1
 ip address 10.2.0.1 255.255.255.0
 no keepalive
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 10.2.0.1 0.0.0.0 area 0
 network 172.16.0.2 0.0.0.0 area 0
!
ip access-list extended PROXIES
 permit ip 10.2.0.0 0.0.0.255 10.1.0.0 0.0.0.255

Now, a ping from 10.1.0.1 to 10.2.0.1 works and is being encrypted by IPSec, using tunnel mode, which adds a new IP header with the Fa0/0 addresses between the ESP packet that contains the original IP packet with the Fa 0/1 addresses:

Schermata 2014-11-05 alle 21.40.12

2. Using a GRE IP Tunnel for route-based IPSec Encryption

This second approach involves the creation of a GRE IP Tunnel between the two routers, using Fa 0/0 IPs as tunnel source and destinations. In this case we change the PROXIES ACLs in order to match only GRE traffic between 172.16.0.1 and 172.16.0.2. This is a route-based approach since we determine with routing which traffic is going to be encrypted, by sending the traffic to be encrypted over Tunnel 0 with a static route for the two Fa0/1 LANs that wins over the same route known through OSPF. I’ll post only the relevant configuration:

R1 configuration 

! New Tunnel interface
!
interface Tunnel0
 ip address 172.31.0.1 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 172.16.0.2
end
! 
! Modified PROXIES ACL
!
ip access-list extended PROXIES
 permit gre host 172.16.0.1 host 172.16.0.2
!
! Route traffic for 10.2.0.0/24 over Tunnel 0
!
ip route 10.2.0.0 255.255.255.0 Tunnel0

R2 configuration

! New Tunnel interface
!
interface Tunnel0
 ip address 172.31.0.2 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 172.16.0.1
end
! 
! Modified PROXIES ACL
!
ip access-list extended PROXIES
 permit gre host 172.16.0.2 host 172.16.0.1
!
! Route traffic for 10.1.0.0/24 over Tunnel 0
!
ip route 10.1.0.0 255.255.255.0 Tunnel0

The transform set TSET is using default IPSec mode, i.e. Tunnel mode:

crypto ipsec transform-set TSET esp-null esp-sha-hmac

This produces a redundant encapsulation, since GRE and IPSec tunnel endpoints are the same:

Schermata 2014-11-05 alle 21.57.31 We can avoid this double encapsulation by using IPSec transport mode (if you change it, the quickest way to reset security associations is to shutdown and activate the Tu 0 interfaces):

crypto ipsec transform-set TSET esp-null esp-sha-hmac
 mode transport

This removes the redundant header: Schermata 2014-11-05 alle 23.03.12

3. Using GRE Tunnel with tunnel protection for route-based IPSec Encryption

In this section we will obtain the same encapsulation that we’ve got in previous section but without using a crypto-map applied to the FastEthernet 0/0 interface. This time we use the newer approach which applies IPSec tunnel protection to the GRE tunnel. This time we’ll define an IPSEC profile to be applied to the tunnel, which in turn uses an ISAKMP profile with the ISAKMP secret specified within a keyring.

Assuming interfaces and routing is configured as in the previous examples, I’ll post only the Fa0/0 and Tu0 interfaces configuration and all the crypto-related configuration statements, so you can assume that everything about cryptography is posted in the following code snippet:

R1 configuration

interface FastEthernet0/0
 ip address 172.16.0.1 255.255.255.252
 duplex auto
 speed auto
end
!
interface Tunnel0
 ip address 172.31.0.1 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 172.16.0.2
 tunnel protection ipsec profile IPSEC_PROFILE
end
! 
crypto keyring KEYRING
 pre-shared-key address 172.16.0.2 key cisco
crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
crypto isakmp profile ISAKMP_PROFILE
 keyring KEYRING
 match identity address 172.16.0.2 255.255.255.255
crypto ipsec transform-set TSET esp-null esp-sha-hmac
crypto ipsec profile IPSEC_PROFILE
 set transform-set TSET
 set isakmp-profile ISAKMP_PROFILE

R2 configuration

interface FastEthernet0/0
 ip address 172.16.0.2 255.255.255.252
 duplex auto
 speed auto
end
!
interface Tunnel0
 ip address 172.31.0.2 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 172.16.0.1
 tunnel protection ipsec profile IPSEC_PROFILE
end
!
crypto keyring KEYRING
  pre-shared-key address 172.16.0.1 key cisco
crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
crypto isakmp profile ISAKMP_PROFILE
   keyring KEYRING
   match identity address 172.16.0.1 255.255.255.255
crypto ipsec transform-set TSET esp-null esp-sha-hmac
crypto ipsec profile IPSEC_PROFILE
 set transform-set TSET
 set isakmp-profile ISAKMP_PROFILE

As we’ve already seen in the previous section, this produces a redundant IP encapsulation because both GRE and ESP create two new IP headers with source and destination IPs the Fa 0/0 interfaces’ IPs:

Schermata 2014-11-06 alle 20.30.32

To remove this redundant encapsulation and save some bytes, just use IPSEC in transport mode:

crypto ipsec transform-set TSET esp-null esp-sha-hmac
 mode transport

This removes the redundant header:

Schermata 2014-11-06 alle 20.33.14

4. Using IPSEC IPv4 Tunnel with tunnel protection for route-based IPSec Encryption

In the last approach, we use IPSec Encryption without using GRE tunneling, such as in section 1, but we use a route-based approach (as opposed to the policy-based encryption we examined at the beginning of this post). This can be accomplished by changing tunneling mode to ipsec ipv4 (I’ll show only Tunnel 0 configuration since everything else is the same as in section 3):

R1 configuration

interface Tunnel0
 ip address 172.31.0.1 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 172.16.0.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC_PROFILE
end

R2 configuration

interface Tunnel0
 ip address 172.31.0.2 255.255.255.252
 tunnel source FastEthernet0/0
 tunnel destination 172.16.0.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC_PROFILE
end

This time, specifying tunnel mode transport does not force IPSEC to use transport mode, since tunnel mode is needed to encapsulate the inner IP packet which carries the ping from R1 to R2 and vice versa. I’ve left the tunnel mode transport statement in the transform set, but the IPSEC security association is negotiated with tunnel mode:

R1#show crypto ipsec sa
interface: Tunnel0
 Crypto map tag: Tunnel0-head-0, local addr 172.16.0.1
 protected vrf: (none)
 local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
 remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
 current_peer 172.16.0.2 port 500
 PERMIT, flags={origin_is_acl,}
 [...]
 local crypto endpt.: 172.16.0.1, remote crypto endpt.: 172.16.0.2
 [...]
 inbound esp sas:
 spi: 0xF99762A5(4187447973)
 transform: esp-null esp-sha-hmac ,
 in use settings ={Tunnel, }
 [...]
 outbound esp sas:
 spi: 0x89CCFDC2(2311912898)
 transform: esp-null esp-sha-hmac ,
 in use settings ={Tunnel, }
 [...]

In the output above, you can also see that local and remote identities (the proxies specified in section 1) are 0.0.0.0/0, since we encrypt everything that we route over the Tunnel 0 interface. On the contrary, when you’re using policy-based IPSec encryption, the local and remote identities are the networks specified within the PROXIES ACL:

R1#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: CMAP, local addr 172.16.0.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.1.0.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.2.0.0/255.255.255.0/0/0)

This produces the following encapsulation:

Schermata 2014-11-06 alle 21.13.45

Conclusion

In my first post we’ve gone through different approaches to solve a simple task, encrypt all the communications between two LANs, starting from the policy-based solution with the crypto-map applied to the Fa0/1 interfaces, and going through three route-based solutions: the first route-based solution still uses a crypto-map and negotiates the tunnel endpoints as local and remote identities, since the tunnel simply encapsulates all the traffic that is sent over it, but it is the crypto map that does the encryption and it must know which traffic it must encrypt. The last two solutions negotiate 0.0.0.0/0 as local and remote identities since it is the tunnel interface itself that does the encryption, to all the traffic that is sent over it.

This post has been an exercise for me to experiment with IPSec tunnels and I hope someone will find the post useful. Feel free to post comments or to contact me, I don’t know if I’ll have time to reply, but you can try if you want 🙂

Advertisements
This entry was posted in Networking and tagged , , , , , , , . Bookmark the permalink.

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