Scribd
Upload
1 views6 pages

09. GRE over IPsec

The document explains the configuration and operation of GRE over IPsec, which encrypts GRE encapsulated packets using IPsec. It details the setup for two Cisco IOS routers, R1 and R2, to establish EIGRP neighborship and secure communication between their loopback networks. The document also includes configuration commands, notes on encryption domains, and verification steps to ensure proper implementation of the GRE over IPsec tunnel.

Uploaded by

Kyaw Ye Htut
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
1 views6 pages

09. GRE over IPsec

The document explains the configuration and operation of GRE over IPsec, which encrypts GRE encapsulated packets using IPsec. It details the setup for two Cisco IOS routers, R1 and R2, to establish EIGRP neighborship and secure communication between their loopback networks. The document also includes configuration commands, notes on encryption domains, and verification steps to ensure proper implementation of the GRE over IPsec tunnel.

Uploaded by

Kyaw Ye Htut
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

GRE over IPsec – Configuration and Explanation

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

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.

You might also like