Building a Dedicated Management Network with Sophos XG

Separating infrastructure administration from ordinary client and IoT traffic.

A management network should contain management planes, not simply every device that feels important. That distinction became central while placing Sophos XG, managed switches, access points, Proxmox, Xen hosts, and storage systems.

What belongs in management?

Typical candidates are:

  • the Sophos WebAdmin and CLI access path;
  • switch management addresses;
  • access-point management interfaces;
  • hypervisor management interfaces;
  • out-of-band controllers where available;
  • selected NAS administration interfaces;
  • monitoring systems that query infrastructure.

Application workloads running on a hypervisor do not automatically belong there. The Proxmox host can be managed through one network while its VMs and containers attach to service, office, IoT, or playground VLANs.

A physical interface or a management VLAN?

Both approaches are useful but solve different problems.

A management VLAN provides scalable connectivity across managed switches. It can reach many infrastructure devices without dedicated cabling.

A dedicated physical firewall interface provides a recovery path when the trunk or switch configuration is broken. It is especially valuable while building the network.

My design combined the ideas:

  • reserve one Sophos port for direct or tightly scoped administration;
  • use a separate port as the production VLAN trunk;
  • place the normal management addresses of infrastructure in a dedicated management network;
  • retain console or direct-cable options for recovery.

The direct interface is not magically secure. It still needs a sensible subnet, physical control, and restricted device access.

Management access uses two policy layers

This is easy to misunderstand on Sophos Firewall.

  1. Firewall rules govern traffic forwarded through the firewall—for example, an administration workstation connecting to a switch in another VLAN.
  2. Device access and local service ACL settings govern services hosted by the firewall itself, including WebAdmin and SSH.

A broad inter-VLAN allow rule does not necessarily grant WebAdmin access. Conversely, enabling administrative services for an entire zone may expose the firewall more widely than intended.

Use an administration source

The strongest simple model is to identify one or a few administration sources:

  • a dedicated administrator workstation;
  • a hardened jump host;
  • a VPN address pool reserved for administrators;
  • an emergency laptop connected directly when needed.

Then allow only the required management protocols from those sources to named infrastructure destinations. Example flows include HTTPS to WebAdmin, SSH to switches, and the management ports used by Proxmox.

Avoid granting the complete Office subnet access to every management interface just because administrators use office computers.

Keep infrastructure usable

Isolation must not break dependencies. Infrastructure may need:

  • DNS and NTP;
  • firmware-update access;
  • authentication services;
  • monitoring and logging destinations;
  • backup storage;
  • controller-to-access-point communication.

Each dependency should become an explicit outbound or inbound rule. Logging those rules during rollout helps reveal undocumented requirements.

Protect against self-lockout

Before restricting WebAdmin access:

  1. Verify the dedicated management path works.
  2. Confirm the administrator client has the expected address.
  3. Confirm HTTPS is enabled for the intended source zone or local service ACL exception.
  4. Keep a direct console option available.
  5. Change one control at a time.
  6. Test from both an allowed and a disallowed network.

Do not remove the last known-good path while connected through it.

Management network is not a server network

It is tempting to put DNS, MQTT, HomeMatic, and general application servers beside hypervisor and switch management interfaces. That makes firewalling simpler but expands the impact of a compromised service.

A clearer distinction is:

  • management plane: interfaces used to administer infrastructure;
  • service plane: DNS, MQTT, automation, databases, web services;
  • workload networks: networks where VMs and containers participate according to their function.

The hypervisor host can therefore be in management while a virtual MQTT broker is in core services and a test VM is in the playground VLAN.

Resulting policy

The management network follows a default-deny mindset:

  • no initiation from IoT, media, or home automation;
  • selected administration sources may reach selected management services;
  • infrastructure may reach only documented foundational services;
  • monitoring and backup flows are explicit;
  • WebAdmin and SSH on Sophos are limited through device-access controls;
  • internet access is allowed only where operationally justified.

This is stricter than most home networks, but the rule set remains small because the purpose of the network is narrow.

References