VPN: DEEP Dive into GRE over IPSec configuration, explanation, and very easy actually once you are familiar with GRE and IPSec!

OSPF_GRE_Over_IPSec2So this is very odd to me after going through the last two posts of GRE and IPSec configuration, however once I found good information, configuration was a breeze.


You do need the basic GRE Tunnel configurations plus a little extra, and you need a LOT less IPSec configuration, though I am sure there are ways to make it more complex and add configurations on top of it.

I took a step back, and took multi-area OSPF out of it, and just used the NBMA routers with a specified loopback as take the IPSec GRE tunnel.

First important thing to note, and this I’m sure changes once you spend more time with this, however from what I found that if you are using dynamic routing protocols you DO NOT want your traffic on either side participating in those that will take the VPN tunnel!

Dynamic routing protocols can help get the encrypted traffic from point A to point B by learning the path to the remote router (when traversing multiple routers), however you will want a static route with GRE over IPSec which you will see why!

(So I actually could have left OSPF off completely with this network, because all of the interfaces showed as connected, except our loopbacks which we couldn’t add)


So to begin the configuration, first we make our GRE Tunnel, just as we did before, with the addition of one command to start the tie back to IPSec:

R2(config)#int tu0
*Mar 31 00:11:11.825: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R2(config-if)#ip add
R2(config-if)#tunnel source s0/0
R2(config-if)#tunnel destination
*Mar 31 00:12:16.912: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R2(config-if)#tunnel mode ipsec ipv4

[Resuming connection 3 to r3 … ]

R3(config)#int tu0
*Mar 31 21:07:10.592: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R3(config-if)#ip add
R3(config-if)#tunnel source s0/2
R3(config-if)#tunnel destination
R2(config-if)#tunnel mode ipsec ipv4

*Mar 31 21:07:55.618: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R3(config-if)#do ping

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 156/159/168 ms

These commands break down to:

  • Creating the tunnel interface
  • Setting the IP Address / Network it belongs to ( /24)
  • Tunnel Source points at the WAN or Outbound interface
  • Tunnel Destination points at the Remote physical interface IP
  • Tunnel mode ipsec ipv4 tells GRE it will be using IPSec for communication
  • Once configured on both sides, ping the remote GRE IP to confirm connectivity

Notice that from the first router, as soon as you define an IP / Source / Destination for a Tunnel interface it is Up / Up. You will see it drop again throughout the configuration, but for the initial setup, that is a good behavior to know.

Next is some IPSec configs we know, such as Policy Creation, Pre-Shared Key creation, and define a Transform Set (no need to define a tunnel mode):

R2(config)#crypto isakmp policy 10
R2(config-isakmp)# encr 3des
R2(config-isakmp)# hash md5
R2(config-isakmp)# authentication pre-share
R2(config)#crypto isakmp key CCNP address
R2(config)#crypto ipsec transform-set VPNLAB ah-md5-hmac
[Resuming connection 3 to r3 … ]

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#crypto isakmp policy 10
R3(config-isakmp)# encr 3des
R3(config-isakmp)# hash md5
R3(config-isakmp)# authentication pre-share
R3(config)#crypto isakmp key CCNP address
R3(config)#crypto ipsec transform-set VPNLAB ah-md5-hmac

What a world of difference, no Crypto ACL’s / Crypto Maps / Lifetimes / Interface configuration / Etc. I won’t go through the above configurations as you should be familiar with these by now, and if not, you need to review this post.

However, there is one additional command that ties GRE and IPSec together, which I will demonstrate here:

R2(config)#crypto ipsec profile PROTECT
R2(ipsec-profile)#set transform-set VPNLAB
R2(ipsec-profile)#int tu0
R2(config-if)#tunnel protection ipsec profile PROTECT
*Mar 31 00:59:19.287: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

So almost immediately you see the IPSec ISAKMP turn on, however I think I jumped over to R3 too fast to catch Tunnel0 going down, however we do see it coming back up here:

R3(config)#crypto ipsec profile PROTECT
R3(ipsec-profile)#set transform-set VPNLAB
R3(ipsec-profile)#int tu0
R3(config-if)#tunnel protection ipsec profile PROTECT
*Mar 31 21:55:08.017: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
*Mar 31 21:55:10.437: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

So to break down these new commands:

  • The IPSec side of the commands: “crypto ipsec profile (word)” defines an IPSec profile, you will need a Transform-Set defined as it will drop you into profile mode to “set transform-set (name)” which I’ve color-coded to see where the transform-set name is derived from in the config
  • The GRE side of the commands: “tunnel protection ipsec profile PROTECT” defines the transform-set to be used to secure / encrypt data during transmission

Now here comes the tricky part to me, as there is no Crypto ACL, or Crypto Map to call out that ACL, and we aren’t applying a Crypto Map calling out a Crypto ACL on the outside facing interface – So how the heck do we define our interesting traffic?

I was able to ping, but no encaps / decaps from “sh cry ipsec sa” were incrementing. So what the answer? Static Routes!

Now this took some real attention to detail, and my brain is working at 25% today, so the struggle is real – But I found the correct syntax for your static routes:

R2(config)#ip route


R3(config)#ip route

I kept trying to use an exit interface of tu0, however, it needed the GRE Tunnels remote peer IP address.

I entered the outside IP of the router, the tunnel0 interface, nothing was working until I caught that – This is why you want to keep all routes using IPSec GRE tunnels out of dynamic routing protocols!

(Note that I did have to put static routes on R1 pointing to and because it was not learning them via a Dynamic routing protocol)

Once all of that was complete, I verified my work:

R3#ping source

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Packet sent with a source address of
Success rate is 100 percent (5/5), round-trip min/avg/max = 184/186/193 ms
R3#sh cry ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (
   remote ident (addr/mask/prot/port): (
   current_peer port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
    #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5

There is our encaps and decaps we want to see! Looking good!

R3#sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0       YES NVRAM  up                    up
FastEthernet0/1       YES NVRAM  up                    up
Serial0/2            YES NVRAM  up                    up
Serial0/3                  unassigned      YES NVRAM  administratively down down
Loopback3                 YES NVRAM  up                    up
Loopback33            YES manual up                    up
Tunnel0                  YES manual up                    up

Our Tunnel0 interface is Up/Up just how we want to see it, aaaaand:

R3#sh cry isa sa
dst             src             state          conn-id slot status    QM_IDLE           1001    0 ACTIVE

The Phase 1 portion of our tunnel is obviously happy as well if we are even getting to the point of encaps and decaps, so on all accounts we have success!!!

The nice thing about this is, really you can add networks via static route that can take this tunnel without any Crypto ACL’s defining the traffic, so it is much more scalable of a solution in my opinion with less configuration / things that can go wrong.

However, as I feel I have done my job here getting this to work, I’m not digging any further into this topic – Time to move onto greener pastures which I am not sure what yet but it will come in the form of another DEEP Dive soon 🙂

One final note that is VERY important for exam day:

If the route / network needs to be in a dynamic routing protocol, you may be tasked to leave it in their to propagate to other routers, and in this scenario you may need for example a Distribute-List to prevent the type 3 LSA Prefix from creating an OSPF route on the router. Be very careful to watch for this on exam day!!!

One thought on “VPN: DEEP Dive into GRE over IPSec configuration, explanation, and very easy actually once you are familiar with GRE and IPSec!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s