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.
Thanks for the share! very helpful! I’m kind of confused. Is this ipsec over gre tunnel or gre over ipsec tunnel? Can you please explain? Thanks in advance
BR
April 18, 2012 at 10:57 AM
HI Stephen. Thanks for sharing this topic. I am getting confused between ipsec over gre vs gre over ipsec. in your example would that be gre over ipsec? Can you please explain? Thanks in advance.
BR
April 18, 2012 at 10:59 AM
According to this document here: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008048cffc.shtml#t7
Using a crypto map on a physical interface and applying tunnel protection to the actual VTI accomplish the exact same thing, they are just two different ways of accomplishing the same thing.
So it is still considered GRE over IPSec, because the data is encapsulated in the tunnel before the actually IPSec encryption is applied to the packet.
Hope this clears it up.
Stephen J. Occhiogrosso
April 28, 2012 at 8:56 PM
[…] For a more in depth look at these commands refer to my older post Encrypted GRE tunnels. […]
Configuring DMVPN. « Another networking blog
August 13, 2012 at 10:22 AM
You’ll have a bad time if the tunnel is not used for an extended period of time as you do not have keep-alives – Also, in the current config you cannot use keep-alives because you have opted to use tunnel protection instead of a cryptomap – Just my 2 cents 🙂
Dave
May 29, 2015 at 3:14 AM