GRE over IPsec – Configuration and Explanation (CCIE Notes)


As GRE does not have its own mechanism to encrypt traffic it depends on IPsec for getting the encryption job done. The whole point of GRE over IPsec is to encrypt what is encapsulated by GRE.

In GRE over IPsec, the entire GRE encapsulated packet is encrypted with an IPsec header. The interesting traffic defined for IPsec encryption is the ‘GRE’ traffic between the source and destination, so the underlying payload is also encrypted along with the routing updates.

The goal is to establish EIGRP neighborship between two Cisco IOS routers R1 and R2 using the tunnel interface, exchange routes (loopback IPs) and make sure the communication takes place between the loopback networks. But allowing communication isn’t our only motive, we want to encrypt all traffic flowing between R1 and R2. That includes the routing information (EIGRP updates) sent over the internet and also the communication between the loopback networks.

Gre over IPsec

Configuration on R1:

interface fasthethernet 0/0
 ip address 10.1.101.1 255.255.255.0
!
interface loopback 0
 ip address 1.1.1.1 255.255.255.255
!
interface tunnel12
 ip address 192.168.12.1 255.255.255.0
 tunnel source 10.1.101.1
 tunnel destination 10.1.102.2
!
router eigrp 12
 network 1.1.1.1 0.0.0.0
 network 192.168.12.0
!
access-list 130 permit gre host 10.1.101.1 host 10.1.102.2
!
crypto isakmp key cisco123 address 10.1.102.2
crypto isakmp policy 10
 authentication pre-shared-key
 encryption des
 hash sha
 group 1
!
crypto ipsec transform-set esp-3des esp-3des esp-sha-hmac
!
crypto map out_map 10 ipsec-isakmp
 set peer 10.1.102.2
 set transform-set esp-3des
 match address 130
crypto map out_map local-address fastEthernet 0/0
!
interface fasthethernet0/0
 crypto map out_map

Configuration on R2:

interface fasthethernet 0/0
 ip address 10.1.102.2 255.255.255.0
!
interface loopback 0
 ip address 2.2.2.2 255.255.255.255
!
interface tunnel12
 ip address 192.168.12.2 255.255.255.0
 tunnel source 10.1.102.2
 tunnel destination 10.1.101.1
!
router eigrp 12
 network 2.2.2.2 0.0.0.0
 network 192.168.12.0
!
access-list 130 permit gre host 10.1.102.2 host 10.1.101.1
!
crypto isakmp key cisco123 address 10.1.101.1
crypto isakmp policy 10
 authentication pre-shared-key
 encryption des
 hash sha
 group 1
!
crypto ipsec transform-set esp-3des esp-3des esp-sha-hmac
!
crypto map out_map 10 ipsec-isakmp
 set peer 10.1.101.1
 set transform-set esp-3des
 match address 130
crypto map out_map local-address fastEthernet 0/0
!
interface fasthethernet0/0
 crypto map out_map

Notes:-

– GRE over IPsec encrypts the entire GRE encapsulated packet.

– Interface for IPsec tunnel – The IPsec tunnel can either be formed using the physical interface IP or using loopbacks. When using loopbacks, you need to make sure the peer endpoints have a route for the loopback. This can be achieved by running another routing protocol to advertise the loopbacks and then forming an IPsec tunnel using the loopback IP address. ‘crypto map out_map local-address loopback 0‘ needs to be configured so that when the tunnel is being negotiated it sources from its loopback address and the same is to be done on the other end peer.

– Encryption Domain – The encryption domain specified is always between the ‘tunnel source’ and ‘tunnel destination’ IP of the tunnel interface. In our case it is 10.1.101.1 to 10.1.102.2 for GRE traffic. The reason for this is that the source/destination of your GRE traffic/tunnel is the physical IP of the fa0/0 interface and you want all GRE encapsulated traffic to be encrypted. So matching the tunnel source and tunnel destination in your crypto map ACL does the work.

– Application of Crypto Map – The crypto map has to be applied on the interface where the route for the destination encryption domain is learnt. In our case the destination encryption domain is 10.1.102.2, and the route is learnt via fa0/0 interface, so the crypto map will be applied on fa0/0. Knowing where to apply the crypto map is essential because this can get a little tricky while configuring IPsec over GRE.

– In the verification section below, note the proxy identities in the IPsec SA. The encrypted traffic is for the tunnel source and tunnel destination IPs with protocol number 47, which is the assigned protocol number for GRE.

Verification on R1 and R2:

R1#show crypto ipsec sa peer 10.1.102.2

interface: FastEthernet0/0
 Crypto map tag: out_map, local addr 10.1.101.1

 protected vrf: (none)
 local ident (addr/mask/prot/port): (10.1.101.1/255.255.255.255/47/0)
 remote ident (addr/mask/prot/port): (10.1.102.2/255.255.255.255/47/0)
 current_peer 10.1.102.2 port 500
 PERMIT, flags={origin_is_acl,}
 #pkts encaps: 711, #pkts encrypt: 711, #pkts digest: 711
 #pkts decaps: 690, #pkts decrypt: 690, #pkts verify: 690

R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 ... Open

User Access Verification

Password: 
R2>


R2#sh crypto ipsec sa peer 10.1.101.1

interface: FastEthernet0/0
 Crypto map tag: out_map, local addr 10.1.102.2

 protected vrf: (none)
 local ident (addr/mask/prot/port): (10.1.102.2/255.255.255.255/47/0)
 remote ident (addr/mask/prot/port): (10.1.101.1/255.255.255.255/47/0)
 current_peer 10.1.101.1 port 500
 PERMIT, flags={origin_is_acl,}
 #pkts encaps: 725, #pkts encrypt: 725, #pkts digest: 725
 #pkts decaps: 700, #pkts decrypt: 700, #pkts verify: 700

R2#telnet 1.1.1.1 /source-interface loopback 0
Trying 1.1.1.1 ... Open

User Access Verification

Password: 
R1>

Captures:-

To capture traffic I ran a ping from 1.1.1.1 to 2.2.2.2 and below is the wireshark capture showing encrypted traffic only. We aren’t seeing any EIGRP hellos or the ping traffic being differentiated and with this we can conclude that everything under a GRE over IPsec VPN is encapsulated by GRE and then encrypted by IPsec.

Gre over IPsec Capture

You can compare the above captures with the captures of IPsec over GRE. There is also a similar detailed post on IPsec over GRE which can be helpful to understand the difference between the two ways GRE can be configured with IPsec.

Bookmark to follow my CCIE Security v4 journey -> https://networkology.net/ccie-security/

Advertisements

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