Sophos RED is a remote-site role rather than a VPN protocol, which is why comparing it with IPsec or OpenVPN answers the wrong question. The device extends a central firewall's control to a branch, and the mode you pick decides who supplies the branch gateway, who hands out addresses, and which traffic crosses the tunnel. Those three answers matter more than the mode names do. Writing them down first turns a product choice into a design decision.

RED Is a Role, Not a Protocol

A RED device joins a branch to a central Sophos Firewall, and the firewall's configuration defines what the branch becomes. The tunnel is an implementation detail of that join rather than a general-purpose VPN endpoint you can aim at any peer.

That framing matters because a RED is not interchangeable with an arbitrary IPsec peer. It expects the central firewall to manage it, and the supported modes describe how much of the branch it takes over. Treating it as a plain tunnel endpoint creates expectations the product never promised. Treating it as a role produces the questions that actually decide the design.

The three conditions below change the answer, and all of them are about ownership rather than encryption.

Three Conditions That Pick the Mode

Ask who owns the branch gateway, who runs DHCP and DNS for branch clients, and whether local internet breakout must survive a tunnel outage.

Standard/Unified answers all three the same way: the central firewall owns the branch LAN, including gateway and DHCP duties, and traffic crosses the tunnel. Standard/Split keeps central management and sends only the configured networks through the tunnel. Transparent/Split leaves the existing branch network in charge of its own gateway and addresses, and redirects only selected traffic into the tunnel. Three modes, three different owners.

ModeBranch gateway and DHCPTraffic through the tunnel
Standard/UnifiedCentral firewall owns bothAll branch traffic
Standard/SplitCentral firewall owns bothOnly the configured networks
Transparent/SplitThe existing branch router keeps bothOnly the selected flows

Read the middle column first, because it decides how much of the branch still works when the tunnel is gone.

Who Owns the Branch Gateway and DHCP

In the unified arrangement the branch has no independent gateway to speak of, which simplifies configuration and concentrates the failure. That concentration is fine when the branch is small and the central firewall is highly available.

In a transparent deployment the branch keeps its router and the RED sits inline to redirect selected traffic. That preserves local control and adds a device whose position in the path now matters for every redirected flow. Document where it sits, because a later change to the branch router can silently bypass it. Neither arrangement wins in general; they distribute responsibility differently.

Address ownership is the part to write down, since two DHCP servers on one segment produce intermittent faults that get reported as VPN trouble.

What Happens When the Tunnel Drops

Split operation is often read as a promise that local internet keeps working during a tunnel failure, and that reading is not safe. The exact behaviour depends on the selected mode, the firmware and the device, so it belongs in the acceptance criteria rather than in an assumption.

Decide what the branch must still do with no tunnel: reach local printers, resolve names, take payments, or nothing at all. Then test that state deliberately by blocking the tunnel and observing the branch. A branch that quietly loses DNS is worse than one that fails loudly, because the helpdesk call arrives hours later. Write the observed result into the design record.

The central dependency is the same in every mode: somebody has to own the recovery path for the device itself.

Write the Branch Contract Before You Deploy

A branch contract fits on one page: owners, address sources, tunneled prefixes, breakout policy and the outage behaviour you accepted.

Then verify the deployed result rather than the intended one. Check the branch client's address, its default gateway, which prefixes resolve through the tunnel, and what still answers when the tunnel is blocked. Compatibility, reachability and licensing all need checking against current vendor documentation for the exact model, since a product name does not guarantee a mode. Keep that page with the device record so the next engineer inherits the decisions instead of the diagram.

ip -br addr
ip route
traceroute -n 10.80.4.10
dig +short intranet.corp.example

Repeat that block with the tunnel blocked, and the difference between the two runs is the outage behaviour you actually bought.

Barruulee wal qabatan