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. For a small or existing routing domain with few routers, RIPv2 can be simpler; OSPF, by contrast, offers faster convergence and a more scalable path model.

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 adjacencies should be established only on designated, trusted transit or VPN interfaces. In the example, the LAN is also entered as an OSPF Network so that SFOS advertises its prefix. This enables OSPF on the LAN interface, allowing SFOS to send outbound OSPF Hellos from it. Dynamic Routing remains disabled for the LAN zone so that incoming OSPF packets are not permitted; this does not prevent the outbound Hellos. Do not enable Redistribute connected until it is clear which directly connected networks it will advertise.

Overview of the process

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.
Enter the respective LAN as a second OSPF network or use a separately tested redistribution.
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.

OSPF routes appear alongside other unicast routes in the routing table. Conventional routing first selects the longest matching prefix. For the same prefix, SFOS compares the Administrative Distance of different routing sources; between comparable OSPF paths, the OSPF metric then decides. Separately, global Route Precedence determines whether conventional routing, SD-WAN Policy Routes, or VPN routes are evaluated first. Before making a global change, record the current order with system route_precedence show.

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 one interface. A dedicated transit zone is therefore the clearest option. If the transit interface shares its zone with other networks, a Local service ACL exception rule can restrict access by IP version, Source zone, Source networks and hosts, Destination host, the Dynamic Routing service, Action, and rule position. However, OSPFv2 uses the multicast destinations 224.0.0.5 and 224.0.0.6, so the local transit address is not necessarily a functional Destination host. Before using such an exception, confirm multicast matching on the installed SFOS build. Without that confirmation, a dedicated transit zone remains the safe choice.

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

⚠️ The example values are for an initial setup. Do not casually replace an established router’s Router ID: the SFOS 23 help warns that changing it resets all OSPF sessions. This does not establish that older versions are exempt. Before changing it, secure a backup and independent management access, record current neighbors and routes, and schedule a maintenance window. Afterward, expected adjacencies must return to Full, intended prefixes must be present, unwanted prefixes absent, and real connections and their return paths must work.

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.

Default metric is the fallback for redistributed routes when no individual metric is configured for their route type. An Area Border Router (ABR) connects other areas to the backbone and maintains a separate topology database and routing information for each connected area. OSPFv2 offers Standard, Cisco, IBM, and Shortcut under ABR type for compatibility with the existing routing domain; the choice must match the agreed design.

When migrating from an older version to SFOS 19.5 or later, the previous default reference bandwidth of 100 changes to 100000 Mbps. A previously customized value is preserved. After an upgrade, compare the actual reference value and resulting costs with the cost plan.

An Autonomous System Boundary Router (ASBR) imports routes from other routing sources into OSPF. The following external metrics refer to this router.

The default metric applies to routes imported into OSPF from other sources. For redistributed routes and the advertised Default Route, Metric type can also be selected. External type 1 adds the internal cost to the ASBR and the external cost. With External type 2, the external metric is compared first; if it is equal, the internal path to the ASBR is also used as a tie-breaker. 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

Area cost can be set only for area types other than Normal; it is not available for the backbone area in this example. For a Normal area, Virtual links > Add adds a virtual link to connect an area without a physical backbone connection to the backbone. This is a planned multi-area change, not a substitute for checking the physical topology.

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.

For this simple design, Area 0.0.0.0 remains Normal. A Stub Area does not receive external AS routes, while Stub no-summary additionally suppresses normal summary routes except for the default route. An NSSA can introduce its own external routes into the OSPF domain as type 7 LSAs; NSSA no-summary combines this with the stricter summary restriction. A Virtual Link is only available for a Normal Area. Do not change the area type as a quick troubleshooting switch because both sides and the entire area design must match it.

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.

An OSPF network always refers to a local network: SFOS activates OSPF on every interface whose address matches the entry and announces its prefix. For the LAN, this example in step 5 also uses a network entry because WebAdmin can use it to target precisely the required prefix and later remove the entry again. The disadvantage is that this also makes the LAN interface part of OSPF. Filtered redistribution avoids this, but under SFOS 22 it requires a separately tested CLI configuration along with rollback.

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 interval controls the interval between Hello packets used to discover neighbors. Dead interval determines how long to wait without a Hello before declaring a neighbor unavailable. SFOS automatically sets Dead to four times Hello; after changing Hello, check that the calculated value is within the permitted range and matches the neighbors. Dead can also be overridden manually. Retransmit interval controls retransmission of Link-State Advertisements (LSAs); Transmit delay accounts for transmission and propagation delay of a link-state update.

DR means Designated Router, and BDR means Backup Designated Router. Higher Router Priority is preferred in the election; with equal priority, the highest Router ID wins.

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.

If Text is selected instead for OSPFv2, enter an authentication password on the interface and coordinate it with the peer. This does not apply to OSPFv3, which does not support authentication.

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 adds the matching local interface to OSPF and advertises its prefix.
Redistribution imports routes into OSPF from another routing source.

Under Routing > OSPF > Networks, click Add and assign the local LAN to Area 0.0.0.0: use 10.10.10.0/24 on Firewall A and 10.20.20.0/24 on Firewall B. Save the entry with Save. Dynamic Routing remains disabled for the LAN zone; the service is allowed only for the transit zone or through the tightly scoped Local Service ACL Exception. The peer must then learn exactly this LAN. Use an unwanted local network as a negative control; it must not appear in the peer’s OSPF routing table.

This variant works as long as the LAN interfaces are intentionally allowed to be part of OSPF. If OSPF should generally not be activated there, or if the prefixes to be distributed come from Static, RIP, or BGP, redistribution is the more appropriate method. However, the Redistribute connected option in the WebAdmin includes all directly connected networks. On a production firewall, this can also include WAN, management, DMZ, VPN, and other VLAN networks. Therefore, the checkbox must not be activated without careful consideration.

For remote access SSL VPN, Redistribute connected only imports the dynamic client subnet. A statically assigned SSL VPN subnet is not injected automatically and, when genuinely required, must be configured as a separate OSPF Network and tested independently.

WebAdmin cannot filter Connected Routes by individual prefix. Although the SFOS 22 command-line help shows an ACL with a Route Map for this purpose, it documents only an exclusion example, not the complete rollback of a production allowlist. Without a rollback procedure verified on the deployed SFOS version, this cannot serve as a safe copy-and-paste recipe. Anyone who needs selective redistribution should treat the ACL and Route Map as a separate routing change, have the syntax and rollback confirmed for the installed build, and verify both the intended prefix and at least one network that explicitly must not be advertised on the peer.

From SFOS 23.0 onward: Access-list, prefix-list, and route-map names must be unique across all dynamic routing protocols because they share an integrated configuration. When upgrading from an earlier version to SFOS 23.0 or later, Sophos Firewall automatically adds protocol prefixes to route-map, prefix-list, and access-list names if a name conflict exists and updates all references to the renamed configurations. Before selective redistribution or rollback, compare the object names and references saved before the upgrade with the current configuration; do not assume an old name still identifies the current binding. After the change or rollback, verify on the peer that intended prefixes are present and explicitly forbidden prefixes are absent. Inventory names and references across protocols before choosing names or planning rollback. Remove only references belonging to the change; do not broadly delete shared objects. Other protocols must retain their expected neighbors and routes. An executable filtering recipe remains withheld until syntax and rollback are confirmed.

The global WebAdmin option Redistribute connected remains disabled for a CLI-filtered variant. After later changes to the global OSPF configuration, show running-config must be checked again because WebAdmin can remove conflicting advanced CLI settings and changes to log-adjacency-changes. Redistribute static is also only activated after a complete inventory of the existing static routes.

Configure and roll back OSPF in the CLI

SFOS 22, OSPFv2/IPv4 only: The OSPF CLI is located under 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF. The following minimal configuration for Firewall A reproduces the transit network and LAN advertisement of the WebAdmin example. The documented SFOS 22 sequence with exit and write at the global ospf(config)# prompt is preserved here.

⚠️ Before ospf router-id on an established router, use the same preflight as in WebAdmin: the SFOS 23 help warns that changing the existing Router ID resets all OSPF sessions. Do not replace it with the example value. Secure a backup and independent management access, record neighbors and routes, and use a maintenance window, followed by checks of Full adjacencies, intended/unwanted prefixes, and real traffic.

enable
configure terminal
router ospf
ospf router-id 192.0.2.10
network 198.51.100.0/30 area 0
network 10.10.10.0/24 area 0
log-adjacency-changes
exit
write
show running-config
end

SFOS 23, OSPFv2/IPv4 only: 3. Route Configuration > 1. Configure Unicast Routing opens the shared routing console at router# (EXEC). configure terminal enters router(config)# (global configuration), and router ospf enters router(config-ospf)#. Starting at router#, enter these commands for the same example without typing the displayed prompts:

router# configure terminal
router(config)# router ospf
router(config-ospf)# ospf router-id 192.0.2.10
router(config-ospf)# network 198.51.100.0/30 area 0
router(config-ospf)# network 10.10.10.0/24 area 0
router(config-ospf)# log-adjacency-changes
router(config-ospf)# end
router# show running-config
router# write

end returns directly to EXEC. The SFOS 23 setup help shows show running-config and write there, while its note generally requires do write. The filter example specifically shows router(config)# do write after leaving OSPF with exit. This documentary tension does not prove that EXEC write fails to save: this article follows the mode-qualified setup example, not bare write in SFOS 23 configuration mode.

show running-config displays running state, not proof of saving. After write in SFOS 23, check the save confirmation for the integrated /conf/routing/frr.conf; the SFOS 22 filter example instead names /conf/routing/ospfd.conf. Do not edit the file by hand. According to Sophos, CLI changes must be saved to appear in WebAdmin and survive a firewall or daemon restart. Check the confirmation and expected WebAdmin values; a restart is not a required test here and was not performed for this article. If confirmation is missing, clarify with Sophos before further changes. Then verify neighbors, routes, and traffic.

On firewall B, the router ID 192.0.2.20 and the LAN network 10.20.20.0/24 are used instead.

The router ID must be unique, must not be 0.0.0.0, and does not need to be an actually assigned IP address. Without manual specification, SFOS uses the highest interface IP. The area ID can be entered as a number from 0 to 4294967295 or in IPv4 notation. SFOS stores the network normalized according to the mask; therefore 198.51.100.1/30 becomes 198.51.100.0/30. This exact stored value must later be used for verification and removal. log-adjacency-changes logs neighbor changes without debug mode and is set by default in a WebAdmin configuration.

Distinguish a Network, the OSPF process, and the default route

SFOS 22, OSPFv2/IPv4: To remove only one Network, prefix its normalized line from show running-config under router ospf with no. Before removing the transit network, secure alternative routes, a backup, and independent management access, and plan a maintenance window: the adjacency on this segment will be lost.

enable
configure terminal
router ospf
no network 198.51.100.0/30 area 0
exit
write
show running-config
end

As a result, OSPF ends on the corresponding interfaces and the affected announcements disappear. no router ospf, on the other hand, removes the OSPFv2 routing configuration. Before this destructive step, save the complete running configuration and a backup, and ensure that alternative routes are available; the command belongs in a maintenance window and is not a temporary on/off switch.

SFOS 23, OSPFv2/IPv4: Start the same Network removal at router# in the shared console. The SFOS 23 overview documents no network at router(config-ospf)#; then use the same EXEC verification and save flow as above:

router# configure terminal
router(config)# router ospf
router(config-ospf)# no network 198.51.100.0/30 area 0
router(config-ospf)# end
router# show running-config
router# write

After removal, exactly the intended Network entry and advertisement must be absent; remaining neighbors, alternative routes, management access, and traffic must work as planned. Also check the save confirmation. To reverse this specific change, restore the previously recorded network … area … entry in the version-appropriate OSPF context, save, and verify again.

For complete process removal, SFOS 22 documents ospf(config)# no router ospf, whereas the SFOS 23 overview gives router(config-ospf)# no router ospf. This is a documented prompt change, not a proven command failure. This SFOS 23 context has not been verified on a device here. No executable SFOS 23 process-removal procedure is therefore offered until Sophos confirms the context and restoration path for the installed build; do not guess a different mode. Do not broadly delete shared ACLs, prefix lists, or route maps.

ospf push-default-route-to-kernel performs a third, separate task: a default route learned via OSPF is adopted into the kernel routing table. The command does not advertise any default route to the neighbors and is therefore not the same as Default-information originate. Beforehand, existing default routes, route precedence, management return path, and route lookup are saved. The officially documented rollback is carried out at the OSPF prompt with no ospf push-default-route-to-kernel; afterwards, the routing table, route lookup, management access, and actual traffic are checked again.

Global changes in WebAdmin can remove conflicting CLI settings. After every such change, verify show running-config, neighbors, learned routes, and the saved configuration again.

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 fully exchanged.
Under Routes, Firewall A must see 10.20.20.0/24 via 198.51.100.2. Firewall B expects 10.10.10.0/24 via 198.51.100.1. A non-authorized test prefix, on the other hand, must not appear.
Under Interface, area, router ID, cost, timer, network type, and MTU are monitored. Database displays the link-state database; Border routers helps to check ABR and ASBR entries in multi-area designs.
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 SSH check, SFOS 22 uses 3. Route Configuration > 1. Configure Unicast Routing > 2. Configure OSPF; SFOS 23 uses 3. Route Configuration > 1. Configure Unicast Routing to open the shared console. In SFOS 23, use end to return to router# and run show running-config there. It displays running configuration, not proof of saving; the separate save confirmation is explained above. Neighbor, Database, Interfaces, and calculated routes are reliably checked in SFOS 22 under Routing > Information > OSPF; therefore, this article does not mention undocumented routing daemon show commands.

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 the adjacency from being established correctly.

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 is working, but the LAN is not being advertised. With the Network method used in this example, the Connected Route must exist on the sending firewall and the corresponding network … area … entry must appear under router ospf. show running-config shows the normalized value in running configuration, not its save status.

If redistribution is used instead, the selected routing source as well as, if applicable, ACL, route map, and redistribute … route-map must match the desired prefix. With Redistribute connected, the complete list of all announced connected routes must also be checked.

If a network behind a policy-based IPsec tunnel disappears after an upgrade to SFOS 22, the dependency on redistribute kernel may be the cause. The tunnel and the OSPF neighbor can still appear healthy; SFOS 22: IPsec routes and redistribute kernel explains the checks and the route-based XFRM target design.

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. For SFOS to create the XFRM interfaces, the local and remote subnet must be Any on both sides. The setting IPv4, IPv6, or Dual then determines the IP versions used; with Dual, separate IPv4 and IPv6 firewall rules must be created manually. With specific traffic selectors, no addressable XFRM interface is created to which IP addresses or routes could be assigned.

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.
The displayed OSPF network type is compared on both sides. A deviation can prevent the OSPF adjacency from forming and must be clarified in the design of the two endpoints.

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.

The official HA documentation does not guarantee that OSPF adjacency state will be preserved. A planned failover should therefore be part of the acceptance test for the specific HA topology. Afterward, verify on the active node that the neighbor, routes, ospfd.log, and zebra.log have returned to the expected state.

OSPFv3 for IPv6

Limit of the SFOS 23 CLI help: The setup help adds router ospf6 and says the same steps apply to OSPFv3, but then continues with IPv4 OSPF Router ID and Network commands. The filter help adds IPv6 ACLs but retains match ip address and router ospf in the subsequent sequence. This does not establish a complete, reliable IPv6 matching, redistribution, and rollback procedure. The CLI examples above apply only to OSPFv2/IPv4. For IPv6, retain the interface-based WebAdmin path below; use an IPv6 CLI procedure only after Sophos confirms it for the installed build. Do not substitute IPv4 command tokens or treat upstream FRR commands as proof of Sophos support.

Under Routing > OSPFv3, IPv6 routing is configured independently of OSPFv2. The router ID remains a unique value in IPv4 notation. SFOS shows 0 for Default metric, but uses the non-changeable value 20; ABR type is fixed to Standard. The Auto-cost reference-bandwidth is set to 100000 Mbps by default. For Default-information originate, there are, as with OSPFv2, Never, Regular, and Always; in WebAdmin, connected and BGP IPv6 routes can be redistributed.

Unlike OSPFv2, a network is not entered first. Under Interfaces, the IPv6-capable interface is selected and assigned to an area. For a simple setup, Area 0.0.0.0 is also used here. Hello and Dead must match on the segment; Cost, Retransmit, Transmit Delay, and Router Priority are set according to your own topology. SFOS supports only one OSPFv3 instance per interface. The Instance ID is configurable; its default value is 0.

First, under Routing > OSPFv3 > Interfaces and areas > Areas, click Add, enter Area in IPv4 notation, select Type to match the design, and click Save. For the simple example, the area is 0.0.0.0. Then, under Routing > OSPFv3 > Interfaces and areas > Interfaces, click Add, select Interface, and enter the same Area, also in IPv4 notation.

The OSPFv3 defaults are Hello 10, Dead 40, Retransmit 5, and Transmit delay 1 second, with Router priority 1. Field purposes, automatic Dead calculation, and the permitted-range check apply as explained in the OSPFv2 interface step. DR/BDR election likewise prefers higher priority, then the highest Router ID on a tie; 0 excludes the interface from election. Interface cost can remain Auto or be set manually by clearing the checkbox; lower values are preferred. Auto uses reference bandwidth and configured interface speed. After changing the configured link speed, the new Auto Cost also takes effect only after a firewall restart. Finish by saving the interface configuration with Save.

Additional OSPFv3 areas can be created as Stub, Stub no-summary, NSSA, or NSSA no-summary. The variants differ in which external and summary LSAs they carry; an NSSA can additionally pass type 7 LSAs from its own redistribution to the ABR. These area types belong in a coordinated multi-area design, not in an improvised repair attempt.

Stub carries no type 4 or type 5 LSAs and does not allow virtual links. Stub no-summary also suppresses type 3 LSAs except the default summary route and likewise does not allow virtual links. NSSA receives no external type 5 LSAs from other areas; its own type 7 LSAs travel within the NSSA and are converted by the ABR to type 5 LSAs for the backbone. NSSA no-summary suppresses types 4 and 5 and type 3 except the default summary route, but retains type 7 and its conversion at the ABR. These LSA properties do not mean that SFOS offers RIP or static redistribution in OSPFv3 WebAdmin.

For the global OSPFv3 configuration, select only the required advertisements and set the corresponding metric and Metric type. The E1/E2 meanings and the effects of Never, Regular, and Always are explained in the global OSPFv2 step; the warning about Always also applies here. Click Apply. This can remove custom changes to log-adjacency-changes; afterward, recheck the running and saved configuration, neighbors, intended and unwanted IPv6 prefixes under Routing > Information > OSPFv3, and actual IPv6 traffic.

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.

Redistribute connected also redistributes all directly connected IPv6 networks into OSPFv3 and should therefore not be activated across the board. According to Sophos, only the dynamic subnet is injected in Remote Access SSL VPN, not the static one. The SFOS-22 help refers to an “OSPF network” for the static subnet, even though OSPFv3 is configured in the WebAdmin via interfaces rather than through a networks list. No reliable procedure can be derived from this contradiction; the announcement of a static IPv6 SSL VPN prefix must be clarified for the installed build with Sophos.

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 be available for each learned destination network. In the example, the LAN network entry is removed first, then the transit network, and finally Dynamic Routing is deactivated for the transit zone. If the LAN is redistributed instead, this redistribution is reversed first. Afterwards, route lookup, routing table, and management access are checked 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.