Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
topcu
New Contributor III

No OSPF neighborship on VPN-Tunnel. What's wrong?

Hello all,

I have trouble, getting an OSPF neighborship running through a VPN-Tunnel, and hope to get some ideas here. My test scenario is the following (s. picture appended): Two FWF60E connected via Point-to-Point Link on root VDOM, simulating the WAN-connection. A Test VDOM, that has access networks and a VPN tunnel to the opposite FN and OSPF routing enabled. The tunnel is routed via a VDOM Link to the root VDOM (as an virtual WAN Interface) and a static host route to the opposite Interface. There are not any other routes configured, because they should be learned via OSPF. The Test VDOM should not learn any routes from the root VDOM.

Both devices are configured symmetrically. Everything works fine. The tunnel is running an I can ping the opposite tunnel interface. The policy implicitly permits everything on all interfaces for test purposes. But no OSPF neighborship is established. The debug sniffer output shows that the local FN is sending OSPF Hellos to 255.0.0.5, source IP Tunnel Interface, as expected. But no hellos arrive at any side. Testequipment: FWF60E, v5.6.5

Any ideas whats wrong with the configuration? May the multicast address be an issue?

Many thanks in Advance!  Hakan

4 REPLIES 4
Toshi_Esumi
Esteemed Contributor III

My best guess is the other side is actually receiving hellos but don't show up in sniffing because NPU offload is working. When you sniff it, try disabling auto-asic-offload on the pair of policies that are handling the tunnel traffic.

Then another guess is MTU size might be somehow different both ends. Make sure you set the same mtu at ospf-interface config on both sides explicitly.

topcu
New Contributor III

Many thanks! But the MTU was not an issue. Meanwhile we found out, that the configured Phase 2 Selectors did not include the Multicast IP-Address. After changing them to 0.0.0.0/0.0.0.0 the OSPF neighborship came up and routes are exchanged correctly.

Toshi_Esumi
Esteemed Contributor III

Traffic selectors in phase2 defeat the purpose of routing protocol. Leave the default (0/0<->0/0) when you use a protocol.

emnoc
Esteemed Contributor III

Agree with the last statement. The networks exchanged would not match the TS if you had any set. very easily overlooked.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Labels
Top Kudoed Authors