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, GRE, and addressed XFRM paths because it can have its own health check and zone and can then be used in an SD-WAN route.

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.

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. For a static route alone, therefore, test the zone behavior separately. 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.

Choose a health check that represents the path

Health check is turned off by default. For a monitored MPLS, RED, or XFRM path, turn it on and start with the documented default values:

• Interval: 60 seconds
• Time-out: 2 seconds
• Retries: 3
• Protocol: PING
• IP address: 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. For custom gateways on route-based VPN, RED, and MPLS, Sophos explicitly specifies a host behind the gateway as the probe target.

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.

With multiple monitoring conditions:

• 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 Services.
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.

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 zone: LAN
• Source network: 10.10.0.0/24
• Destination zone: MPLS
• Destination network: 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, GRE, 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.

Route-based IPsec with specific traffic selectors is different: SFOS creates the route automatically, and the XFRM receives neither its own IP nor a manual route. Don’t apply an Any-to-Any gateway recipe to this variant without checking it.

A GRE path doesn’t begin with the gateway object either. First validate the outer endpoints, tunnel IPs, and GRE function using Configure and test a GRE tunnel on Sophos Firewall. If the provider design then requires SD-WAN selection, the custom gateway uses the peer tunnel IP as its Gateway IP. The zone, health check, and rule match must fit the specific design; the VPN zone remains unavailable for custom gateways.

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. In Log viewer, check the SD-WAN module 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.

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. Don’t assume a disruption-free transition.

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.

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.

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