Configure and test BGP on Sophos Firewall

BGP exchanges selected routes between routers. On Sophos Firewall, it is particularly useful for multiple sites, redundant links, and AWS or Azure VPNs. For a single destination network with a fixed next hop, a static route is usually simpler.

In the following example, two Sophos Firewalls establish an eBGP session over a transit network. At the end, the Neighbor is Established, Firewall A knows the LAN behind Firewall B, and vice versa.

⚠️ Dynamic Routing should only be reachable by the intended peer. Changing the Router ID interrupts all BGP sessions; changing the Local AS also deletes all configured Neighbors and Networks. Both changes therefore belong in a planned maintenance window with a current backup.

BGP in seven steps

These steps are required for a simple IPv4 setup:

Define the transit IPs, local and remote ASNs, and the networks to advertise.
Test direct IP reachability between the two BGP peers.
Under Administration > Device access, allow Dynamic Routing only for the peer zone or through a restrictive Local Service ACL Exception; check the firewall rules required for the design separately.
Set the Router ID and Local AS under Routing > BGP.
Add the peer IP as a Neighbor with the Remote AS.
Enter only the required local prefixes under Networks.
Under Routing > Information > BGP-IPv4, verify the Established state, the learned route, and then actual traffic.

What BGP decides on the firewall

BGP answers the question of which networks are reachable through which router. Each participant needs several clearly separated values:

The Local AS identifies the local autonomous system. Two different ASNs form an eBGP connection; the same ASN on both sides would be iBGP.
The Remote AS is the ASN of the peer.
The Router ID identifies the BGP router within the BGP topology. It looks like an IPv4 address but does not have to be an interface address, and it should remain unique and stable.
A Neighbor is the IPv4 or IPv6 address of the peer to which the BGP session is established. In the directly connected example, this is the transit IP.
A Network is a local prefix that the firewall should advertise to the peer.

BGP does not permit user traffic and does not encrypt it. Dynamic Routing under Device Access or a Local Service ACL controls the firewall’s local BGP service. Traffic forwarded over learned routes additionally requires suitable firewall rules, a working return path, and, depending on the design, a deliberate NAT configuration.

For dynamic routing within a single internal routing domain, OSPF is often the more natural choice. BGP is better suited between different autonomous systems, for cloud providers, or when routes must be influenced selectively with policies.

Plan the example topology

The example uses two sites:

Firewall A: Local AS 65010, Router ID 192.0.2.10, transit IP 198.51.100.1/30, LAN 10.10.10.0/24
Firewall B: Local AS 65020, Router ID 192.0.2.20, transit IP 198.51.100.2/30, LAN 10.20.20.0/24
Transit network: 198.51.100.0/30

The ranges 192.0.2.0/24 and 198.51.100.0/24 are documentation networks. Replace them with the actual values for the environment. The two private ASNs are suitable for an internal example; for a connection to AWS, Azure, or a provider, use the ASN and peer values specified by the remote side.

Choose the Router ID deliberately and keep it unique and stable. With Automatic, SFOS uses the highest interface IP. If that address changes later, the router’s identity can change unexpectedly as well. A manual value avoids this dependency.

Prepare BGP securely

Before configuration, make sure the following conditions are met:

The firewall runs in Gateway Mode. BGP is not available in Transparent Mode.
The two transit IPs can reach each other directly. For an XFRM tunnel, the tunnel interface must also be up.
The Local AS, Remote AS, peer IPs, and permitted prefixes have been agreed with the peer administrator.
The local routing table and the planned Networks are documented so that each advertisement can be verified after configuration.
A current configuration backup and an independent management path are available.
Firewall rules and return paths for the later user traffic have been planned.

Configure zones and interfaces on Sophos Firewall explains the basics of the transit interface and zone. Before changing a production routing environment, a current firewall backup should also be available outside the appliance.

Permit Dynamic Routing selectively

Under Administration > Device access, Dynamic Routing is disabled for all zones by default. For a dedicated network used exclusively for transit, the service can be enabled in that zone.

If the peer interface shares its LAN or WAN zone with other networks, a Local Service ACL Exception for the specific peer IP or transit network is narrower than enabling access for the entire zone. Under Administration > Device access > Local service ACL exception rule > Add, create an Accept rule with the appropriate IP version, Source zone, Source networks and hosts, Destination hosts, the Dynamic Routing service, and Rule position. Then test access from the permitted peer IP and from a source that is not permitted.

The Sophos BGP help additionally calls for firewall rules for inbound and outbound BGP traffic. At the same time, the Device Access help states that local services are not controlled by firewall rules. These statements do not align unambiguously. Therefore, treat separately the Local Service ACL for the local BGP service, rules required by the tunnel or provider design, and normal rules for routed user traffic. This does not justify a blanket Any-to-Any rule for TCP 179. Secure Device Access on Sophos Firewall explains the local access layer in more detail.

Configure BGP in WebAdmin

Perform the following steps on both firewalls. Only the local and remote values are reversed.

1. Set Router ID and Local AS

Under Routing > BGP, enter the following values in Global configuration on Firewall A:

If a BGP configuration already exists, document the current state before applying changes: changing the Router ID resets all BGP sessions; changing the Local AS deletes all Neighbors and Networks. Apply such changes only during a planned maintenance window.

Router ID assignment: Manual
Router ID: 192.0.2.10
Local AS: 65010

On Firewall B, also use Manual, together with 192.0.2.20 and 65020. Then apply the global configuration.

Local AS accepts values from 1 to 4294967295. For internal environments without a public ASN, Sophos specifies the private range from 64512 to 65535.

2. Add the peer as a Neighbor

Under Routing > BGP > Neighbors, click Add and enter the following on Firewall A:

IP version: IPv4
IP address: 198.51.100.2
Remote AS: 65020

Firewall B uses 198.51.100.1 as the Neighbor and 65010 as the Remote AS. Save each entry with Save.

The Neighbor address is not the remote LAN and not the Router ID. It is the directly reachable transit IP of the peer. If this IP is unreachable or the ASNs are reversed, the session cannot reach Established.

3. Advertise the local LAN

Under Routing > BGP > Networks, click Add. Firewall A advertises:

IP version: IPv4
IP address: 10.10.10.0
Subnet mask: 255.255.255.0 (/24)

On Firewall B, enter 10.20.20.0 and 255.255.255.0 (/24) instead.

A Network entry defines which prefix BGP should advertise; it replaces neither the local route nor a firewall rule. After saving, check both the advertised prefix and the prefix received by the peer. Only prefixes that are actually required belong in this list.

Understand IPv6 neighbors and networks

SFOS also supports IPv6 under Neighbors and Networks. The preceding example deliberately remains on IPv4; for IPv6, enter the corresponding IP version, a directly reachable IPv6 peer address and the IPv6 prefix separately.

WebAdmin adds the required separation automatically. In a CLI-only configuration, the defaults are asymmetric: IPv4 Networks are initially activated for all neighbors, including IPv6 neighbors. IPv6 Networks are not activated for any neighbor. For an IPv6 neighbor, explicitly set these states in the corresponding address families:

address-family ipv4 unicast
no neighbor <ipv6-neighbor> activate
exit
address-family ipv6 unicast
neighbor <ipv6-neighbor> activate

To reproduce the WebAdmin defaults in a CLI configuration, Sophos also lists no bgp ebgp-requires-policy and bgp log-neighbor-changes. show running-config only shows values that differ from defaults; an automatically selected router ID and, for example, the default maximum-paths ibgp 16 may not appear. Validate IPv4 and IPv6 separately under Routing > Information > BGP-IPv4 and BGP-IPv6, including their own IPv6 firewall rules and return paths.

Test and validate BGP

An established session alone does not confirm a working packet flow. Validate the setup at several levels:

Under Routing > Information > BGP-IPv4 > Neighbors, the peer must appear in the Established state.
Under Routes, Firewall A should show the prefix 10.20.20.0/24; Firewall B should show 10.10.10.0/24.
Under Summary, check the session and the number of received prefixes.
Under Diagnostics > Tools > Route lookup, check a destination such as 10.20.20.10 on Firewall A.
Then test an actual service between one host in each LAN. Log Viewer and Packet Capture must show the expected rule, the correct transit interface, and the return traffic.

An Established Neighbor proves only that the BGP exchange works. The learned route, a correct Route Lookup, and an actual connection are required to validate the entire setup. Test a Sophos Firewall rule with Log Viewer and Packet Capture helps with packet-flow validation.

The same example through the CLI

As an alternative to WebAdmin, the same base configuration can be entered in the BGP CLI after signing in over SSH. Do not run the following commands in addition to an example environment that has already been fully configured. The menu path is:

3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP

On Firewall A, the complete example looks like this:

enable
configure terminal
router bgp 65010
no bgp ebgp-requires-policy
bgp log-neighbor-changes
bgp router-id 192.0.2.10
neighbor 198.51.100.2 remote-as 65020
address-family ipv4 unicast
network 10.10.10.0/24
exit
show running-config
write
end

On Firewall B, replace the Local AS, Router ID, Neighbor, Remote AS, and Network with 65020, 192.0.2.20, 198.51.100.1, 65010, and 10.20.20.0/24, respectively.

show running-config is used for verification. write stores the CLI configuration permanently, makes the entries visible in WebAdmin, and preserves them after a restart. Without write, the change is not fully complete.

The additional officially documented check is:

show ip bgp

It shows the known BGP prefixes and their path information. Reliably check Neighbor state and Summary under Routing > Information > BGP-IPv4.

⚠️ Do not mix advanced CLI configuration and WebAdmin without control. Editing a Neighbor in WebAdmin can remove additional CLI values such as a Neighbor password or Route Map. Once such settings are used, first preserve show running-config and continue maintaining the BGP configuration through the CLI.

Weight, MED, and global Route Precedence

The global Route Precedence orders static, sdwan_policyroute, and vpn. Keep it separate from the attributes BGP uses to select its own paths. system route_precedence show displays the current value; change it only when these categories genuinely compete. Adjust routing priority on Sophos Firewall explains validation and rollback.

Administrative Distance is one factor used to choose between different routing protocols. Within BGP, BGP attributes are evaluated. Sophos names a higher Weight as preferred, for example; among otherwise comparable paths, a lower MED is preferred.

This is especially important when the same prefix is available through redistribute ospf and is also learned from a BGP Neighbor. By default, the locally originated redistributed route has Weight 32768, while the route learned from the Neighbor has Weight 0. Without a deliberate adjustment, the redistributed route therefore wins. To prefer the peer path, set its Weight higher and then verify the resulting route.

Use MED for multiple entry paths

The Multi-Exit Discriminator (MED) tells a directly neighboring AS which of several entry paths into the local AS it should prefer. A lower MED is better; the default is 0. Advertise a higher value on the less-preferred path. By default, MED is compared only when the same prefix is learned over multiple links from the same neighboring AS.

MED is non-transitive. When the receiving AS forwards the route to another AS, the value resets to 0. BGP also evaluates Weight, Local Preference, locally originated status, AS path length and Origin Type first. MED decides only when these more important attributes are equal. A configured value therefore does not prove that the intended path wins.

Sophos sets MED through an outbound Route Map with a fixed sequence number and binds it to a specific Neighbor in the IPv4 Address Family. out changes the advertisement to that peer; it does not force the Sophos Firewall’s outbound traffic path. The official SFOS 22 page documents setup, but not a complete rollback procedure. Implement the change only after the exact removal commands for the installed build have been confirmed separately and documented in a recovery plan alongside the previously saved show running-config.

After an approved change, show ip bgp on the receiving router must show the expected MED and preferred path. On a Sophos peer, the route also appears under Routing > Information > BGP-IPv4 > Routing. Without this before-and-after comparison, this section is decision guidance rather than an executable production change.

BGP over route-based IPsec and cloud VPN

BGP can run over an addressed XFRM interface of a route-based site-to-site IPsec tunnel. Assign suitable transit IPs to both XFRM interfaces. Permit Dynamic Routing selectively for the VPN zone; rules for user traffic are still required.

For cloud connections, do not choose the values freely:

For AWS Site-to-Site VPN, the inside tunnel addresses, Remote AS, and other tunnel values come from the AWS configuration. Test both AWS tunnels separately.
For Azure VPN Gateway, the local XFRM IP must match the intended BGP peer IP; the local and Azure ASNs must be different.

A green IPsec tunnel and a BGP Neighbor in Established are two separate checks. The expected prefixes and actual application traffic must work afterward.

Isolate errors systematically

Neighbor remains Active or does not appear

Active does not mean that the session is working. The firewall is still trying to establish a BGP connection. First check direct reachability of the peer IP, interface and tunnel status, Local AS, Remote AS, and the Neighbor IP. Then check whether Dynamic Routing is allowed in the correct zone or through an appropriate Local Service ACL Exception.

For XFRM, also make sure both tunnel addresses are correct and the IPsec tunnel is up. For cloud and XFRM setups, also check the rules required by the respective VPN design. If their services are restricted, they must include TCP 179 between the two peer IPs. Device Access or the Local Service ACL for the local BGP service remains separate from those rules.

Neighbor is Established, but the remote network is missing

The session works, but the prefix is not being advertised or accepted. Check the Network entry, its IP version and mask, and show running-config; then use Routes and Summary on the peer to see whether the prefix arrives or is rejected by a policy.

If a network behind a policy-based IPsec tunnel disappears after an upgrade to SFOS 22, the previous dependency on redistribute kernel may be the cause. The BGP session can remain Established; SFOS 22: IPsec routes and redistribute kernel explains the version change and the route-based XFRM target design.

The BGP route is visible but not used

First use Route Lookup to determine which route wins for a specific destination IP. A more specific route takes precedence over a broader prefix. If several sources compete, evaluate Administrative Distance and BGP attributes separately, and only then the global Route Precedence category.

The route is correct, but traffic does not work

BGP has completed its task once the correct route is installed. Errors then usually lie with the firewall rule, NAT, return path, or destination system. For normally routed site networks, SNAT is often unnecessary because both sides should know the real LAN prefixes.

Advanced settings disappeared after a WebAdmin edit

WebAdmin exposes only the base values. If a Neighbor was saved there after advanced CLI configuration, its password, Route Map, or changed defaults may have been removed. Applying Global configuration also removes changes to bgp log-neighbor-changes and no bgp ebgp-requires-policy. Compare the saved configuration, restore the values through the CLI, and save them with write.

Map BGP and routing logs

The SFOS 22 log reference maps BGP and BGPv6 to bgpd.log. zebra.log covers the installation of dynamic IPv4 and IPv6 routes in the kernel; for route-based IPsec, xfrmi.log covers the XFRM tunnel interface. This mapping supports a staged diagnosis: first check the BGP session and advertisement, then installation in the system routing table, and finally the tunnel state if required. Sophos Firewall services and log files explains how to access these and other files. Undocumented live-shell commands are not required for this validation.

Roll back the change safely

Before removing BGP, an alternative path or a maintenance window must exist for every learned destination network. First remove the affected Networks and Neighbors. Change the global BGP configuration only when no other peers depend on it. Disable Dynamic Routing only when the zone no longer requires another dynamic routing service.

In WebAdmin, first remove unneeded advertisements under Routing > BGP > Networks, then the affected peers under Neighbors. Verify replacement routes after each step. Leave Router ID and Local AS unchanged while other BGP connections depend on them; changing the Local AS would delete all remaining Neighbors and Networks.

The reviewed SFOS 22 sources document no complete CLI command for deleting the entire BGP process; no such command is derived or recommended. Advanced CLI policies require removal commands confirmed for the installed build and the saved prior configuration block.

Then recheck Routing Information, Route Lookup, management access, and actual traffic. A rollback is complete only when the BGP session has disappeared and all required destination networks remain reachable over the intended replacement path.