Choose the right Sophos RED operation mode

The operation mode of a Sophos SD-RED is not a minor detail. It determines who provides DHCP and the gateway at the remote site, which traffic uses the RED tunnel, whether internet access is inspected centrally, and what continues to work if the tunnel fails. A Site-to-Site RED tunnel between two Sophos Firewalls is a different design and does not use these four operation modes.

For new, centrally managed branches, Standard/Unified is usually the clearest starting point. Standard/Split saves tunnel bandwidth but removes local internet traffic from central control. Transparent/Split integrates the RED into an existing network. Manual/Split is a special cabling and routing design for local internet autonomy, not an ordinary quick mode.

Decide on the operation mode before configuring DHCP, VLANs, firewall rules, and the rollout. Changing it later alters the traffic path and requires a maintenance window with controlled functional tests.

This guide covers SFOS 22.0 and the SD-RED 20 and SD-RED 60 models supported by that release. RED 15/15w and RED 50 devices no longer connect from SFOS 20.0 MR1 onward. Legacy Firewall RED interfaces between UTM and SFOS must be replaced and deleted before upgrading to SFOS 22.0; otherwise, upgrades, restores, and imports are blocked. From SFOS 21.0 MR2 and 21.5 MR1 onward, RED system hosts are automatically assigned a /32 mask. Under Hosts and services > IP host, open Usage for each RED system host and replace it in dependent rules and routes with the correct IP host or network host where the old interface subnet was intended. These migration checks should therefore be part of the change plan before a hardware or firewall migration.

The four RED operation modes at a glance

This summary helps with the initial choice, but it does not replace a review of failure behavior, VLANs, and security. In particular, Split does not automatically mean fail-open, and Transparent does not automatically mean that VLAN tags are passed through.

Standard/Unified: Everything through the central site

In Standard/Unified, Sophos Firewall provides DHCP and the default gateway through the RED interface. The SD-RED forwards all traffic through the encrypted tunnel, including the branch’s internet traffic.

This provides the highest level of central control. Firewall rules, web policies, IPS, Application Control, reporting, and central internet access can be implemented consistently at the head office. At the same time, the tunnel and the central WAN connection must handle more traffic because ordinary branch internet traffic also traverses the site path twice.

If the RED tunnel fails, clients lose more than access to internal networks. Because their gateway is located on Sophos Firewall across the tunnel, internet access normally fails as well. Standard/Unified is therefore suitable when central security is more important than local internet availability during a tunnel outage.

When Standard/Unified fits

• All site traffic must be inspected and logged centrally.
• DHCP, DNS forwarding, rules, and internet access should converge on Sophos Firewall.
• The central WAN capacity is sufficient for the branch’s additional internet traffic.
• A tunnel failure may deliberately take the site offline, or a tested second RED uplink exists.
• VLANs must be transported through an SD-RED 60.

Standard/Split: Central networks through the tunnel

With Standard/Split, Sophos Firewall remains the DHCP server and default gateway for the network provided by the RED. Only the destination networks entered under Split networks use the tunnel. Other destinations, typically the internet, leave the site through the RED’s local WAN connection.

This relieves the tunnel and the central internet connection. The trade-off is a clear security boundary: Sophos masks the local internet traffic at the RED, but the central firewall cannot inspect it with its firewall, web, or IPS rules. From the central firewall’s perspective, this traffic path is not ordinary forwarded internet traffic.

Split networks accepts IP networks. FQDN host objects are not supported here. VLAN-tagged frames are also not the correct traffic path in Standard/Split. Only the DHCP network provided directly by the RED receives local internet access through this mode.

Standard/Split is not a general fail-open design either. If the tunnel fails, Sophos documentation states that clients on the network provided by the firewall lose both central destinations and internet access. A design that requires local internet operation independently of the tunnel must be planned and tested differently.

When Standard/Split fits

• The branch needs only a few clearly defined networks at the central site.
• Local internet breakout is intentional and may remain outside central Sophos policies.
• Sophos Firewall can manage the remote network through DHCP.
• VLAN tagging through the RED tunnel is not required.
• The failure path has been tested and is not confused with Manual/Split.

Transparent/Split: RED in the existing network

Transparent/Split suits remote sites where the router, DHCP, DNS, and default gateway already exist and must remain in place. The RED operates transparently in the existing Layer 2 network. Only the configured split networks or split domains are routed through the tunnel to the central site.

This mode avoids changing the gateway for clients. Troubleshooting is more demanding, however: DHCP, DNS, and the normal internet path remain part of the local network, while selected destinations are redirected through the RED. Testing must therefore show separately which path stays local and which one actually enters the tunnel.

Transparent/Split does not transport VLAN-tagged frames. A 3G/4G failover uplink is also unavailable in this mode. For a wireless module, the remote DHCP server must pass DHCP option 234 containing the IP address of the RED interface at the firewall site to the access point; this is not the AP address, a branch address, or the firewall’s public address.

When Transparent/Split fits

• The existing router must continue to provide DHCP, DNS, and the default gateway.
• Only selected central networks or domains should be reachable through the RED.
• The RED can be integrated cleanly inline in the existing network.
• The site does not need VLAN tags across this RED traffic path.
• Local and tunneled traffic can be tested separately with Packet Capture and real destination tests.

Manual/Split: Local gateway with static routes

For an SD-RED, Manual/Split primarily describes a deliberately manual network design. The WAN and LAN sides of the RED are integrated into the existing site infrastructure so that the existing router remains the default gateway. That router receives static routes to the RED for the central networks.

The benefit is local autonomy: normal internet access can continue even if the RED tunnel or the RED itself fails. The trade-off is additional planning. Return paths, static routes, ARP behavior, and physical cabling must be exact. An incorrect next hop can bypass the tunnel for central traffic or send it into a dead end during an outage.

Sophos describes a manual physical deployment for this purpose and a RED configuration based on the Standard/Unified scheme, while the existing gateway and static routes determine the split. The term should therefore not be treated as an independent, self-explanatory switch.

Manual/Split belongs only in a documented design with:

• an alternative local gateway
• static routes for every central destination network
• a verified return path from the central site
• independent management access
• tests with an active tunnel, a disconnected tunnel, and a powered-off RED

Layer 2 and extension options

Use multiple REDs as a shared bridge network

A Bridged RED setup is not a fifth operation mode. It combines at least two existing RED interfaces in a bridge on Sophos Firewall. The remote RED networks then behave as one shared LAN, while firewall rules can still restrict traffic between the RED sites.

Create the bridge under Network > Interfaces > Add interface > Add bridge. Specify a clear name and the bridge interface, then select the required RED interfaces as Member interfaces with their zones. The address plan, DHCP ownership, and all bridge members must be coordinated first; multiple uncontrolled DHCP servers or duplicate IP addresses would then operate in the same Layer 2 network.

We recommend this design only when several branches genuinely require the same broadcast domain. Routed RED networks are easier to isolate, monitor, and change independently for typical branch deployments. After saving, test DHCP, ARP, site-to-site traffic, the responsible firewall rule, and intentionally blocked traffic. A green RED tunnel confirms the individual tunnels, but not the bridge or its rules.

A second uplink and a second firewall are not operation modes

The RED configuration can additionally contain a second firewall endpoint and, depending on model and mode, a second uplink. These options complement the chosen traffic path; they do not replace it.

A second firewall endpoint can be used for failover or load balancing. A second uplink can protect tunnel establishment. When both uplinks are set to Static, their DNS server IP addresses must differ; different DNS providers are not required. The RED checks the first uplink’s route entry for DNS resolution. If that gateway does not respond, it treats the DNS server IP as unreachable and does not retry the same IP address through the second uplink.

The tests must remain separate:

1. The selected RED mode must first work correctly through the primary uplink.
2. A controlled uplink failover is then tested.
3. RED status, DHCP, central destinations, and the internet path are checked again.
4. HA environments require a separate firewall failover test; the RED tunnel needs time to re-establish after the role change.

A green tunnel status alone proves neither the correct internet path nor functioning security policies.

VLANs and LAN port modes on SD-RED 60

The SD-RED 60 can transport VLANs through the tunnel, but only in Standard/Unified. Each LAN port additionally defines how the RED handles tagged and untagged frames.

• Tagged: Only the configured VLANs are forwarded with tags. Unconfigured VLANs and untagged frames are discarded. Up to 64 VLAN IDs can be entered per port.
• Untagged, drop tagged: Untagged frames are assigned to the configured VLAN; already tagged frames are discarded. This corresponds to a controlled access port.
• Disabled: The LAN port discards traffic.
• Untagged: Untagged frames receive the configured VLAN ID, while already tagged frames are forwarded unchanged. Only one VLAN configuration is possible per port. This is a hybrid port, not a freely configurable trunk; the allowed VLANs must still be controlled on the connected switch and on the firewall.

Sophos Firewall needs a matching VLAN interface on the RED interface for every VLAN in use. VLAN ID, IP network, DHCP, RED port mode, and switch configuration must match exactly. The complete firewall workflow is described in Configure and test a VLAN on Sophos Firewall.

Plan wireless behavior separately

Before setting up a wireless module, a RED interface with an IP address must exist, and DNS resolution must work on that specific interface. An optional wireless module for the SD-RED 20 or 60 can use three different traffic paths:

• Separate zone: Wireless traffic uses VXLAN to reach the firewall independently of the RED operation mode. Sophos Firewall must explicitly allow separate-zone traffic for the RED interface; this does not imply blanket WAN permission.
• Bridge to AP LAN: The wireless network is bridged to the access point’s local LAN.
• Bridge to VLAN: The wireless network is assigned to a VLAN; the exact behavior depends on the RED mode and VLAN configuration.

In Standard/Unified and Standard/Split, a correctly configured DHCP server must run on the RED interface. In the documented Transparent/Split wireless scenario, the remote network provides DHCP and DNS, and the RED interface must obtain its IP address from the remote DHCP server. That server must supply option 234 containing the IP address of the RED interface at the firewall site. Without this option, 1.2.3.4 is the documented fallback: it is a diagnostic clue to a missing option, not an address to configure in production. Wireless settings, LAN port mode, and RED operation mode should therefore be accepted as one design rather than three independent dropdowns.

Bridge to VLAN does not turn a split mode into general VLAN transport. In Standard/Split, wireless clients can reach local hosts with the same tag and, when present on the RED interface, the VLAN interface at the tunnel endpoint. They cannot reach the configured split networks because the RED routes those networks only for untagged packets. In Transparent/Split, the same VLAN extends locally across LAN ports 1–4 and the WAN port; split networks remain unreachable over this wireless traffic path.

Configure and safely test the operation mode

Prerequisites and exact fields

First, turn on the RED service under System services > RED. Then create or edit the appliance under Network > Interfaces > Add interface > Add RED. The key hardware fields are RED ID, Unlock code, Firewall IP/hostname, Device deployment, Uplink connection, RED operation mode, RED IP, Zone, Configure DHCP, RED DHCP range, and, for split modes, Split network.

For automatic deployment, the RED must start at least once on a network with DHCP and internet access so that it can download its configuration from the provisioning service. A static uplink requires manual deployment with a USB stick. The path must allow TCP 3400, UDP 3410, and NTP 123: the RED downloads its configuration and establishes the control channel over TCP 3400, then establishes the Layer 2 data tunnel over UDP 3410. Without a WAN DHCP address during automatic deployment, the device repeatedly restarts.

We recommend a dedicated LAN- or DMZ-type zone rather than the general LAN zone, so branch rules remain separate. If changing RED IP moves the RED interface to a subnet that no longer contains the existing RED DHCP range, SFOS turns off the RED DHCP server. Record this dependency in the change plan so clients do not unexpectedly lose their leases after a mode change.

Align routing, firewall rules, and NAT with the mode

Create firewall rules under Rules and policies > Firewall rules between the RED zone and only the required destination zones. Use Any for networks and services only for a time-limited functional test; restrict production rules to the required source networks, destination networks, and services. A RED-to-LAN rule does not replace a RED-to-WAN rule in Standard/Unified; the central internet path also requires a matching SNAT rule.

In Standard/Split, the RED itself masquerades local internet traffic with its public address. This path does not appear at the central firewall and does not need a central WAN SNAT rule. Centrally tunneled traffic, however, needs correct forward and return routes and matching firewall rules; existing NAT rules must not unintentionally translate its source or destination networks. In Manual/Split, test the static routes on the existing branch gateway and the return route at the central site as one pair.

Change the mode with a state-preserving rollback

Before the change, record the complete RED configuration, RED IP, zone, DHCP range and options, split networks, static routes, firewall and NAT rules, VLAN interfaces, LAN port modes, and an independent management path. Also save the last working configuration of the participating router and switch ports. Change one layer at a time: mode and RED network first, then DHCP, routing, and rules, and finally VLAN or wireless settings.

If acceptance fails, do not add more changes in parallel. Restore RED operation mode, RED IP, zone, DHCP, and split networks to the recorded values, reinstate the previous routes and rules, and renew the lease on one test client. Rollback is complete only when gateway, DNS, a central destination, the internet path, and the rule ID match the baseline again. Manual/Split also requires restoring the original physical cabling.

The practical setup workflow, including provisioning, LEDs, rules, performance, and troubleshooting, is described in Set up and troubleshoot Sophos SD-RED. The operation mode additionally requires acceptance of the actual traffic path:

1. A client receives the expected IP address, DNS servers, and correct gateway.
2. A defined destination network at the central site is reachable.
3. Log Viewer or Packet Capture shows the expected Firewall Rule ID and RED path.
4. An internet test shows the expected public exit, central or local.
5. One allowed and one blocked application confirm where the security policy actually applies.
6. VLANs and wireless networks are tested individually rather than with only a general ping.
7. A planned tunnel or uplink failure confirms the documented failure behavior.

If the tunnel is green but the traffic path remains unclear, Use Packet Capture correctly on Sophos Firewall helps. On production sites, do not change the operation mode, DHCP, VLANs, and firewall rules simultaneously. Otherwise, a fault can hardly be assigned to one layer.

Troubleshoot by traffic path

• The RED repeatedly restarts or does not establish a tunnel: Check WAN DHCP, DNS, and internet access at the RED site first. Then verify TCP 3400, UDP 3410, and time synchronization over NTP 123. With manual offline deployment, an incorrect clock can prevent the TLS handshake.
• The tunnel is green, but no traffic passes: Look for the expected Firewall Rule ID in Log Viewer, then check routes and NAT rules for the exact source/destination pair. In Advanced Shell, the Sophos-documented read-only capture tcpdump -ni any port 3410 shows whether RED traffic reaches the firewall endpoint. It does not prove that a rule allows the traffic or that the payload follows the correct path; follow it with a Packet Capture filtered by client and destination.
• Only split destinations fail: Confirm that the complete destination network is present in Split network. FQDN hosts are unsupported there. In Transparent/Split, test the local DNS or split-DNS path separately.
• Only VLAN traffic fails: Check the mode first. SD-RED 60 supports VLAN transport through the RED tunnel only in Standard/Unified. Then compare the VLAN ID, VLAN interface on the RED interface, LAN port mode, switch tagging, DHCP, and VLAN-specific firewall rule.
• An HA failover has occurred: Do not expect an immediate green status. SFOS documents a reconnection delay that varies with the number of interfaces and other settings. Wait for the tunnel to re-establish and repeat the complete path test rather than changing RED settings at the same time.

Common misconceptions

Split does not automatically mean internet during a tunnel outage

Standard/Split uses local internet breakout, but clients still depend on the RED network provided by the firewall. Sophos documents the loss of internet access there as well if the tunnel fails. Manual/Split is the separate design for an existing local gateway.

Transparent does not mean arbitrary Layer 2 passthrough

Transparent/Split integrates the RED into an existing network but does not transport VLAN-tagged frames through this path. DHCP, DNS, and wireless options must still be planned deliberately.

A green tunnel does not prove the correct operation mode

Tunnel status confirms the connection to the firewall. Only DHCP, routing, internet, rule, and failure tests show whether the selected operation mode matches the intended design.