I’ll walk through how I configure Peer Administration on a Sophos XGS HA cluster so you can avoid the usual gotchas. This guide uses a practical, example-led approach. I cover network assessment, peer admin addresses, DHCP configuration, firewall rules and a few checks to prove the setup works. I use short, specific steps and real IP examples so you can map this to your own Sophos XGS HA Cluster.
Start by assessing the network. Map the interfaces and decide which will carry client traffic, which will be the HA heartbeat and which will be management. I prefer a dedicated HA link. Use a small subnet for heartbeat, for example 172.16.100.0/30 between the primary and auxiliary. Keep the management or Peer Administration IPs out of the client DHCP pool, ideally on a management VLAN or separate physical port. If you must place an admin IP on the same LAN as clients, document it clearly and reserve the address in DHCP. For a concrete example, if your primary LAN IP is 10.60.7.1/24, give the auxiliary an admin IP like 10.60.7.2 but do not use that auxiliary admin IP as the clients’ gateway.
Set the Peer Administration values in the Sophos GUI after you have the network plan. Give the auxiliary its administrator IP on the chosen interface and set the primary’s admin IP where the primary listens. I recommend these practical rules: use a separate IP for management, give the HA heartbeat its own link or VLAN, and bind the cluster virtual IP where you want client traffic to appear. In active-passive mode the cluster virtual IP is the gateway for client DHCP leases. That means DHCP Configuration for port 1 should hand out the cluster virtual IP as the gateway, not the auxiliary admin IP. The auxiliary admin IP is for management and failover signalling, not for normal client traffic.
Assign addresses and configure DHCP with care. If the cluster uses a virtual IP for the LAN, put that virtual IP into the DHCP scope as the default gateway. Avoid giving DHCP leases a physical appliance IP. If you run the Sophos DHCP server on the firewall, set the gateway to the cluster virtual IP. If an external DHCP server handles leases, create a DHCP reservation or static route so the virtual IP remains reachable during failover. Test this by forcing a failover and confirming clients keep their gateway and traffic continues without changes.
Document interfaces and firewall rules. Write down which physical ports map to which VLANs, the admin IPs, the heartbeat subnet, and the cluster virtual IPs. For firewall rules, make rules against the virtual IPs or zone objects rather than a device’s physical admin IP. That keeps policy consistent when the active unit switches. Open only the management services you need to the admin IPs. Restrict access to the admin IPs with management ACLs and keep logging on for HA events.
For ongoing maintenance I follow a short checklist. Check HA synchronisation after any change. Match firmware and hotfix levels on both units before you pair them. Run a scheduled failover test quarterly, confirm routing and DHCP behaviour after the test, and keep an up-to-date network diagram and DHCP scope list. Common issues are mismatched interfaces, forgotten DHCP gateway settings, and using the auxiliary admin IP as the client gateway. When something fails, verify the heartbeat link first, then the admin IPs, then the virtual IP bindings.
Practical takeaways: use a dedicated heartbeat, keep admin IPs separate from client gateways, hand out the cluster virtual IP in DHCP, write firewall rules against virtual IPs or zones, and test failover regularly. Follow those steps and your Sophos XGS HA Cluster will behave predictably under failover and during maintenance.
