OSPF stuck in INIT over GRE tunnel with IPsec

jonmo2578 · ‎08-13-2013

Hi there,

Im having problems re-establishing ospf adj over a GRE tunnel as soon as I apply any ipsec configuration onto it..

Ive seen a few threads covering similar problems but not found a solution yet..

When the tunnel is set up without any ipsec configuration, ospf adj successfully comes up

Spoke end ( Cisco 2800 )

interface Tunnel5111

ip address 10.180.51.134 255.255.255.252

no ip redirects

ip mtu 1438

ip pim query-interval 1

ip pim sparse-mode

ip virtual-reassembly

ip ospf network point-to-point

ip ospf hello-interval 1

ip ospf dead-interval 3

tunnel source 84.x.x.x

tunnel destination 81.x.x.x

Head end. ( Cisco 3900 )

interface Tunnel5111

ip address 10.180.51.133 255.255.255.252

no ip redirects

ip mtu 1438

ip pim query-interval 1

ip pim sparse-mode

ip virtual-reassembly in

ip ospf network point-to-point

ip ospf dead-interval 3

ip ospf hello-interval 1

tunnel source 81.x.x.x

tunnel destination 84.x.x.x

As soon as I apply the following ipsec configuration, OSPF adj falls over..

tunnel mode ipsec ipv4

tunnel protection ipsec profile ipsec-test

The spoke end then gets stuck in an OSPF state of INIT

RTR#sh ip ospf ne

Neighbor ID Pri State Dead Time Address Interface

10.10.12.3 0 INIT/ - 00:00:02 10.180.51.133 Tunnel5111

but the Head end router does not see any OSPF state at all to the spoke.

Reading various threads, this would indicate that the router is receiving Hellos but not getting the router ID.. to progress to EXSTART..

Both routers can ping either end on the source and destination addresses… 84.x.x.x. and 81.x.x.x

Also both routers can ping the other end of their tunnel, 10.180.51.133 and 134

Have tried creating two different tunnels now to the 3900 router and both encounter the same problem.

To confuse matters, if I set up the tunnel to our older 3700 VPN head router using exactly the same config with ipsec enabled on the tunnel, OSPF adj does come up !!..

although I did have to lower the mtu value to 1438 for it to establish.

So to me, this says that this should work using ipsec over the tunnel ?

Has anyone encounter this problems before and managed to solved it.

Any help would be much appreciated..

Thanks.

Jon.

jonmo2578 · ‎08-15-2013

More to add to this after a few more days testing various suggestions..

Increasing the hello and dead intervals to default values has no effect.. On debuging ip ospf hellos, we are seeing Hellos sent from the hub ( 3900 ) to the spoke ( 2800 ) and the spoke replying back but this is not received back on the 3900

Hub. ( sends out hellos but gets nothing back )

OSPF-100 HELLO Tu5111: Send hello to 224.0.0.5 area 51 from 10.180.51.133

repeats

Spoke ( recieves hellos and sends reply but does not reach Hub )

OSPF: Send hello to 224.0.0.5 area 51 on Tunnel5111 from 10.180.51.134

OSPF: Tunnel5111: Interface state change to UP, new ospf state P2P

OSPF: Tunnel5111: Route adjust notification: UP/UP

OSPF: Rcv hello from 10.10.12.3 area 51 from Tunnel5111 10.180.51.133

OSPF: Send immediate hello to nbr 10.10.12.3, src address 10.180.51.133, on Tunnel5111

OSPF: Send hello to 224.0.0.5 area 51 on Tunnel5111 from 10.180.51.134

OSPF: End of hello processing

OSPF: Send hello to 224.0.0.5 area 51 on Tunnel5int tunnel 5111

OSPF: Send hello to 224.0.0.5 area 51 on Tunnel5111 from 10.180.51.134

OSPF: Rcv hello from 10.10.12.3 area 51 from Tunnel5111 10.180.51.133

OSPF: Send immediate hello to nbr 10.10.12.3, src address 10.180.51.133, on Tunnel5111

OSPF: Send hello to 224.0.0.5 area 51 on Tunnel5111 from 10.180.51.134

Also, have tried setting this up with static ospf statements and have ran into the same problem, where ospf adj comes up across the tunnel without and encryption but as soon as I apply any ipsec config the SPOKE router goes to INIT status and the HUB does not see anything..

So this works...

interface Tunnel5111 ( at spoke end )

ip address 10.180.51.134 255.255.255.252

no ip redirects

ip mtu 1438

ip pim query-interval 1

ip pim sparse-mode

ip virtual-reassembly

ip tcp adjust-mss 1374

ip ospf network non-broadcast

ip ospf priority 0

tunnel source 8.x.x.x

tunnel destination 81.x.x.x

But adding this breaks it..

tunnel mode ipsec ipv4

tunnel protection ipsec profile ipsec-test

You'd think that this would point to a problem with the crypto config.. but it works fine from Cisco 2800 -> 3700.. weird..