Marko Apfel
Network

Sophos XG Homelab: The Resulting Architecture and Lessons Learned

The final design principles, migration approach, and lessons from building a segmented Sophos XG homelab.

4 min read

The project began as a plan to separate computers, media devices, smart-home equipment, and servers. It ended with a reusable network architecture and, more importantly, a method for changing that architecture without losing control of it.

The resulting model

The stable design principles were:

  1. Sophos XG is the default gateway for the segmented subnets.
  2. VLAN interfaces on one parent port terminate tagged networks.
  3. A managed switch transports those VLANs over an 802.1Q trunk.
  4. Switch access ports place ordinary devices into one VLAN without requiring device-side tagging.
  5. A separate Sophos interface provides a restricted administration and recovery path.
  6. Firewall rules control traffic between trust boundaries.
  7. Device-access settings separately protect services hosted by Sophos itself.
  8. Proxmox and other virtualization hosts use a management network, while workloads join networks according to their function.

The exact VLAN IDs, port numbers, and subnets evolved during implementation. That was not a design failure. It was a reminder to distinguish architectural decisions from replaceable configuration values.

Networks represent purposes

The logical model included management, infrastructure or core services, trusted clients, IoT, home automation, media, and a playground for experiments. Each network had a narrow description and a default policy.

This proved more useful than grouping devices only by location. A virtual server and a physical appliance may belong to the same trust domain even though they connect through different switch ports. Conversely, two devices in the same room may deserve different policies.

The firewall is the policy boundary

Using Sophos for inter-VLAN routing keeps policy and visibility in one place. The switch forwards frames inside each VLAN and transports tags; Sophos decides whether routed sessions cross from one network to another.

This only provides meaningful segmentation if rules remain specific. A broad allow-any rule between internal zones produces connected networks, but not strong boundaries.

What worked well

A dedicated management path

Keeping administration separate from the trunk reduced the risk of self-lockout and made experimentation less stressful.

One VLAN at a time

Adding one interface, one trunk membership, one access port, and one test client created a known-good template.

Non-overlapping /24 networks

The simple convention made routing behavior and troubleshooting clearer. It also avoided the subtle mistake of placing smaller networks inside a broad /16 already used by clients.

Named objects and purpose-driven rules

Rules such as HomeAuto_to_MQTT explain more than generic LAN-to-LAN permissions. Stable destination objects also make address changes manageable.

Positive and negative tests

Confirming that an allowed service works is only half the test. Confirming that IoT cannot reach management proves the boundary exists.

What caused confusion

Treating VLAN IDs as the architecture

Debating whether a network should be VLAN 10 or VLAN 50 matters less than defining its trust level and required flows. IDs can be changed; undocumented dependencies remain dangerous.

Mixing native and tagged assumptions

VLAN 1 and untagged traffic created ambiguity. Both ends of every trunk must explicitly agree.

Confusing routes, rules, and local services

Three separate questions must be answered:

  • Does Sophos know where the destination network is?
  • Does a firewall rule permit forwarded traffic?
  • Does the local service ACL permit access to Sophos itself?

Changing the wrong layer wastes time and can weaken security.

Moving too many parts simultaneously

Changing addressing, DHCP, trunk membership, access ports, and rules at once makes every symptom ambiguous. Small migration steps are not bureaucracy; they are a diagnostic tool.

Operational checklist

The finished network needs maintenance. I keep these items in the operating routine:

  • export the Sophos configuration before structural changes;
  • back up managed-switch configurations;
  • maintain a VLAN, subnet, gateway, DHCP, and port table;
  • label important cables at both ends;
  • review temporary rules and remove them;
  • review device-access settings after zone changes;
  • keep infrastructure addresses and DNS records stable;
  • test the emergency management path periodically;
  • retain logs long enough to diagnose intermittent failures;
  • document why each cross-VLAN rule exists.

A compact acceptance test

For every network:

  1. A client receives the expected address, prefix, gateway, and DNS server.
  2. The client reaches its Sophos gateway.
  3. DNS and NTP work through the intended services.
  4. Internet access matches policy.
  5. Required internal application flows work.
  6. Prohibited management and cross-network flows fail.
  7. Logs identify the rule responsible for important decisions.

Final perspective

The biggest improvement was not the number of VLANs. It was moving from implicit trust to explicit communication.

Sophos XG, a managed switch, and VLAN-aware access points provide the technical mechanisms. The quality of the result comes from the questions asked before configuration: What is this device? What must it initiate? Which service should answer? What should remain impossible?

Those questions keep the homelab understandable as it grows—and they make the design transferable to new switches, access points, servers, and firewall versions.

References