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
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
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.
Traffic selectors in phase2 defeat the purpose of routing protocol. Leave the default (0/0<->0/0) when you use a protocol.
Agree with the last statement. The networks exchanged would not match the TS if you had any set. very easily overlooked.
PCNSE
NSE
StrongSwan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1547 | |
1030 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.