OSPF stuck in INIT over GRE tunnel with IPsec

[jonmo2578]

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]

Thanks for the all the latest suggestions guys..

Rolf..… your previous post sums up my problem exactly.. ospf and hellos all good until I add ipsec config.. In answer to some of your earlier questions..  yes, the tunnels end points are still pingable throughout this whether we use static ospf statements or our usual P2P setup..

Jawad.... thanks for that link.. I came across this thread too and was also confused by the suggested fix.. Im open to trying it later if no further progress but our 3900 router is brand new out the box and the "clear ip ospf process " would  effectively be the same as rebooting the router which we have done ?.. Also, I have managed to establish other ( unencrypted ) tunnels to this router since which would not happen if this was a problem ?..

Paul.... thanks for joining this discussion.. the static ospf statements was to prove this would work via unicast.. I think I did see in some other thread that multicast hellos 224.0.0.5 may not work over encrypted tunnels, so this was to test if the ospf statements made any difference…. Ran into the same problem again, where ospf was fine unencrypted but everything falls over when we stick on the ipsec on the tunnel.

Ive ended up labbing this up with a spare 2800 and made the setup as simple as possible with no ACLs blocking 224.0.05 ( which we don't have anyway on live config )..

When debugging, hello pkts are seen on both hub and spoke routers so 224.0.0.5 is making it through..

When encrypted.. 224.0.0.5 replys from SPOKE to HUB are not making it back..

The tunnel source is coming from an ATM interface, over DSL using a dialler setup on the SPOKE end…

My plan for tests today..

May not be an issue, but just to rule out any funniness over the 3rd party dsl provider, Im gonna directly patch a 2800, 2900 and possibly our spare 3900 to our live HUB router to see if that makes any difference.

After that, I will have a go at your larger pkt, df option and control plane suggestions Rolf..

Will feed back my results later today..

Thanks all.

Jon.

[paul driver]

Hello,

The tunnel source is coming from an ATM interface, over DSL using a dialler setup on the SPOKE end…

Is the broadcast keyword specifed in the dailer-map statement?

Also have you tested this using standard crypto-maps statements instead of VTI's and excluding 224.0.0.5 in an acl from being encrypted?

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[jonmo2578]

Hmm.. interesting.. so I tried connecting my 2800 directly into a spare port on the VPN head router.

Configured up a /30 between the two ethernet ports ( to simulate the service provider )

and then set up a new tunnel over the top..

it works with ipsec encyption on the tunnel ?!!.

Ospf adj came up right away.

Now this would point to something weird going on over dsl connection.. however, we have used the same dsl connection to our 3700 router and that succesfully gets ospf adj with encryption !!.

Anyway, at least this proves encryption on tunnel to the Cisco 3900 works..

Weird..

Our dsl connection is configured as follows on the SPOKE router..

interface ATM0/3/0

no ip address

ip flow ingress

no ip route-cache cef

load-interval 30

carrier-delay msec 150

no atm ilmi-keepalive

pvc test 0/38

  tx-ring-limit 3

  encapsulation aal5mux ppp dialer

  dialer pool-member 1

interface Dialer1

ip address negotiated

ip information-reply

ip directed-broadcast

encapsulation ppp

tx-ring-limit 3

tx-queue-limit 3

dialer pool 1

dialer-group 1

ppp chap hostname ********

ppp chap password ******

Have also tried pointing the ATM setup to a virtual-template as oppose to using a Dialer.. still get the same problem with ospf adj..

***

Regarding the mtu sizes.. I ran a ping test between the tunnels addresses earlier..

Standard pings between tunnels were fine..

however when adding 'df'.. i had to use..

ping 10.180.51.134 size 1300 df  ... in order for it to work on both ends.

Ive had since amended the mtu and mss adjust size on our tunnels to 1300/1236..