Configure and verify OSPF on Sophos Firewall

OSPF automatically exchanges IPv4 routes between routers. This is useful when multiple sites, redundant paths, or frequently changing networks become too cumbersome to maintain with static routes.

In the following example, two Sophos Firewalls establish an OSPF adjacency over a dedicated transit network. At the end, the neighbor is Full, Firewall A knows the LAN behind Firewall B, and vice versa. OSPFv3 is configured separately for IPv6.

⚠️ OSPF should run only on designated, trusted transit or VPN interfaces. Do not enable Dynamic Routing indiscriminately for LAN and WAN zones, and do not enable Redistribute connected until it is clear which directly connected networks this will advertise.

OSPF in seven steps

The following steps are required for a simple OSPFv2 connection:

Address the transit interfaces and verify direct IP reachability.
Under Administration > Device access, allow Dynamic Routing for a dedicated transit zone or through a tightly restricted Local Service ACL Exception.
Under Routing > OSPF, enter a unique Router ID on each firewall.
Create Area 0.0.0.0 as Normal.
Under Networks, assign the local transit network to Area 0.0.0.0.
Advertise only the LAN routes that are actually required.
Under Routing > Information > OSPF, verify the Full neighbor status and the learned route.

An OSPF Network is not the remote destination network. The entry enables OSPF on local interfaces whose IP address falls within this network. The remote LAN appears only when the remote peer advertises it through OSPF.

What OSPF decides on the firewall

OSPF is an internal link-state routing protocol. Neighboring routers exchange information about their reachable networks and paths, build a Link-State Database from it, and calculate the lowest-cost path. A lower Cost is preferred over a higher one.

OSPF therefore solves a different task from firewall rules and SD-WAN:

OSPF learns and distributes destination networks within the local routing domain.
A firewall rule still decides whether payload traffic may pass between the involved zones and networks.
NAT changes addresses when required, but it is not part of OSPF.
An SD-WAN Route can additionally make decisions based on source, service, application, or link quality.

Sophos Firewall assigns dynamically learned routes to the static category in the global Route Precedence. If an OSPF route competes with an SD-WAN or VPN route, the Route Precedence must therefore also match the intended packet flow. Within OSPF, however, the Cost determines the route.

OSPFv2 processes IPv4. OSPFv3 performs the same task for IPv6 but is configured separately on Sophos Firewall.

Plan the example topology

The example values represent two sites:

Firewall A: Router ID 192.0.2.10, transit IP 198.51.100.1/30, local LAN 10.10.10.0/24
Firewall B: Router ID 192.0.2.20, transit IP 198.51.100.2/30, local LAN 10.20.20.0/24
Transit network: 198.51.100.0/30
OSPF Area: 0.0.0.0

The addresses 192.0.2.0/24 and 198.51.100.0/24 are documentation networks. Replace them with the actual values from the environment.

The Router ID looks like an IPv4 address but does not have to be assigned to an interface. What matters is that it remains unique and permanently stable within the OSPF domain. 0.0.0.0 is not permitted. Without an explicitly configured value, SFOS uses the highest interface address; a deliberately selected Router ID prevents the identity from shifting unexpectedly after an interface change.

For this simple design, the Backbone Area 0.0.0.0 is sufficient. Multiple Areas become worthwhile only when a larger routing domain is deliberately segmented and summarized. Every additional Area requires a connection to the Backbone Area.

Prepare OSPF securely

The following prerequisites should be met before configuring OSPF:

The firewall is running in Gateway Mode. OSPF is not available in Transparent Mode.
Both transit IPs are in the same network and can reach each other directly, for example with Ping.
The interface, subnet mask, MTU, and zone are documented.
Router ID, Area, authentication, Hello interval, and Dead interval are coordinated on both sides.
A configuration backup and an independent management connection are available.
Suitable firewall rules and return paths are planned for both LANs.

A dedicated transit VLAN and transit zone make the connection easier to secure. Configure zones and interfaces on Sophos Firewall explains the basics.

Enable Dynamic Routing selectively

Under Administration > Device access, Dynamic Routing is disabled for all zones by default. For this example, the service is enabled only in the dedicated transit zone to which the 198.51.100.0/30 network is bound.

The checkbox in the Device Access matrix applies to the entire zone, not just to a single interface. If the transit interface shares its zone with other networks, a Local Service ACL Exception should instead restrict the service to the transit network and the intended peers.

This access setting concerns OSPF packets addressed to the firewall itself. It does not require a normal firewall rule. The actual traffic between 10.10.10.0/24 and 10.20.20.0/24 still requires suitable IPv4 firewall rules. Secure Device Access on Sophos Firewall explains the separation between local services and forwarded traffic.

Configure OSPFv2 in WebAdmin

Perform the following steps on both firewalls. Only the Router ID, transit IP, and local LAN differ.

1. Set global settings

Under Routing > OSPF, define the global values:

Router ID: 192.0.2.10 on Firewall A, 192.0.2.20 on Firewall B
Default metric: leave at 20 unless there is an intentional requirement for redistributed routes
ABR type: Standard for a new standard design
Auto-cost reference-bandwidth: leave at the default value of 100000 Mbps unless the cost plan requires a different shared reference value
Default-information originate: Never unless the firewall is explicitly intended to distribute a Default Route to all OSPF neighbors
Redistribute connected, static, RIP, and BGP: leave disabled initially

Then apply the global configuration with Apply.

The Default Metric applies to routes imported into OSPF from other sources. The Interface Cost, by contrast, determines path selection within the OSPF topology. A lower Cost wins.

Do not use Default-information originate: Always as a quick internet failover switch. The firewall would then advertise a Default Route even when it does not have one itself. Regular advertises it only when a Default Route exists in the routing table.

2. Create the Backbone Area

In the Areas section, click Add and set the following values:

Area: 0.0.0.0
Type: Normal

For the Area, select Authentication Type Text or MD5. If the peer supports MD5, prefer it over the clear-text option. The corresponding Key ID and key are entered later on the transit interface. MD5 authenticates the OSPF packets but does not encrypt the exchanged routing information.

Then save the Area with Save.

3. Add the transit network

In the Networks section, click Add:

IPv4/Netmask: 198.51.100.0/30
Area: 0.0.0.0

On Firewall A, the address 198.51.100.1 matches this Network; on Firewall B, 198.51.100.2 matches. OSPF therefore runs on the respective transit interfaces, and the two firewalls can establish an adjacency.

Save the Network entry with Save.

Do not simply enter the local LAN as a presumed remote destination. An additional Network entry can advertise it even without a neighbor, but it also enables OSPF on the matching LAN interface. If no OSPF routers are intended there, selective Redistribution provides cleaner control over the advertisement.

4. Override interface values only deliberately

The transit interface can be selected under Override interface configuration. The default values are suitable for many Ethernet connections:

Hello interval: 10 seconds
Dead interval: 40 seconds
Retransmit interval: 5 seconds
Transmit delay: 1 second
Interface cost: Auto
Router priority: 1

Hello and Dead must be identical on all routers in the segment. Retransmit Interval and Transmit Delay are set locally. Cost and Router Priority may intentionally differ: the Cost determines the preferred data path, while the Priority influences the election of the DR and BDR on broadcast networks. A Priority of 0 excludes the interface from this election.

If the Priority is identical, the Router ID decides, but an active DR election is not preemptive. A manually configured Cost is useful when one of multiple paths should be preferred. With Auto, SFOS calculates the Cost from the global Reference Bandwidth and the configured interface speed. If the link speed is changed under Network > Interfaces, OSPF applies the new Auto Cost only after a firewall restart.

For MD5 authentication, select Authentication Type MD5 in the Area. Then enter the same Key ID from 0 to 255 and the same key on the transit interface on both sides.

Apply changed interface values with Save.

5. Advertise only the required LANs

For this example, Firewall A must advertise 10.10.10.0/24, and Firewall B must advertise 10.20.20.0/24. There are two fundamentally different methods:

An OSPF Network enables OSPF on the matching local interface. This is appropriate when additional OSPF routers should establish an adjacency there.
Redistribution imports a route from another routing source into OSPF. This allows a directly connected LAN to be advertised without requiring an OSPF adjacency on that interface.

In this example, the two LANs are redistributed selectively because no additional OSPF routers should establish an adjacency on their interfaces.

The Redistribute connected option in WebAdmin imports all directly connected networks. On a production firewall, this can include WAN, management, DMZ, VPN, and other VLAN networks. The checkbox must therefore not be enabled without reviewing its impact.

For selective advertisement, an ACL with a Route Map can be used in the OSPF CLI. After logging in over SSH, follow 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF. The following example on Firewall A permits only the local LAN 10.10.10.0/24:

enable
configure terminal
access-list ospf-connected-out permit 10.10.10.0/24
route-map ospf-connected-filter permit 10
match ip address ospf-connected-out
exit
router ospf
redistribute connected route-map ospf-connected-filter
exit
write
show running-config

On Firewall B, use 10.20.20.0/24 in the access-list instead. The ACL has an implicit final Deny rule; Connected Routes that are not explicitly permitted are therefore not redistributed through this Route Map.

The global Redistribute connected option in WebAdmin remains disabled with this method. After later changes to the global OSPF configuration, check show running-config again because WebAdmin can remove conflicting advanced CLI settings.

Redistribute static also requires deliberate filtering. It includes static Blackhole Routes, among others, which could otherwise be passed unintentionally to neighboring routers.

Verify and validate OSPF

An adjacency alone does not prove that the intended LAN is reachable. Validation therefore proceeds from the OSPF layer through to the actual packet flow.

Under Routing > Information > OSPF > Neighbors, the peer must appear with its Router ID. Full indicates that the relevant Link-State information has been exchanged completely.
Under Routes, Firewall A must see 10.20.20.0/24 through 198.51.100.2. Firewall B expects 10.10.10.0/24 through 198.51.100.1.
Under Interface, verify the Area, Router ID, Cost, timers, Network Type, and MTU.
Under Diagnostics > Tools > Route lookup, check a specific destination, for example 10.20.20.10 on Firewall A.
Then test a real connection between one host in each LAN. Log Viewer and Packet Capture must show the expected firewall rule, transit interface, and return traffic.

Test a Sophos Firewall rule with Log Viewer and Packet Capture helps with the last two steps.

For an additional check over SSH, use the CLI path 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF:

enable
show ip ospf interface
show ip ospf database
show ip ospf neighbor
show ip ospf route

These commands document the participating interfaces, the Link-State Database, Neighbor status, and the routes calculated by OSPF in one place.

In the Advanced Shell, the OSPF and kernel logs provide additional context. Access it through 5. Device Management > 3. Advanced Shell:

cd /log
tail -f ospfd.log

Stop the live output with Ctrl+C. Then check the second log:

tail -f zebra.log

ospfd.log shows OSPF events. zebra.log helps verify whether a dynamically learned route was installed in the kernel. To inspect the log without following it live, use less /log/ospfd.log, for example. Sophos Firewall service and log files maps additional files to the responsible services.

Troubleshoot errors systematically

No neighbor appears

First verify direct reachability between the transit IPs. Then confirm that the transit interface is up, the OSPF Network matches the local interface IP, and Dynamic Routing is enabled in the correct zone. Area, subnet mask, Authentication Type, Key ID, key, Hello, and Dead must match on both sides. Duplicate Router IDs also prevent a clean adjacency.

Neighbor remains in Init or 2-Way

Init means that Hello packets are arriving, but bidirectional communication has not yet been confirmed. Device Access, asymmetric filters, interface assignment, and the return path are the first items to check.

2-Way is normal between two routers in a broadcast network when neither router is the DR or BDR. In this example with exactly two OSPF routers and Priority 1, the two participants become DR and BDR; their adjacency should therefore reach Full. If it remains in 2-Way, verify Router Priority, Network Type, and the peer.

Neighbor remains in ExStart, Exchange, or Loading

In these states, synchronization of the Link-State Database has started but does not complete. Common causes are mismatched MTU values, incompatible Network Types, duplicate Router IDs, or unstable connections. Under Routing > Information > OSPF > Interface, the MTU, MTU Mismatch Detection, Network Type, and timers are available for comparison.

Neighbor is Full, but the remote LAN is missing

The adjacency works in this case, but the LAN is either not advertised or not permitted by the filter. On the sending firewall, the Connected Route, ACL, Route Map, and redistribute connected route-map must match the intended prefix. show running-config shows the saved OSPF configuration.

If Redistribute connected was enabled in WebAdmin instead, review not only the missing LAN but the complete list of all networks advertised as a result.

The route exists, but traffic does not work

OSPF has completed its task when the route with the correct Next Hop is present. Errors after that usually involve the firewall rule, NAT, Route Precedence, return path, or destination system. Normal routed site networks generally do not require SNAT because both firewalls should know the LANs through OSPF.

OSPF over route-based IPsec

OSPF can also run over an XFRM interface of a route-based Site-to-Site IPsec tunnel. With an Any-to-Any or Dual-Stack tunnel, assign the XFRM interfaces on both sides unique IP addresses from the same transit network. This addressing is not possible with specific Traffic Selectors.

The following additional requirements apply to this design:

Dynamic Routing is allowed for the VPN zone under Administration > Device access.
The XFRM transit network is entered as an OSPF Network.
Payload traffic requires suitable IPv4 or IPv6 firewall rules for the VPN zone.
Hello, Dead, authentication, and MTU must match the peer.
Compare the displayed OSPF Network Type on both sides. A mismatch can prevent the adjacency from forming; if it cannot be corrected in WebAdmin, the peer must be adjusted or Sophos Support must be involved.

A green IPsec tunnel and an OSPF neighbor in Full are separate checkpoints. Only the learned route and an actual packet flow confirm the complete setup.

In an HA cluster, OSPF can reconverge after a failover. A planned failover should therefore be tested, followed by a check on the active Node that the neighbor, routes, ospfd.log, and zebra.log have returned to the expected state.

OSPFv3 for IPv6

Under Routing > OSPFv3, IPv6 routing is configured independently of OSPFv2. The Router ID remains a unique value in IPv4 notation.

Unlike OSPFv2, a Network is not entered first. Under Interfaces, select the IPv6-capable interface and assign it to an Area. Area 0.0.0.0 is also used for a simple design. Hello and Dead must match on the segment; set Cost, Retransmit, Transmit Delay, and Router Priority as appropriate for the local topology. SFOS currently supports only one OSPFv3 instance per interface with the default Instance ID 0.

Sophos Firewall currently does not support authentication for OSPFv3. The exchange should therefore take place only over trusted or already protected links. An existing OSPFv2 configuration does not advertise IPv6 networks, and IPv6 payload traffic requires separate IPv6 firewall rules.

In WebAdmin, directly connected IPv6 networks and BGP IPv6 routes can be redistributed into OSPFv3. Here too, Redistribute connected includes all directly connected IPv6 networks and should therefore not be enabled indiscriminately.

Validation takes place under Routing > Information > OSPFv3; in case of errors, ospf6d.log provides protocol-specific context.

Roll back the change safely

Before removing OSPF, an alternative path or a planned maintenance window must exist for every learned destination network. First remove Redistribution of the local LAN, then the transit Network, and finally disable Dynamic Routing for the zone. Then verify Route Lookup, the routing table, and management access again.

When reverting only an incorrect Cost, timer, or filter, change only that one setting at a time. This makes it possible to determine whether the OSPF adjacency, route advertisement, or only the payload traffic was affected.