Set up Site-to-Site RED between two Sophos Firewalls

A Site-to-Site RED tunnel connects two Sophos Firewalls directly without requiring an SD-RED appliance at either site. One firewall acts as the Firewall RED server and accepts the connection. The other acts as the Firewall RED client and establishes the tunnel to the server.

This current SFOS 22 workflow must not be confused with a RED operation mode such as Standard/Unified or Standard/Split. These modes apply to a physical SD-RED. A firewall-to-firewall design instead uses RED interfaces, static routes, and matching firewall rules on both firewalls.

⚠️ Before making changes, create a current backup of both firewalls, confirm independent administrative access, and document a recovery path. If possible, do not translate the public address of the Firewall RED server using NAT because address translation can interfere with incoming RED connections.

The workflow in eight steps

1. Plan the roles, RED IPs, site networks, and reachable server address.
2. Turn on the RED provisioning service on both firewalls and allow the RED control path.
3. Create the Firewall RED server interface at the central site.
4. Transfer the generated provisioning file securely to the peer site.
5. Create the Firewall RED client interface at the branch and import the file.
6. Add a static route to the remote LAN on both sides, using the peer RED IP as gateway and leaving the interface unselected.
7. Allow data traffic on both firewalls with narrow logged rules; don’t create a linked NAT rule.
8. Verify the tunnel, route, rule match, and real bidirectional traffic separately.

A green RED interface only confirms that the tunnel has been established. It does not prove that routing, firewall rules, and the return path work.

Planning and design

When Site-to-Site RED fits

Site-to-Site RED is a streamlined way to connect two Sophos Firewalls. RED provisioning handles part of the traditional VPN negotiation, while the remote LAN networks still use normal routing and firewall rules.

New designs should still make a conscious choice between RED and Site-to-Site IPsec. IPsec offers more profile, routing, interoperability, and redundancy options. Site-to-Site RED is attractive when both endpoints are Sophos Firewalls and a simple Sophos-specific tunnel is sufficient.

A physical SD-RED is configured with Set up and troubleshoot Sophos SD-RED. The RED operation modes do not apply to the firewall-to-firewall tunnel described here.

Plan the example topology

The following example deliberately uses documentation addresses. Replace all of them with the actual networks and addresses of the two sites:

• Central site, Firewall RED server role: public address 198.51.100.10, LAN 10.10.0.0/16
• Branch, Firewall RED client role: public address 203.0.113.20, LAN 10.20.0.0/16
• Central-site RED IP: 10.255.100.1
• Branch RED IP: 10.255.100.2

The two RED IPs form the address pair between the firewalls. They must not conflict with a site LAN or another interface or VPN network. The client firewall must be able to reliably reach the server’s public IP address or FQDN.

This example uses 255.255.255.252 (/30) as the RED netmask. This small transit network contains exactly the required address pair. If you choose another unused transit network, replace both RED IPs and the netmask consistently. RED doesn’t resolve overlapping site LANs; settle the addressing or NAT design before creating the tunnel.

Sophos explicitly describes RED interfaces as secure, encrypted tunnels. When you register the RED provisioning service, SFOS uses the registration details to generate a certificate for secure RED communication. The documented firewall-to-firewall interface workflow therefore doesn’t ask you to select a PSK or certificate manually: the server generates a Provisioning file containing configuration data for the client. Transfer the file only over a protected channel.

Configure the tunnel and data path

Create the Firewall RED server

First create the server on the firewall with a reliably reachable public address:

1. Go to System services > RED and turn on the RED provisioning service.
2. Open Network > Interfaces.
3. Select Add interface > Add RED.
4. Under Branch name, enter a name such as RED-HQ-Branch.
5. Set Type to Firewall RED server.
6. Leave Tunnel ID set to Automatic.
7. Enter 10.255.100.1 as the RED IP.
8. Enter 255.255.255.252 as the RED netmask.
9. Assign a deliberately chosen zone. This example uses a custom zone named RED-S2S.
10. Initially leave Tunnel compression and MTU unchanged, then save.
11. Under Network > Interfaces, select Download provisioning file from the new RED interface’s menu.

The provisioning file belongs to this tunnel and should be treated as a sensitive configuration artefact. Transfer it to the branch over a protected channel and do not leave it in a generally accessible download or shared folder after the import.

The zone later affects rule and Device Access matches. LAN is possible, but a dedicated zone usually creates a clearer security boundary when several sites exist. Configure zones and interfaces on Sophos Firewall explains the general relationships.

Automatic avoids accidentally reusing a Tunnel ID. If an operational requirement makes you set it manually, Sophos says the tunnel must not already be in use on either device. In the documented client workflow, you don’t enter a second Tunnel ID; the server’s provisioning file provides the association. Tunnel compression can improve RED throughput over slow internet connections, but uses processing resources; change it only after a reproducible before-and-after measurement. The RED interface MTU affects fragmentation; an MTU or fragmentation problem can therefore block larger flows even while the tunnel is up. Test a smaller MTU only when a fragmentation or Path MTU problem has been demonstrated.

Create the Firewall RED client

At the peer site, create the client with the file generated by the server:

1. Here too, go to System services > RED and turn on the RED provisioning service.
2. Create a new interface under Network > Interfaces > Add interface > Add RED.
3. Use a Branch name such as RED-Branch-HQ.
4. Set Type to Firewall RED client.
5. Under Firewall IP/hostname, enter the public address or FQDN of the server.
6. Under Provisioning file, select the file from the server firewall.
7. Enter 10.255.100.2 as the RED IP.
8. Enter the same 255.255.255.252 RED netmask.
9. Assign the planned RED-S2S zone, initially leave Tunnel compression and MTU unchanged, and save.

If the client can reach the server only through a translated or changing address, DNS, upstream NAT, and the return path require especially careful testing. Sophos recommends making the server directly reachable without NAT where possible.

The client firewall initiates the outgoing connection, so the branch doesn’t need an equivalent inbound publication.

Add static routes without an interface

After establishment, the tunnel does not automatically know the LAN networks behind the firewalls. Create an IPv4 unicast route on both sides:

• Central site: destination 10.20.0.0/16, gateway 10.255.100.2
• Branch: destination 10.10.0.0/16, gateway 10.255.100.1

The critical RED exception is that no interface is selected for these two routes. The firewall sends ARP requests to determine the reachable RED interface for the peer address. Selecting an interface later can interfere with this mechanism and is not an improvement.

Create the route under Routing > Static routes > IPv4 unicast route > Add. Choose the administrative distance and metric deliberately to match the wider routing design. Set up and test a static route on Sophos Firewall explains the general field logic and Route Lookup validation.

Restrict the RED service and firewall rules

First, the local RED service must be allowed to accept the connection. Under Administration > Device access, turn on RED only for the zone from which the RED connection actually arrives. If the public source addresses are stable and known, instead create a narrow Accept rule under Local service ACL exception rule > Add, specifying Source zone, Source Network / Host, the WAN interface as Destination host, and Services: RED. Normal firewall rules can’t control local services. Device Access and Local Service ACL explains this separation.

Forwarded traffic then needs matching rules under Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule. For a test flow initiated at the central site and a custom RED-S2S zone, use:

• Central site: Source zones LAN, Source networks and devices 10.10.0.0/16, Destination zones RED-S2S, Destination networks 10.20.0.0/16, and only the required Services.
• Branch: Source zones RED-S2S, Source networks and devices 10.10.0.0/16, Destination zones LAN, Destination networks 10.20.0.0/16, and the same required Services.

For connections initiated by the branch, add the pair with networks and zones reversed. Keep Log firewall traffic on during validation and position each rule so that a broader rule doesn’t match first. Leave Create linked NAT rule off. This normally routed site connection should preserve real source addresses and have complete return routes. Don’t overwrite an existing, deliberately required NAT exception without reviewing it. Understand and configure Sophos Firewall rules explains the rule mechanics in detail.

Validation, troubleshooting, and rollback

Validate the tunnel in a controlled way

Start validation with a single test flow whose exact time is recorded. First confirm that both RED interfaces are active and that Route Lookup for an address in the remote LAN shows the expected path. The flow must then match the intended Rule ID on both firewalls.

A packet capture on Sophos Firewall shows whether the packet enters the RED interface on the source side, arrives at the peer, and is forwarded to the destination LAN. Test the return path separately. A ping alone is insufficient when the production application uses TCP or UDP on different ports.

Success therefore means all of the following at the same time:

• The RED interfaces are up on both sides.
• Route Lookup shows the planned path in both directions.
• The expected firewall rule matches on both firewalls.
• A real application flow works bidirectionally.
• Source and destination addresses appear without unintended NAT.
• After a controlled restart, a new flow is established successfully again; an HA cluster also requires a separate failover test.

For HA, Sophos explicitly documents a delay while RED tunnels reconnect to the auxiliary firewall after failover. The duration varies with the number of interfaces and other settings, and the warning applies to Site-to-Site RED tunnels as well as RED appliances. Don’t promise immediate recovery: record the failover time, interface state, and reconnection time, then retest the application flow.

Isolate errors systematically

The client does not establish the tunnel: Check the RED provisioning service, server address, DNS, reachability, Device Access, and the provisioning file that belongs to the tunnel. Do not blindly combine a new file with an old client configuration.

The provisioning file is rejected: Confirm that it comes from the server interface currently in use and wasn’t changed during transfer. Don’t hastily delete the server interface: preserve the previous state first, then download a fresh file from the server if necessary and recreate the client cleanly in a maintenance window.

The tunnel is up, but the remote LAN is unreachable: Check the destination network and peer RED IP of the static route on both sides. No interface may be selected for this special RED route. Then verify the rule match and return route.

Only one direction works: A matching rule or route is usually missing on one firewall, or another more specific or higher-priority path already reaches a site network. Route Lookup, packet capture, and real return traffic must agree.

The connection is unstable: Correlate latency, packet loss, public server reachability, NAT in front of the server, and WAN-path changes. Save node-local logs for the exact test time. Find and analyse Sophos Firewall service logs explains the log files and support paths.

The tunnel is up, but flows with larger packets stall: In packet capture, inspect both directions for fragmentation and Path MTU ICMP messages. Compare the MTU values of both RED interfaces and test different packet sizes. Only with that evidence should you test the same MTU gradually on both interfaces. Never change compression and MTU together, or the cause remains ambiguous.

No broad Any rule, blanket WAN allowance, service restart, or random change to RED IPs and routes replaces this correlation. If the error remains unclear despite a correct design, collect the backup, SFOS build, timestamp, interface status, routes, Rule IDs, packet capture, and relevant logs for Sophos Support.

Roll back safely

If the pilot fails or the design is rejected, first disable the additional firewall rules and remove the two static routes. Then delete the client RED interface and finally the server RED interface in a controlled way. Restore temporary Device Access or Local Service ACL allowances and changed MTU or compression values to their documented previous state; remove newly created host and network objects only if nothing else uses them.

Do not remove an existing management path that uses this tunnel until an alternative access method has been tested successfully. After rollback, verify normal routing, the previous rules, and reachability of both firewalls again.

FAQ