BGP on OPNsense — configuring FRR, peering with upstreams, and the production discipline

BGP on OPNsense is the protocol of the multihomed edge and the cloud interconnect. The configuration is not difficult — the FRR plugin writes a valid bgpd.conf from the GUI inputs — but the discipline is. A BGP deployment that has not been filtered is a hijack waiting to happen. A BGP deployment that has not been authenticated is a session that any attacker who can inject packets can disrupt. This lesson covers how to configure BGP through the FRR plugin, the filtering discipline, the authentication options, and the verification commands the operator uses to confirm the deployment is doing what it should.

The configuration surface

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

• General — enable BGP, set the local AS number, configure the router ID, configure global timers, configure default information originate (sending a default route).
• Neighbours — define each BGP peer: the neighbour IP, the remote AS, the description, the source interface, the eBGP multihop (for non-directly-connected peers), the password for MD5/TCP-AO authentication.
• Prefix Lists — define prefix lists (named sets of prefix matches) used by route maps.
• Route Maps — define route maps (sequences of match/set) used to filter and modify routes.
• Redistribution — what sources to redistribute into BGP (e.g., connected, static, OSPF, kernel routes).

The plugin writes /usr/local/etc/frr/bgpd.conf and applies the configuration through vtysh. The operator verifies with vtysh -c 'show running-config'.

Step-by-step configuration for a single upstream

The minimum configuration for a single-upstream BGP deployment:

1. Install the plugin (System → Firmware → Plugins → os-frr).
2. Set the local AS number (Routing → FRR → BGP → General). The AS number is assigned by the regional Internet registry (RIPE, ARIN, APNIC, etc.) for a public AS, or is a private AS (64512 to 65534) if the deployment is internal.
3. Set the router ID to a stable IP.
4. Configure the neighbour (Routing → FRR → BGP → Neighbours). The neighbour IP is the upstream router’s IP on the WAN link. The remote AS is the upstream’s AS.
5. Configure authentication (the password field on the Neighbours tab). MD5 is the historical default; TCP-AO (RFC 5925) is the modern choice.
6. Define the inbound prefix list (Routing → FRR → BGP → Prefix Lists). The list specifies what prefixes the operator is willing to accept. For a default-route-only acceptance, the list is permit 0.0.0.0/0. For accepting the upstream’s customer routes, the list is the upstream’s customer-prefix-set (typically provided by the upstream).
7. Define the outbound route map (Routing → FRR → BGP → Route Maps). The map specifies what to send. For a default-route-only advertisement, the map matches a static default route.
8. Apply the filters to the neighbour (the Inbound Route Map and Outbound Route Map fields on the Neighbours tab).
9. Apply and verify.

bgp-node# vtysh -c 'show running-config' | grep -A 40 'router bgp'

router bgp 65001
bgp router-id 10.0.0.1
neighbor 198.51.100.1 remote-as 64512
neighbor 198.51.100.1 description 'ISP A transit'
neighbor 198.51.100.1 password PASSWORD
neighbor 198.51.100.1 route-map INBOUND-FROM-ISP-A in
neighbor 198.51.100.1 route-map OUTBOUND-TO-ISP-A out
!
ip prefix-list UPSTREAM-A-IN seq 5 permit 0.0.0.0/0
!
route-map INBOUND-FROM-ISP-A permit 10
match ip address prefix-list UPSTREAM-A-IN
set local-preference 100
!
route-map OUTBOUND-TO-ISP-A permit 10
match ip address prefix-list MY-OWN-PREFIXES
set community 64512:100
!
ip prefix-list MY-OWN-PREFIXES seq 5 permit 192.0.2.0/24
ip prefix-list MY-OWN-PREFIXES seq 10 permit 198.51.100.0/24

The filtering discipline

Three filters every BGP session needs:

1. Inbound prefix list — defines what the operator is willing to accept from the peer. At minimum, deny 0.0.0.0/0 le 8 (bogons), deny 127.0.0.0/8 le 32 (loopback), deny 192.0.2.0/24 le 32 (TEST-NET), deny the operator’s own prefixes (no peer should advertise them). The list should also include the specific prefixes the operator wants from the peer (a default, the peer’s customer routes, etc.).
2. Outbound route map — defines what the operator is willing to send to the peer. At minimum, the operator’s own prefixes. The route map typically tags the routes with a community so the upstream can apply policy on its side.
3. Authentication — MD5 or TCP-AO on every session that crosses an untrusted network. Plain-text BGP is acceptable only on point-to-point links the operator controls end-to-end.

A production filter set, for a multihomed edge with two ISPs:

• Inbound from ISP A — permit ISP A’s customer routes + permit a default.
• Inbound from ISP B — permit ISP B’s customer routes + permit a default.
• Outbound to ISP A — permit the operator’s own prefixes + AS path prepending on the secondary link.
• Outbound to ISP B — permit the operator’s own prefixes + AS path prepending on the secondary link.
• No redistribution of OSPF, connected (other than the operator’s own), or kernel routes into BGP without an explicit route map.

Communities

BGP communities are tags (32-bit or 64-bit values) that propagate with routes. They are the standard mechanism for coordinating policy across AS boundaries.

Common community uses:

• No-export (well-known; 65535:65281) — the receiver does not advertise this route to any eBGP peer.
• No-advertise (65535:65282) — the receiver does not advertise this route to any BGP peer.
• No-peer — restored from RFC 1997 but less commonly used.
• Operator-specific communities — agreed between the operator and the upstream; “if you see 64512:100, set local preference to 100; if you see 64512:200, prepend my AS twice on egress”.

The FRR plugin’s Route Maps tab lets the operator set and match communities. The discipline: use communities to express policy the operator would otherwise have to hardcode on every neighbour.

Multihoming

A network with two or more upstream ISPs runs BGP with both, with the routes from each filtered, and with policy that determines:

• Outbound preference — Local Preference on the routes learned from each ISP. Higher wins.
• Inbound preference — AS path prepending on the routes advertised to each ISP, or MED. The upstream with the shorter AS path (or lower MED) wins.

A simple multihoming design:

OPNsense
   |
   +---- ISP A (AS 64512, primary)        Local Pref 200, no prepend
   |
   +---- ISP B (AS 64513, backup)         Local Pref 100, prepend 2x

The operator assigns higher Local Preference to routes from ISP A, so outbound traffic prefers ISP A. The operator prepends AS 65001 twice on routes advertised to ISP B, so ISP B’s other customers prefer ISP A’s routes (shorter AS path). The result: outbound traffic prefers ISP A; inbound traffic also prefers ISP A. ISP B is a backup.

Verifying the deployment

The OPNsense operator verifies BGP through three commands:

bgp-node# vtysh -c 'show ip bgp summary'; echo '---'; vtysh -c 'show ip bgp neighbors 198.51.100.1'; echo '---'; vtysh -c 'show ip route bgp'

Neighbor        V    AS   MsgRcvd  MsgSent  Up/Down   State/PfxRcd
198.51.100.1    4  64512   12345      9876   12:34:56        1
198.51.100.5    4  64513    9876      7654   12:34:56        1

---



BGP neighbor is 198.51.100.1, remote AS 64512, external link
Description: ISP A transit
BGP state = Established
Last state = OpenConfirm
Last event = RecvKeepAlive
Last error = None
Local host: 198.51.100.2, Local port:  random
Foreign host: 198.51.100.1, Foreign port: 179
Nexthop: 198.51.100.2
BGP version 4, remote router ID 10.0.0.2
Password: configured
Received: 12345 messages, 0 notifications, 0 in queue
Sent: 9876 messages, 0 notifications, 0 in queue
Route map: INBOUND-FROM-ISP-A(in), OUTBOUND-TO-ISP-A(out)

---
B>* 0.0.0.0/0 [20/0] via 198.51.100.1, igb0, 00:05:23
B>* 0.0.0.0/0 [20/0] via 198.51.100.5, igb0, 00:05:23

The failure modes of BGP on a firewall

Four production failure modes:

1. Session flap. A flaky link or a configuration change resets the session. The operator tunes the BGP timers (timers and neighbor advertisement-interval) and configures BFD for sub-second detection on critical links.
2. Route hijack. A peer (or an attacker) advertises a prefix the operator should not accept. The fix is the inbound prefix list — and verifying it after every change.
3. Route leak. The operator accidentally advertises a prefix they do not own (an internal /24, a customer prefix). The fix is the outbound route map — and verifying it after every change.
4. Authentication mismatch. The MD5 password does not match the upstream’s. The session does not establish; the operator sees notification messages in show ip bgp neighbors. The fix is consistent key management.

Summary

• OPNsense exposes BGP through the FRR plugin; the plugin writes /usr/local/etc/frr/bgpd.conf.
• The minimum configuration: local AS, router ID, neighbour (remote AS, IP, authentication), inbound prefix list, outbound route map.
• The discipline: every BGP session has all three filters. No exceptions.
• Multihoming: Local Preference for outbound, AS path prepending or MED for inbound.
• Communities are the standard policy tag — use them to coordinate with the upstream.
• Verification: show ip bgp summary, show ip bgp neighbors <ip>, show ip route bgp.