Redundant connections for Sophos RED tunnels between XG(S) firewalls
On Sophos RED endpoints, a primary and secondary IP address or hostname can be defined as peer. However, if a RED tunnel is set up between two Sophos XG(S) firewalls, only one IP address or host name can be defined on the client side. This means that redundancies in the WAN interfaces on the server side cannot be used. Multiple redundancies with weighting are possible using a surprisingly simple trick.
DNS, always DNS
The trick makes use of the fact that the RED tunnel resolves the configured host name via the firewall-internal DNS service. Instead of the actual remote peer, therefore, an internal host name (here in the example “hifish.red”) is used.
In the DNS section, you enter the host name and then store the IP addresses with the corresponding weighting.
Restrictions and final considerations
Although redundancies can be formed very well in this way, the failback to the IP address with the lowest weighting does not work automatically. The client is therefore stuck to the IP with which the last communication with the server firewall took place. A workaround here is to temporarily deactivate the RED interface on the client firewall. When the connection is re-established, the IP with the lowest weight is chosen.
Another limitation is that the DNS server in the Sophos Firewall currently only supports A records. Therefore, only WAN interfaces with fixed publix IPs can be connected in this way. For remote stations with dynamic IPs, DynDNS services can be used if required. In environments with several RED tunnels, the use of a central, public DNS service can be easier to manage.
During tests, I also noticed that only the main IP address of a WAN interface can be used for RED uplinks. If you define several alias IPs on a WAN interface (e.g. with several fixed public IPs), these cannot be used for RED connections.
