cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
991
Views
0
Helpful
14
Replies
Highlighted
Beginner

Routing over GRE IPSEC Tunnel

I've established a IPSEC GRE tunnel between two sites but cannot ping either end. I'm not seeing errors on the tunnel, it's up and active. The research I've done hasn't been helpful in my particular situation. I believe my ACL's are correct. My configs are attached. Can anyone help me with this?

 

Headend:

HeadendCapture.PNG 

 

Farend:

FarendCapture.PNG

 

Tunnel state:

State.PNG

 

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

Hello Sergey,

 

Did you try to remove tunnel protection configuration? 

View solution in original post

14 REPLIES 14
Highlighted
VIP Rising star

roharris33,

 

If you are sourcing your ping from another interface (not the GRE tunnel interface), then you need to have some sort of routing going on for the tunnel endpoints to learn of each other's interfaces. If you just try to ping the tunnel interface, does it succeed? If so, then you probably just need to enable dynamic routing on the tunnel interface and add your other interfaces into the process. 

Highlighted

Sergey,

 

Thanks for the reply. The source is the GRE tunnel interface. From my understanding the routing should be correct. 

 Headend:

headendroute.PNG 

 

Farend:

farendroute.PNG

Highlighted

Are you able to post the config so that we can review it?

Highlighted

roharris33,

 

Can you please show the output of show ip interface brief command from both routers and also show run interface tunnel1.

 

Highlighted

The configs are attached to the original post. I'll attach it to this post too just in case. Here are the requested show results.

 

Headend:

HeadendNext.PNG

 

Farend:

farendnext.PNG

Highlighted

Thanks for posting the configurations. Pinging from one end of the tunnel to the other end of the tunnel should be straightforward from a routing perspective since the destination address is in a connected subnet. I do have a couple of things to ask about and to suggest.

1) on farend you have a static route for 10.192.0.0 255.255.0.0 192.168.200.1. Why is this? That subnet is the subnet of the tunnel. So why have a static route? And why would the static route next hop be out the outbound interface when the subnet is a locally connected subnet. I suggest that you remove this from the config.

2) farend has the tunnel destination as 111.111.111.237. I assume that this is a disguise for the real address and that is ok. Can the farend router ping that address?

3) headend has policy based routing configured on the tunnel. I do not understand why and believe that it is flawed as configured. The PBR acl permits everything with a source address of the tunnel subnet to any destination. I do not understand why you would select traffic with the tunnel subnet. And I believe that the set ip default address is incorrect. It specifies the next hop as 192.168.100.97 which is the address of interface Gig0/0/0. At least as a test I suggest that you remove the PBR. Once we get the tunnel working correctly we can discuss whether you want to put PBR back in. But for now please remove it.

 

HTH

 

Rick

HTH

Rick
Highlighted

Richard,

 

That static route has a /16 subnet mask, so it is not the same as the tunnel network.

 

Highlighted

Hello Sergey,

 

Did you try to remove tunnel protection configuration? 

View solution in original post

Highlighted

ebarin,

The topic starter is roharris33, not me :)
Highlighted

Good catch about the mask of the static route. However that is a typo on my part. Checking the config again I see that the mask of the static route is really 255.255.255.0. I stand by my (corrected) comment that this static route makes no sense.

 

HTH

 

Rick

HTH

Rick
Highlighted

You're right, the static route is a hold over from testing. Not necessary at all. Interestingly a ISAKMP and IPSEC debug didn't provide much information. It was the NHRP dbug that provided the most information in regard to this issue.
Highlighted

Thanks for the confirmation that the static route was a holdover and is not necessary. I am not surprised that debug for isakmp and for ipsec was not very helpful and nhrp was crucial. If it is a standard GRE tunnel with ipsec, and especially if it is a tunnel VTI then isakmp and ipsec are important in bringing up the tunnel. But your tunnel is multipoint GRE (for DMVPN) and for this type of tunnel nhrp is the critical element. Glad to know that you have it sorted out.

 

HTH

 

Rick

HTH

Rick
Highlighted
Beginner

Have you tried using VTI instead of GRE over IPsec, will most likely make your configuration a bit simpler?

 

Theres helps of articles out there for it, but here is one i just found. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnips/configuration/zZ-Archive/IPsec_Virtual_Tunnel_Interface.html

 

I use it in my network to get rid of the need for GRE tunnels

Highlighted

Thanks for the info. I'll check it out.