Generic Routing Encapsulation (GRE) Simplied for Network Pro

Encapsulation is a kind of  mechanism that transport packets of one type of protocol within another protocol. The protocol that is been carried is called as the Passenger Protocol, and the protocol that is used for carrying the passenger protocol is called as the Transport Protocol.

Generic Routing Encapsulation (GRE) is light weight tunneling mechanisms which uses IP as the transport protocol and can be used for carrying many different passenger protocols (such as IP, IPX, AppleTalk etc). 

GRE  tunnels can be visualized as virtual point-to-point links that have two endpoints identified by the tunnel source and destination addresses at each endpoint. 

It is important to understand that GRE tunnels do not encrypt traffic in any way; they are simply encapsulate within an additional GRE and IP header. If a secure tunnel is required, IPSec can be used with GRE to provide data confidentiality.

What is the difference between VPN and GRE?

GRE and VPN both are tunneling mechanism providing a method of connecting remote networks virtually over the public network.

There are Pros & Con's with GRE and VPN which we will see next.

VPN provide a more secure way for traffic to communicate over the public network i.e. encrypts traffic that is sent across the link

GRE tunnels simply encapsulate the traffic before sending it over the link. However, VPN tunnels come with several disadvantages as well. 

VPN configurations must include statically maintained ACL's to identify traffic allowed through the tunnel. This can become a tedious process and less feasible job for larger networks. Discontinuous subnets require separate tunnels.

VPNs do not create routable interfaces, which means certain actions that could be taken on other interfaces cannot be taken on VPN tunnels.

VPNs do not allow multicast traffic to pass, therefore dynamic routing protocols, such as RIP and OSPF, are no longer options to use across VPN. 

GRE tunnels allows a way to get around VPN shortcomings. 

GRE tunnels have no limitation on the types of traffic which can traverse it, that mean it can carry any type of protocol packet thru it. It can route multiple subnets without multiple tunnels requirement. Also, it creates a routable interface hence routing protocols can operate across it. However, as mentioned above, it is not very secure hence we need to  keep in mind that GRE over IPSec tunnels are different from stand-alone IPSec VPN tunnels.

Comparison Chart

Where do we use GRE tunnels?

1. You could implement a GRE tunnel to connect two similar type of network thru a different type of intermediate network for e.g. AppleTalk networks connected through an IP-only network, such requirement are very less likely these days.
2. To route IPv4 packets across a network that only uses IPv6 this appears to be one more interesting reasoning to use GRE's these days.
3. When we need to forward data from dis-contiguous networks through a single tunnel since VPNs has some constraints.
4. When we need to forward multicast traffic.
5. When we need to provide transportation of multi-protocol local networks over a single-protocol backbone.
6. Provides a workaround for networks that contain protocols with limited hop counts such as routing of RIP over larger hop count.
7. Configure VPNs between the Router for WAN connectivity over public network.

Routing Protocol Consideration

Several routing protocols can be used over a P2P GRE over IPsec VPN, including EIGRP and OSPF.

EIGRP is recommended as the routing protocol because of its conservative use of router CPU and network bandwidth as well as its quick convergence times. 

EIGRP also provides a range of options for address summarization and default route propagation.

Routing protocols do increase the CPU utilization on a network device, and this impact must be considered when sizing those devices.

IP Multicast Consideration

Scalability testing with IP multicast and IPSec encryption indicates that there are issues with packet loss, because of the instant replication of many packets. IP multicast replication happens at a single moment in time. The replication occurs before encryption, meaning that the crypto cards or engines in the various platforms can be overwhelmed if a large number of spokes joins the same IP multicast stream. 

For example, consider a design using the Cisco Catalyst 6500 with VPN SPA module, and configuring 1000 P2P GRE over IPSec tunnels to branch offices. If each branch office is joined to a single IP multicast stream, the VPN SPA must replicate each IP multicast packet 1000 times, one per VPN tunnel. Assuming the Sup720 can sustain the replication speed of the stream, many packets (up to 1000) arrive at the input queue of the VPN SPA, causing overruns or dropped packets. 

Firewall Considerations for GRE over IPSec.

Depending on the crypto and P2P GRE hub or branch placements, the following protocols and ports are required to be allowed: 
• UDP Port 500        — ISAKMP as source and destination 
• UDP Port 4500     — NAT-T as a destination 
• IP Protocol 50       — ESP 
• IP Protocol 51        — AH (if AH is implemented) 
• IP Protocol 47        — GRE (if GRE traverses the firewall post decryption) 
• Any potential end user traffic—If GRE does not traverse the firewall post            encapsulation.

Below is the procedure for enabling GRE over IPSec.

1. First enable internet connectivity by implementing NAT on both routers. 
2. Configure GRE and test connectivity. Non-encrypted traffic should flow between the private networks. 
3. Add IPSec to the configuration and test connectivity. The traffic between the private networks should be encrypted. 
4. Add the Cisco IOS Firewall to the external interfaces, the outbound inspect list and inbound access list, and test connectivity. 
5. If you use a Cisco IOS Software release earlier than 12.1.4, you need to permit IP traffic between 172.16.1.x and - 10.0.0.0 in access list 103. 

Configure NAT to enable internet connectivity.

!
hostname R1
!
!--- This is the internal interface.
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
 ip nat inside
 speed 100
 full-duplex
!
!--- This is the external interface.
interface FastEthernet0/1
 ip address 1.1.1.1 255.255.255.248
 ip nat outside
 speed 100
 full-duplex
!
!--- Define the NAT pool.
ip nat pool ourpool 1.1.1.10 1.1.1.20 netmask 255.255.255.248
ip nat inside source route-map nonat pool ourpool overload
!
!---Define default route
ip classless
ip route 0.0.0.0 0.0.0.0 1.1.1.2
!

!--- See point no.5 in above section if you use a Cisco IOS
!--- Software release earlier than 12.1.4 for access list 103.

access-list 175 deny   ip 10.0.0.0 0.0.0.255 172.16.1.0 0.0.0.255

access-list 175 permit ip 10.0.0.0 0.0.0.255 any
!
!--- Use access list in route-map to address what to NAT.
route-map nonat permit 10
 match ip address 175
!
-----------------------------------------------------------
!
hostname R2
!
!--- This is the internal interface.
interface FastEthernet0/0
ip address 172.16.1.2 255.255.255.0 
 ip nat inside
 speed 100
 full-duplex
!
!--- This is the external interface.
interface FastEthernet0/1
 ip address 2.2.2.1 255.255.255.248
 ip nat outside
 speed 100
 full-duplex
!
!--- Define the NAT pool.
ip nat pool ourpool 2.2.2.10 2.2.2.20 netmask 255.255.255.248
ip nat inside source route-map nonat pool ourpool overload
!
!--- Define default route
ip classless
ip route 0.0.0.0 0.0.0.0 2.2.2.2
!
!--- See point no.5 in above section if you use a Cisco IOS

!--- Software release earlier than 12.1.4 for access list 103.

access-list 175 deny ip 172.16.1.0 0.0.0.255 10.0.0.0 0.0.0.255
access-list 175 permit ip 172.16.1.0 0.0.0.255 any 
!
!--- Use access list in route-map to address what to NAT.
route-map nonat permit 10
 match ip address 175
!

Test internet connectivity

R1#ping 2.2.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

------------------------------------------------------------

Configure GRE and test connectivity

To maintain simplicity below snippet is shown for router 1 only you can do necessary changes (swapping of IP's) to replicate the configuration on router 2.

!--- This is end "A" of the GRE tunnel.
interface Tunnel0
ip address 192.168.3.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
!
!--- Associate the tunnel with the physical interface.
tunnel source FastEthernet0/1
tunnel destination 2.2.2.1
!
!--- This is the external interface associated to end "A" of the GRE tunnel.
interface FastEthernet0/1
ip access-group 103 in
!
!
!--- Allow IPSec and GRE traffic between the private networks.
access-list 103 permit gre host 2.2.2.1 host 1.1.1.1
!

Test Connectivity

R1#ping 2.2.2.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

-------------------------------------------------------

Configure IPSec

Configuring IPSec encryption involves two steps for each router. These steps are as follows:
1. Configure ISAKMP (Phase 1)
2. Configure IPSec (Phase 2)

IKE exists only to establish SAs (Security Association) for IPSec. Before it can do this, IKE must negotiate an SA (an ISAKMP SA) relationship with the peer.
To begin, we’ll start working on R1 and then eventually need to replicate the same on R2

First step is to configure an ISAKMP Phase 1 policy:

!--- This is the ISAKMP Phase 1 configuration.

crypto isakmp policy 10

 encryption 3des

 hash md5

 authentication pre-share

 group 2

lifetime 86400

!

!--- define a pre shared key for authentication with R1's

!--- peer, 2.2.2.1

crypto isakmp key ciscokey address 2.2.2.1

!

Second step is to configure IPSec Phase 2 policy:

!--- need to create the transform set used to protect our data.

!--- We’ve named this to_R2

crypto ipsec transform-set to_R2 esp-des esp-md5-hmac 

!

crypto map myvpn 10 ipsec-isakmp 

set peer 192.168.2.2

set transform-set to_R2 

match address 101

!

!--- If you are running a version of IOS Software Release earlier

!--- than 12.2.15 then the crypto map must be applied to the tunnel !--- interface as well as the physical interface.

!

interface FastEthernet0/1

crypto map myvpn

!

!--- Force the private network traffic into the tunnel.

ip route 172.16.1.0 255.255.255.0 192.168.3.2

!

!--- All traffic that enters the GRE tunnel is encrypted by IPsec.

!--- Other ACE statements are not necessary.

access-list 101 permit gre host 192.168.1.1 host 192.168.2.2

!

!--- Access list for security reasons. Allow

!--- IPsec and GRE traffic between the private networks.

access-list 103 permit esp host 192.168.2.2 host 192.168.1.1

access-list 103 permit udp host 192.168.2.2 eq isakmp host 192.168.1.1

access-list 103 deny   ip any any log

!

Test Connectivity

R1# ping 172.16.1.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

---------------------------------------------------------

Add the Cisco IOS Firewall to the external interfaces

!

ip inspect name myfw tcp

ip inspect name myfw udp

ip inspect name myfw ftp

ip inspect name myfw realaudio

ip inspect name myfw smtp

ip inspect name myfw streamworks

ip inspect name myfw vdolive

ip inspect name myfw tftp

ip inspect name myfw rcmd

ip inspect name myfw http

ip audit notify log

ip audit po max-events 100

!

!

interface FastEthernet0/1

ip inspect myfw out

!

!

--------------------------------------------------

Verification

Below are the commands to be used for verifying the what ever configuration we did untill now.

First try to ping a host in the remote subnet -10.0.0.0/24 from a host in the 172.16.1.0/24 network in order to check the VPN configuration. This traffic should go through the GRE tunnel and be encrypted. 

Use the show crypto ipsec sa command to verify that the IPSec tunnel is up. First check that the SPI numbers are different than 0. You should also see an increase in the pkts encrypt and pkts decrypt counters. 

• show crypto ipsec sa - Verifies that the IPSec tunnel is up.
• show access-lists 103 - Verifies that the Cisco IOS Firewall configuration works correctly.
• show ip nat translations - Verifies that NAT works properly.

• show crypto session Verify if encryption is in place and it works

Troubleshooting

• debug ip nat access-list number —Displays information about IP packets translated by the IP NAT feature.
• debug crypto ipsec - Displays IPsec events.
• debug crypto isakmp - Displays messages about Internet Key Exchange (IKE) events.
• debug crypto engine - Displays information from the crypto engine.
• debug ip inspect {protocol | detailed}- Displays messages about Cisco IOS Firewall events.
• debug ip packet (with no ip route-cache on the interface)—Displays general IP debugging information and IP security option security transactions.

Security Risks of GRE Tunnels:

1. Lack of Encryption: By default, GRE tunnels do not provide encryption, meaning data is transferred in clear text and could be intercepted56.
2. Dependence on Additional Protocols for Security: To secure data, GRE tunnels often rely on additional protocols like IPSec53.
3. GRE tunnels are designed to be completely stateless. This means that each tunnel endpoint does not keep any information about the state or availability of the remote tunnel endpoint.
4. Spoof Attack - Since the GRE protocol does not have any built-in mechanisms for authentication, attackers can easily impersonate legitimate endpoints to gain access to the network and carry out malicious activities such as stealing sensitive information or launching cyberattacks.
5. Denial-of-service (DoS) attacks - An attacker can flood a network with excessive traffic targeted at a particular endpoint, causing it to be overwhelmed and unable to process legitimate requests. This can lead to disruption of critical services, loss of productivity, and potential financial losses due to downtime.