Create and test a custom gateway on Sophos Firewall

A custom gateway on Sophos Firewall describes a next hop on an existing interface. The object is particularly useful for MPLS, RED, and addressed XFRM paths because it can have its own health check and zone and can then be used in an SD-WAN route. SFOS supports custom gateways for IPv4 and IPv6; the example throughout this article uses IPv4.

Quick answer

Create a custom gateway here:

Routing > Gateways > Add

For an MPLS path through Port4, for example, enter:

• Name: MPLS_Zurich_GW
• Gateway IP: 192.0.2.2
• Interface: Port4-192.0.2.1
• Zone: MPLS
• Health check: On
• Monitoring condition: PING to 10.20.0.10

You must then select the gateway in a matching SD-WAN route and test it with the firewall rule, return path, Log viewer, and actual traffic. A green status icon only confirms the health check, not the operation of the entire connection.

⚠️ A custom gateway is not an additional physical WAN gateway. It doesn’t appear under Network > WAN link manager and doesn’t participate in WAN load balancing, even if you assign the WAN zone.

Distinguish the custom gateway, route, and interface

Several objects have different roles in a working path:

• The interface connects the firewall to the transit network, such as Port4, RED, or XFRM.
• The Gateway IP is the directly reachable next router on this path.
• The custom gateway combines the gateway IP, interface, zone, and optional health check in a reusable object.
• The SD-WAN route decides which traffic uses this gateway.
• The firewall rule allows the planned zones, networks, and services.
• The remote side needs a matching return path.

A normal static route can contain the gateway IP directly and doesn’t require a separate gateway object. A custom gateway becomes useful when SFOS must monitor the path, select it in an SD-WAN route, or classify it through a gateway zone.

Physical WAN gateways, by contrast, are created automatically when a WAN interface is configured and are managed as Active or Backup in the WAN link manager. This separation prevents an internal MPLS or tunnel path from being treated as an internet connection by mistake.

For these automatically created gateways, the zone cannot be changed under Routing > Gateways. The default gateway is fixed to the WAN zone. The selectable gateway zone in the procedure below applies to custom gateways, not to the default gateway.

Use Network > WAN link manager for a cellular WAN gateway’s failover rules. Cellular WAN and 4G/5G failover explains setup, cellular probe targets, and the switchover test.

Plan the example topology

The continuous example connects a client network to a remote server network through an MPLS router:

• Local client network: 10.10.0.0/24
• Test client: 10.10.0.10
• Firewall interface: Port4 with 192.0.2.1/30
• MPLS router: 192.0.2.2
• Remote network: 10.20.0.0/24
• Stable monitoring and test host: 10.20.0.10
• Test service: TCP 443
• Custom zone: MPLS of type LAN

192.0.2.0/24 is a documentation network and isn’t used in production. For the real environment, replace the interface IP and gateway IP together with the actual transit network. The remote network and monitoring host must genuinely be behind this gateway. Create the MPLS zone beforehand under Network > Zones and secure it according to the path’s trust level; zones and interfaces on Sophos Firewall explains the fundamentals.

Before the change, document the existing route, firewall rules, NAT expectation, and return path. A remote change also requires a configuration backup, a maintenance window, and an independent management path.

Create the custom gateway

Enter the basic gateway values

1. Open Routing > Gateways.
2. Under IPv4, click Add.
3. Enter MPLS_Zurich_GW as the Name. The name is freely selectable but should identify the site and path.
4. Enter 192.0.2.2 as the Gateway IP. This is the directly reachable MPLS router, not the remote destination network.
5. Select Port4-192.0.2.1 as the Interface. The gateway IP and interface must belong to the same reachable transit path.
6. Select MPLS as the Zone.

Sophos Firewall prioritizes the gateway zone over the interface zone. However, it only applies to traffic when the gateway is selected in a matching SD-WAN policy route. With a static route alone, the gateway zone isn’t applied; the actual interface zones and the matching firewall rule determine the zone match. You can’t assign the VPN zone to a custom gateway.

The gateway zone doesn’t apply to SD-WAN policy routes migrated from SFOS 18.0 MR1 or earlier. In this case, a visible zone field alone doesn’t prove that an existing rule is correct. Test the route, zone match, and actual traffic first in a maintenance window.

Existing custom gateways can also be edited, cloned, and deleted under Routing > Gateways. Before deletion, check dependencies as described in the rollback procedure below.

Choose a health check that represents the path

Health check is turned off by default. SFOS documents these default timing values:

• Interval: Time between health-check probes; the default is 60 seconds.
• Time-out: Response deadline for a probe to count the gateway as active; the default is 2 seconds.
• Retries: 3

Retries sets the number of consecutive probe attempts. If none of these attempts receives a response, SFOS considers the gateway unreachable. Sophos doesn’t provide a complete formula for the exact failure-detection time, so consider Interval, Time-out, and Retries together. Protocol and IP address, by contrast, are design choices. This example uses PING to 10.20.0.10.

The monitoring host is deliberately behind the gateway. If you only checked the directly adjacent gateway IP, the router could respond even though the downstream MPLS or tunnel path is interrupted. Sophos generally requires a continuously available host behind the gateway as the probe target. The official Any-to-Any XFRM example follows the same principle.

Alternatively, you can use TCP with a specific port. This is useful when the check should cover not only IP reachability but also a stable responding service. However, a TCP check on port 443 marks the gateway as down when the web service fails, even though routing may still work. The probe target and protocol must therefore represent the intended failover signal.

To add another monitoring condition, select AND or OR under Operator and click the add icon. Then set the additional condition’s protocol, destination IP, and, for TCP, port. The operators work as follows:

• AND: All conditions must be met. This is strict but can cause an unnecessary switchover when a single target fails.
• OR: SFOS checks conditions from top to bottom until one is met. This reduces false alarms but may hide a partial outage.

Don’t shorten the interval, time-out, or retries without evidence. First measure normal latency and temporary packet loss on the actual path. Aggressive values can make the status flap between active and inactive.

After saving, Routing > Gateways shows with a status icon whether the health check considers the gateway active or inactive.

Use the gateway in the routing design

Create an SD-WAN route for the example traffic

A gateway object doesn’t forward traffic by itself. For the example, create an SD-WAN route:

1. Open Routing > SD-WAN routes > IPv4 > Add.
2. Enter Clients_to_Branch_MPLS as the Name.
3. Select the internal interface as the Incoming interface.
4. Set Source networks to 10.10.0.0/24.
5. Set Destination networks to 10.20.0.0/24.
6. Initially select only HTTPS, or TCP 443, under Service.
7. Under Link selection settings, use Primary and backup gateways.
8. Select MPLS_Zurich_GW as the Primary gateway.
9. Only enter a real backup path if it is fully configured and tested.
10. Set Route only through specified gateways deliberately: When selected, SFOS drops the traffic if none of the specified paths is available; when cleared, another SD-WAN route or the default route can take over.
11. Save the route and check its position. The first matching SD-WAN route wins.

The networks and service are environment-specific values. A broad route with Any as source, destination, and service can match far more traffic than intended. Keep the match narrow for the first test and only expand it deliberately after successful validation.

The SFOS 22 default for Route Precedence is static, SD-WAN, VPN. If SD-WAN precedes Static and an SD-WAN route uses Any as its destination, it can also capture internal or directly connected traffic and interrupt management access. The example’s narrow destination avoids this problem. If the design requires more than a Primary and Backup gateway, use an SD-WAN Profile with up to eight gateways instead.

Add the firewall rule and return path

For the forwarded stream, create a logged rule from the client network’s source zone to the MPLS gateway zone. The source, destination, and service match the SD-WAN route:

• Source zones: LAN
• Source networks and devices: 10.10.0.0/24
• Destination zones: MPLS
• Destination networks: 10.20.0.0/24
• Services: HTTPS
• Log firewall traffic: selected

The gateway zone doesn’t replace a firewall rule. Conversely, a rule alone doesn’t enforce the MPLS path. Both must align with the SD-WAN route. Create and safely test Sophos Firewall rules explains the general rule design.

The router behind the remote network needs a return path to 10.10.0.0/24. In normal site routing, the original client IP usually remains unchanged. A broad MASQ rule would hide it and may appear to repair the return path while making the routing design worse.

Distinguish XFRM and other tunnel paths

With route-based IPsec using Any-to-Any, the XFRM interface receives a transfer IP. A custom gateway then uses the peer XFRM IP as the Gateway IP, the local XFRM as the Interface, and a stable host in the remote network as the monitoring target. The complete tunnel configuration remains in Set up a site-to-site IPsec VPN.

Forward a virtual IP over IPsec to multiple servers shows how a remote site reaches a virtual IP through such an XFRM gateway and mirrored SD-WAN routes while DNAT distributes connections across several internal servers.

Route-based IPsec with specific traffic selectors is different: no additional manual route is created for those traffic selectors, and the XFRM doesn’t receive its own IP. Don’t apply an Any-to-Any gateway recipe to this variant.

Validate the gateway and traffic

Check status and usage

1. Under Routing > Gateways, MPLS_Zurich_GW must appear active.
2. Refresh Object usage and verify that the expected SD-WAN route uses the gateway.
3. Recheck the match criteria, position, and gateway in the SD-WAN route.
4. Under System services > Log settings, verify that the SD-WAN module is being logged. Then check Log viewer for gateway, health-check, and route events.
5. For deeper diagnostics, use dgd.log as the Dead Gateway Detection log; Sophos Firewall service and log files explains its context.

The active gateway status only proves that the monitoring host responds under the selected condition. Object Usage only proves the configuration reference. Only the following real-world test confirms the data path.

Test a real traffic flow

1. From the test client 10.10.0.10, start a new HTTPS connection to 10.20.0.10.

2. In Log viewer, check the source, destination, service, Firewall Rule ID, any NAT Rule ID, and the gateway used.

3. Check the traffic count of the SD-WAN route. OUT counts requests and IN counts replies where each direction matches the route’s Source and Destination; a one-sided counter alone therefore doesn’t prove a path failure.

4. Under Diagnostics > Packet capture, use a narrow BPF filter:

   host 10.20.0.10 and tcp port 443
   

5. Verify that requests leave through Port4 and replies return over the same planned path.

6. On the destination system, check the actual source IP and return path.

The Policy tester doesn’t account for SD-WAN routes. It can test a firewall-rule match, but not the gateway that was actually used. Test a Sophos Firewall rule with Log Viewer and Packet Capture covers the combined validation.

Only run a failover test with a separately validated backup path, in a maintenance window, and with an independent management path. Don’t delete the referenced production gateway as a test method. After the controlled path failure, retest a new connection, gateway status, public or private source IP, return path, and failback. When the Primary gateway returns, new connections use the Primary again; existing connections initially remain on the Backup.

By default, SFOS 22 reroutes non-SNAT connections when the gateway or SLA changes. This doesn’t happen automatically for SNAT connections. Rerouting with SNAT requires the same translated source IP on both paths and the separate reroute-snat-connection option; MASQ or different source IPs therefore often prevent a seamless switchover. Don’t assume a disruption-free transition during acceptance testing.

Troubleshoot systematically

The gateway remains inactive

• The gateway IP and interface must describe the same directly reachable transit path.
• The monitoring host must genuinely be behind the gateway and respond reliably.
• For PING, verify that ICMP is allowed along the entire path.
• For TCP, check the correct port and a service that is actually running.
• Use Packet Capture to verify that the probe and reply use the expected interface.
• Only change the interval, time-out, and retries after checking the path.

XML API on SFOS 23: For Add Gateway Object and Update Gateway Object, API status 505 is documented with the message identifier Message.GatewayIpNotInInterfaceIpRange. This is the status in the API response, not an HTTP status code; the identifier does not guarantee the exact wording of the displayed message. If you receive this result, check the selected interface’s network and the intended next-hop address (Gateway IP) before retrying. Its documentation in SFOS 23 does not establish that address validation was first introduced in this version.

The gateway is active, but application traffic doesn’t work

• The SD-WAN route may be missing, placed too low, or matching different source, destination, or service values.
• The firewall rule’s source zone and gateway zone must match the actual flow.
• Check route precedence, NAT, and return path separately.
• The monitoring host may be reachable even when another destination host or service is down.
• An active XFRM gateway doesn’t automatically prove that the IPsec SA, firewall rule, and remote route are correct.

The gateway zone appears to be ignored

• Verify that the gateway is actually selected in the matching SD-WAN policy route.
• For a static route alone, check the interface zone and the firewall rule that actually matches.
• The gateway zone doesn’t apply to an SD-WAN route migrated from SFOS 18.0 MR1 or earlier. Don’t hide the path with a broad rule; modernize the route and zone design in a controlled manner.
• You can’t select the VPN zone for a custom gateway. An XFRM interface is still a VPN interface and requires a deliberate rule and routing design.

The status unnecessarily flaps between active and inactive

• Check the probe target for actual availability and rate limits.
• Measure normal latency and packet loss before changing values.
• With AND, a single target can make the entire gateway inactive.
• With OR, one reachable fallback target can hide a partial outage.
• Don’t use shorter intervals or time-outs as a general stability fix.

Roll back safely and operate the gateway

Before rollback, document Object Usage, the original route, and the original firewall rules. Then:

1. Disable the new SD-WAN route or restore the previous path.
2. Use a new client connection to verify that the original path works again.
3. Remove firewall or NAT rules created only for the test once no dependency remains.
4. Refresh Object Usage.
5. Delete the custom gateway only when no route or profile uses it anymore. If you delete a Backup gateway, SFOS sets the route’s Backup to None. If you delete the Primary gateway or the selected SD-WAN Profile, SFOS deletes the SD-WAN route and then uses the default route WAN link load balance.

For ongoing operation, document the owner, gateway IP, interface, zone, probe targets, protocol, interval, time-out, retries, routes that use the gateway, and the latest failover test. After changes to MPLS, RED, XFRM, zones, SD-WAN, or the monitoring host, retest both the status and actual traffic.

FAQ