This article explains “GRE over IPSec” tunnel basics and demonstrates how they provide secure, flexible transport between two Cisco routers separated by the public internet.
There are several ways to skin a cat. This particular cat will be skinned (evidently I’m not fond of cats) using “IPSEC Profiles”. I’ll talk about why in a moment, but first let’s take a step back.
What is GRE?
GRE is a very simple overlay used to make devices that are not adjacent, appear to be. This is useful for forming routing neighbors, as we discover in the video example.
GRE was conceived when security wasn’t the foremost concern; therefore we often ‘harden’ GRE tunnels with IPSec.
What is IPSec?
IPSec is a suite of protocols that provide a secure wrapper for sensitive data and ensures data integrity end-to-end. Traditionally IPSec only supported the encryption of unicast packets. This would render routing protocols like EIGRP very much broken; as EIGRP uses the multicast address 188.8.131.52 to form neighbors.
Luckily, with GRE-over-IPSec we get the best of both worlds.
GRE over IPSec
GRE over IPSec (sometimes called GREoIPSec or GRE-over-IPSec) is a technique that allows your data packets to remain unencrypted by forming a protective shield of IPSec encryption around the GRE session; keeping the ‘black hats’ from spying on in-transit data.
With IPSec VTIs (Virtual Tunnel Interfaces) we can actually establish EIGRP neighbors directly over an IPSec tunnel. It is trivial to do this using the tunnel mode ipsec ipv4 command under your tunnel interface. However, it is still common to see GRE over IPSec in the real world, and is where this article focuses.
What problems do “IPSec Profiles” solve?
Not too many years ago when we created new subnets at a site, we’d have to define them as “interesting traffic”. Basically this was an ACL, then we’d create a “crypto map” to apply the ACL to a physical interface.
It’s now considered a legacy method, but because it was the only method for many years it is still actively deployed. You’ll find a lot of documentation still refers to the old method.
The “IPSec Profile” is a tool we can use to avoid defining bespoke ACLs. IPSec profiles link our transform-set to a tunnel interface – so everything that traverses the tunnel gets encrypted. Cool, eh? Aside from being cool, it also reduces risk: we’re unlikely to ‘fat finger’ an access list if there isn’t one to… er, finger.
It also keeps the bigwigs happy because site-to-site connectivity is less complex to set up, therefore the business isn’t waiting on the network or security team.
GRE over IPSec Configuration – Video Example
In this scenario, Router A has discovered Router B’s LAN subnets (and vice versa) via EIGRP, over an unencrypted GRE tunnel.
Upon investigation, a network engineer discovers a lack of encryption applied to the tunnel. The engineer telnets to Router B, and takes captures of his login credentials in plain text. Shock, horror!
The engineer then implements GRE over IPSEC using IPSec profiles. This secures the data whilst also ensuring EIGRP remains functional over the IPSec encrypted GRE tunnel. A final packet capture gives us our proof.
Take a look at the video to see GRE-over-IPSec in action:
GRE over IPSec Configuration Steps
Here is the same configuration used in the video, displayed in copy-and-paste-friendly format.
crypto isakmp policy <policy number> authentication pre-share crypto isakmp key <password> address <peer public IP> crypto ipsec transform-set <set name> <encyption protocol> <authentication protocol> crypto ipsec profile <profile name> set transform-set <transform-set name> int tunnel <tunnel number> tunnel protection ipsec profile <profile name>
- Apply the configuration to both sites.
- The “crypto key” (password) must be identical on both routers.
- Routing will drop until the IPSEC is applied to both ends.
If you’d like to mock up a replica of my lab, use the files below to give you a head-start.
The topology diagram is located below:
Note: The “Internet” in this topology is just a regular router. No additional Internet Router configuration is necessary after the initial script is applied.
Full Configurations (Initial State – using GRE only)
Full Configurations (Final State – using GRE over IPSec)
This article explained how GRE over IPSec is used to provide secure, flexible tunneling between remote routers.
We discussed the advantages of using IPSec Profiles over legacy methods of creating secure tunnels, and applied this knowledge in a lab environment.
Finally, we demonstrated with packet captures that transit data was encrypted, highlighting the difference between pure GRE and GRE-over-IPSec tunnels.
I hope this helped you gain a better understanding of the technology, and that you’ve had some fun along the way.
Please let me know what you think in the comments, and be sure to subscribe to my YouTube channel writememTV