OSPF Neighbors Hung in INIT State via GRE/IPsec tunnel

[Brian Reed]

I have a backup router scenario for my remote sites I'm trying to build and test.  The remote site router has an IPsec tunnel to an ASA 5510 facilitated via crypto map applied to a fastethernet interface which is attched directly to a DSL modem and get its IP address via DHCP from the modem.  I have a second tunnel that is IPsec protected GRE that is bound to a loopback interface with the tunnel end point terminating in a VRF on the router.  The second tunnel connects to a 2901 on the inside of the ASA with a loopback, VRF, and tunnel termination configured the same as the remote.  The second tunnel is created between the two routers through the ASA, and show  crypto isakmp sa and sho crypto ipsec sa confirms this.  debug ip ospf hello, debug ip ospf events and debug ip ospf adj show hello packets between the two routers.  However the routers never form a full adjaceny and never move beyond the INIT state.  The MTU on the physical interface of the remote router connected to the ISP is 1468.  The MTU on the tunnel at both ends is 1372. I have tried ajusting them lower with change in the adjacency state.

Now, this exact scenary works perfectly for my remote site routers attached to a T1 and communicating with the 2901 via our MPLS WAN with no ASA in the middle and no pre-formed IPsec tunnel to traverse.  Cisco TAC ASA team states the tunnel to the ASA is configured properly and all traffic is passing through that tunnel as it should being that I am allowing all IP through the tunnel and ACL configured for non-split tunneling.  I can't seem to find where the ospf adjacency negotiation is breaking.  Has anyone configured a scenario like this before?

2901-----ASA-----1921  IPsec to the ASA, then IPsec protected GRE to the 2901 with a VRF and OSPF router configured for the tunnel networks

I can provide configs and visio's.

Thanks to everyone - Brian.              

[lgijssel]

You do need neighbor statements to build the ospf relation.

Multicast hello's cannot be sent over ipsec.

Guess you thought of that though.

regards,

Leo

[AJ Cruz]

Is it stuck in INIT on both ends? Kind of interesting. If the router wasn't receiving hellos it would be stuck in the DOWN state. INIT means it receives hellos, but the hellos do not contain the receiving router's own router id (OSPF's way of acknowledging hellos). So it sounds like the hello goes through one way but either the router isn't acknowledging the hello (not likely) or something (say a firewall) is blocking the "return" hello.

Sent from Cisco Technical Support iPad App

[Brian Reed]

Only the 1921 is stuck in INIT.  The 2901 has no state for the neighbor relationship.  Debugs on the 1921 show hellos received from the 2901 and sent.  The 2901 never sees the hellos from the 1921.  Yes, there is an ASA 5510 in between with an IPsec tunnel that facilitates connectivty to the corporate network for the 1921.  That connectivity allows the second tunnel connection between the 1921 and the 2901, the 2901 being on the inside of the ASA.  I opened a case with TAC and the VPN engineer says the ASA is not the issue.  They opened an case with the router group and they started labbing up the scenario with my configs on Thursday but I haven't heard from them.  Thanks!!!

[Brian Reed]

Both loopbacks are numbered interfaces.  Thanks!

[smitesh kharecha]

H Brian,

In GRE over IPSEC, if tunnel on one end is unnumber loopback and on another end it is numberred, it will never shows your the routes. Change the both ends to unnumbered or both ends to numbbered...

HTH,

Smitesh

PS: Please rate helpful post...

[Brian Reed]

I worked with TAC for almost 4 hours on Monday and we determined this configuration is not technically valid and not supported.  The functional challenge is routing a protected mode GRE tunnel through and interface which already has a crypto map applied to it for a Lan to Lan tunnel that must be up before the protected mode tunnel can even communicate with the router on the other end.  I'm searching now for some post or documentation that explains what happens in this case to prevent the second tunnel from forwarding traffic.  I will have to explain why this configuration will not work and right now I don't have any further information other than it just won't.  If you are aware of any documentation it would be greatly appreciated if you share.

Thanks for everyones input!