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.
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 the data traffic on both firewalls with narrow logged rules, and allow the RED service only from the required zones.
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.

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.

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. Assign a deliberately chosen zone and save the interface.
9. From the menu of the new RED interface, download the provisioning file.

The provisioning file belongs to this tunnel and should be treated as a sensitive configuration artifact. 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.

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. Assign the planned zone and save the interface.

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.

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 firewall rules and the RED service

Forwarded traffic requires a matching rule on both firewalls. A broad LAN-to-LAN rule is a simple functional example, but production rules should restrict the source network, destination network, and services to the actual requirement. Keep logging enabled during validation.

For this example, the central firewall needs a rule from LAN 10.10.0.0/16 to the branch network 10.20.0.0/16. On the branch, represent the required return or reverse-direction traffic accordingly. NAT is normally unnecessary for a routed site connection; both sides should see the real source addresses and have a complete return path. Understand and configure Sophos Firewall rules explains the rule mechanics in detail.

The RED service must also be reachable from the zones where the RED connection arrives. Under Administration > Device access, RED can be turned on for a zone. If stable source addresses are known, a narrow Local service ACL exception rule is preferable to a broad allowance for the entire WAN zone. The exception applies only to the RED control path and does not replace a firewall rule for site traffic. See Device Access and Local Service ACL for details.

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 or failover, a new flow is established successfully again.

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 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 analyze Sophos Firewall service logs explains the log files and support paths.

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 to their documented previous state.

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