OSPF on OPNsense — configuring FRR, advertising networks, and the production discipline

Configuring OSPF on OPNsense is not just “tick the enable box”. The operator must assign interfaces to areas, decide what to advertise, configure authentication, and verify that the LSDB converges correctly. A misconfigured OSPF deployment can leak prefixes to peers, accept routes the operator did not intend, or produce adjacencies that flap every minute. This lesson covers how to configure OSPF through the FRR plugin on OPNsense, what to advertise and what to keep out, and the production discipline that distinguishes a working deployment from one that has merely enabled the protocol.

The configuration surface

OPNsense exposes OSPF through Routing → FRR → OSPF (after installing the os-frr plugin). The tabs:

• General — enable OSPF, set the router ID, configure global timers, configure redistribution from other sources.
• Interfaces — assign interfaces to OSPF, set the area, the network type (broadcast / point-to-point), the cost, the priority, the hello/dead intervals, the authentication.
• Areas — define virtual links and area ranges (where summarisation happens at the ABR).
• Passwords — define the authentication keys per interface.

The plugin writes the FRR configuration to /usr/local/etc/frr/ospfd.conf and applies it through vtysh. The operator can verify the live configuration in vtysh -c 'show running-config'.

Step-by-step configuration

The minimum configuration for an OSPF deployment between OPNsense and an upstream router on the WAN link:

1. Install the plugin (System → Firmware → Plugins → os-frr). The plugin pulls in the FRR suite and the GUI.
2. Set the router ID (Routing → FRR → General). The router ID should be a stable IP — typically the LAN interface IP or a loopback IP. Never leave it as “auto” in a production deployment; the auto-assigned ID depends on the highest IP at startup, which can change if an interface flaps.
3. Enable OSPF in the same tab.
4. Assign the WAN interface to the OSPF area (typically area 0 if this is the only OSPF area in the network).
5. Set the network type (broadcast on Ethernet, point-to-point on a /30).
6. Configure authentication (a plaintext password or MD5 hash, depending on what the upstream supports).
7. Decide what to advertise — typically the LAN interface network. This is set under Interfaces → OSPF, “Advertise” checkbox.
8. Apply and verify with vtysh.

ospf-node# vtysh -c 'show running-config' | grep -A 30 'router ospf'

router ospf
ospf router-id 10.0.0.1
network 10.0.0.0/24 area 0.0.0.0
network 192.0.2.0/30 area 0.0.0.0
passive-interface igb1
interface igb0
ip ospf network point-to-point
ip ospf authentication-key PASSWORD
ip ospf cost 10
exit

What to advertise, what to keep out

The most consequential OSPF decision on a firewall is the set of prefixes the firewall advertises to its peers. The defaults of the FRR plugin are not safe for production — the plugin will advertise every connected network that has OSPF enabled on it.

The discipline:

• Advertise prefixes the network needs to reach through this firewall. If the LAN is 10.0.0.0/24 and the operator wants remote sites to reach it via OSPF, advertise it. If the LAN is a /24 of point-to-point links to internal routers that have their own OSPF, advertise those.
• Never advertise prefixes the operator does not intend to expose. A DMZ with sensitive servers, a management VLAN with admin hosts, a link to an upstream ISP that should not see internal topology — none of these should be advertised.
• Use passive interfaces for networks where the operator wants the prefix announced but does not want to form adjacencies. The LAN is typically passive — the operator announces the LAN network so the rest of the OSPF domain knows the prefix, but the operator does not want OSPF hellos going to LAN workstations.
• Be careful with redistribution. A firewall that redistributes BGP routes into OSPF, or that redistributes a default route, can announce prefixes the operator did not review. The discipline: never redistribute without a route map that filters exactly what is permitted.

Authentication

OSPF supports two authentication mechanisms in production deployments:

• Plaintext — a cleartext password carried in the OSPF packet. Defeats casual observation but not a packet capture. Use only on links the operator trusts physically.
• MD5 — an HMAC-MD5 digest computed over the OSPF packet and a shared secret. The receiver recomputes and verifies. Defeats both observation and tampering. The OSPF standard mechanism for shared-media authentication.

FRR also supports key chains (multiple keys with rollover) and SHA-based authentication in newer versions. The choice depends on what the upstream router supports and what the operator’s security policy requires.

The configuration in the GUI: Routing → FRR → OSPF → Interfaces → set the authentication type and key per interface. The operator must set the same key on the upstream router or the adjacency will not form.

Verifying the deployment

The OPNsense operator verifies an OSPF deployment through three commands:

ospf-node# vtysh -c 'show ip ospf neighbor'; echo '---'; vtysh -c 'show ip ospf interface brief'; echo '---'; vtysh -c 'show ip route ospf'

Neighbor ID     Pri   State         Dead Time   Address         Interface
10.0.0.2        1     Full/DR       00:00:38    192.0.2.2       igb0:192.0.2.1
---

Interface       Area            Cost  State    Nbrs/F/C
igb0            0.0.0.0         10    P2P      1/1
igb1            0.0.0.0         10    DRother  0/0

---
O    10.0.0.0/24 [110/10] is directly connected, igb1
O    192.0.2.0/30 [110/10] is directly connected, igb0

The failure modes

OSPF on a firewall has four production failure modes the operator must plan for:

1. Adjacency flaps. A link that goes up/down/up produces constant SPF runs and LSDB churn. The operator tunes SPF throttling (timers throttle spf) and configures the upstream’s interface dampening.
2. Route redistribution leaks. A misconfigured redistribution injects prefixes into OSPF that the operator did not intend. The fix is a route map that filters exactly what is permitted.
3. Area leaks. A multi-area deployment where a misconfigured area range or virtual link causes prefixes to leak. The fix is careful area design and verification of the ABR configuration.
4. Authentication mismatch. A new router with a different password forms no adjacency. The fix is consistent key management — typically a configuration-management system that enforces the key.

Summary

• OPNsense exposes OSPF through the FRR plugin; the plugin writes /usr/local/etc/frr/ospfd.conf.
• The minimum configuration: router ID, enable OSPF, assign interfaces to areas, decide what to advertise, configure authentication, verify with vtysh.
• The most consequential decision is the set of prefixes to advertise. Passive interfaces, no redistribution without route maps, careful area design.
• Authentication: plaintext on trusted links, MD5 on shared media, key chains for rollover.
• Verification is show ip ospf neighbor, show ip ospf interface, show ip route ospf.
• The four failure modes: adjacency flaps, redistribution leaks, area leaks, authentication mismatches.