OSPF Neighbors Won't Form Over a VPN? Check These in Order

The tunnel is up, the interfaces sit in the same subnet, and OSPF still shows nothing. Most of the time the tunnel is fine and one OSPF requirement is not met. Work the five checks below in order and stop at the first one that fails.

Each check has a distinct symptom, which is why the order matters more than the list.

Check 1: is the link model right

A point-to-point interface and a shared multi-access network are different OSPF environments. Copying a broadcast-LAN configuration onto a tunnel is the most common mistake here. Set the network type the VPN implementation supports, usually point-to-point for a routed tunnel. Then confirm the platform agrees, because some implementations ignore or override the setting.

If the link model is wrong, nothing later in the list will help.

Check 2: are the packets allowed through

OSPFv2 is IP protocol 89, not a TCP or UDP port, so a firewall rule written for ports drops it silently. Hellos also go to multicast addresses, which a policy may not permit. Allow protocol 89 between the tunnel endpoints, then check whether the platform needs explicit neighbor statements.

A tunnel that passes pings and nothing else is a policy problem, not a routing one.

Check 3: do the neighbor parameters match

Area ID, hello and dead intervals, authentication and stub flags all have to agree. A mismatch usually leaves the neighbor stuck in a visible state rather than failing silently, which is useful. Compare the running configuration on both ends, not the intended one.

An MTU mismatch is the subtle one. It blocks database exchange at ExStart, so the neighbor never reaches Full.

Check 4: what does the state say

The state names the failure. Init means hellos are arriving but this router is not listed in them, which points at a one-way path or a multicast problem. Two-Way is normal on a broadcast segment with a non-DR neighbor and abnormal on a point-to-point link. ExStart or Exchange stuck means an MTU or database-description problem. Loading means link-state requests are not being answered.

Read the state before changing anything, because it eliminates most of the list.

show ip ospf neighbor prints the state, the neighbor address and the dead timer. Compare that timer against the hello interval on both sides: a dead interval four times the hello is normal, anything else is a mismatch. The state column is the fastest read on the whole page.

Check 5: what is actually advertised

A Full adjacency is not a route. Check which networks are originated, which are learned and which are installed in the routing table. A missing network statement or a redistribution policy that excludes the site prefix produces a healthy neighbor and an empty table.

Then test a host-level application and the return path, because a routing protocol does not open a firewall.

For IPv6, OSPFv3 has its own requirements and is not an address-family toggle on every OSPFv2 setting. Use the matching protocol and platform documentation. And if the connection is one fixed link, compare static routes before adding a control plane you have to operate.