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.
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 directly reachable peer IP to which the BGP session is established.
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. The BGP session itself is established over TCP 179 and is permitted to the firewall through Device Access or a Local Service ACL. User traffic over a learned route still 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 networks to advertise already exist as matching routes in the local routing table.
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 safer than broad access for the entire zone. Under Administration > Device access > Local service ACL exception rule > Add, create an Accept rule for the peer zone, the specific peer IP or restrictive transit network, the required firewall address, and the Dynamic Routing service. Then test access from the permitted peer IP and from a source that is not permitted.

Device Access controls only the BGP connection to the firewall. Production connections between the two LANs still require normal firewall rules. Secure Device Access on Sophos Firewall explains this separation.

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 does not create a route. The exact prefix must already exist in the local routing table, for example as a directly connected network or static route. If it is missing or the mask differs, the BGP session may still be Established, but the Network is not advertised.

Enter only the prefixes that are actually required. Unrestricted redistribution of connected or static routes can also include WAN, management, or blackhole networks and belongs in production only with verified filtering.

Test and accept 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
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.

Route Precedence and BGP path selection

system route_precedence does not decide between BGP and a static route. The global setting only orders the categories static, sdwan_policyroute, and vpn; BGP and other dynamic routes belong to the static category in this context.

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.

Display the current global order in 4. Device Console:

system route_precedence show

Change it only when routing categories actually compete. Adjust routing priority on Sophos Firewall explains the relationships and safe examples.

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. On the sending firewall, the Network must exist in the local routing table with exactly the same mask. Then check Networks, filters, and show running-config. Fix a missing local route instead of concealing it with a disabled BGP Network Import Check.

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. Compare the saved configuration, restore the values through the CLI, and save them with write.

Check BGP and routing logs

In 5. Device Management > 3. Advanced Shell, two log files show the different layers:

tail -f /log/bgpd.log

bgpd.log records BGP and BGPv6 events. Stop the live output with Ctrl+C. If BGP knows a route but it does not appear in the system, continue with:

tail -f /log/zebra.log

To read without following the log live, use, for example:

less /log/bgpd.log

For route-based IPsec, /log/xfrmi.log can additionally explain the state of the XFRM interface. Sophos Firewall services and log files maps further files.

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.

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.