Posts Tagged ‘Generic Routing Encapsulation’
Encrypted GRE Tunnels.
One thing to keep in mind about IPSec tunnels, is the fact they do not scale very. After all a simple IPSec tunnel will not pass multicast traffic so routing updates will not traverse the tunnel requiring you to either rely on RRI (Reverse route injection) or static routes. So how do we get over this little obstacle, we run a GRE tunnel. (I covered GRE tunnels a few posts back)
Now there are a few ways we can do this, the first is to run the GRE tunnel over the IPSec tunnel, in this case the tunnel destination is at the other end of the IPSec tunnel and is matched by the ACL of the IPSec tunnel to ensure the traffic between the tunnel endpoints are encrypted. Another way is to apply an IPSec profile to the GRE tunnel. Let’s check out the configuration:
You will notice some of these configurations will look verify familiar such as the ISAKMP policy and the transform-set. However there are a couple of differences you will notice, such as the absence of a crypto map a few new profiles and keyrings.
This configuration allows us to nest specific hosts and pre-shared keys to a specific keyring, that we will apply later on.
The ISAKMP profile is where we specify what end points should match this policy, as well as tie in the keyring we created earlier. Keep in mind we can have multiple PSK’s in a keyring and multiple match identity in the same ISAKMP profile. The ISAKMP profile will simply find the right PSK in the keyring for the specific match identity address in the ISAKMP profile.
Now we have the IPSec profile, this is pretty close to what the crypto map did. It ties in ISAKMP so it knows what peers to match with and also the transform-set for phase 2 negotiations. You will also see in here we can set our Perfect Forward Secrecy (PFS) level, if one is desired.
So now that we have everything we need all we need to do is apply our IPSec profile to the tunnel interface.
The 2 commands that make this happen are the tunnel mode ipsec ipv4 this tells the tunnel that it is going to be running in IPSec mode. The next command tunnel protection ipsec profile LabIPSecProfile is how tie in the IPSec profile we created early.
Now that we have a GRE with IPSec protection our GRE tunnel is secure from the eavesdropping eyes of the internet. This GRE tunnel also provides us a transport mechanism to carry multicast traffic so we can run a routing protocol over this connection providing us with a scalable solution for managing site-to-site VPNs and our routing infrastructure.
Let’s look at Generic Routing Encapsulation (GRE)
Generic Routing Encapsulation, not much to say about it, its generic right? Well, it’s pretty tough to find a network that does not utilize GRE tunnels in one way, shape, or form. Whether they are Encrypted GRE tunnels or GRE tunnels riding over IPSec tunnels for branch connectivity chances are GRE is being used somewhere in your network. After all GRE provides us with various features that traditional IPSec tunnels do not offer us. Such as allowing multicast traffic to traverse the tunnel providing us scalability with the use of a routing protocol. It provides us these features because of how it interacts with the IP packet, some people refer to GRE as a layer 3.5 protocol because of how it encapsulates the existing layer 3 IP packet.
Below we can see how GRE interacts with the IP packet:
Notice you can see two sets of IP address in that packet, the first set of IP addresses (10.0.0.1 & 10.0.0.2) are the tunnel addresses, the second set of addresses under the GRE header is the real data that was sent through the tunnel, and it’s simple ICMP echo request from 1.1.1.1 to 2.2.2.2.
And for a closer at the fields within the GRE encapsulation.
Also notice the protocol type at the bottom, GRE can be used to encapsulate more than just IP Packets SNA, IPX, Appletalk and quite a few others can also be encapsulated with GRE.
More information can be in RFC 2784 which explains the IP Packet fields in greater detail then I covered here.
Now, as far as how the configuration goes for a normal GRE tunnel goes it is fairly minimal:
However, there are a few things that can be a little rough to get the hang of at first. The first thing unlike physical interface you can declare tunnel interfaces from configuration mode and you can start at any number. Now like any other interface you will want to assign your tunnel its own IP address since these GRE tunnels operate around layer 3 they will need IP addresses on the same subnet so both tunnel interfaces can communicate. The only other requirements for configuring a GRE tunnel is specifying the tunnel source and the tunnel destination. The tunnel source can be a physical interface or an IP address just keep in mind the tunnel source needs to be local on the router. The tunnel destination is going to the address of the remote router you are terminating the tunnel to. You will want to make sure the tunnel source and tunnel destination configured have connectivity to each other since it is between these addresses the GRE tunnel will run over.
There you go, GRE in a nutshell!
CCIE or Null! 