Planning VLANs and IP Subnets for a Sophos XG Homelab

Once the trust boundaries were clear, I needed an address plan. This sounds mechanical, but mistakes here cause some of the most confusing symptoms in a segmented network.

A VLAN and a subnet are related, but not identical

A VLAN is a Layer-2 broadcast domain. An IP subnet is a Layer-3 address range. In a conventional homelab design, one VLAN normally maps to one subnet because this keeps gateway, DHCP, and firewall configuration understandable.

For example:

These values are examples, not a universal standard. The useful convention is that the third octet mirrors the VLAN ID. It reduces mental translation while troubleshooting.

Avoid overlapping networks

One early idea used a large 10.0.0.0/16 network together with smaller networks such as 10.0.10.0/24. That does not create separate address spaces. The /16 already contains every address from 10.0.0.0 through 10.0.255.255, including the complete /24.

In other words:

• 10.0.0.0/16 contains 10.0.10.0/24;
• a host configured for the /16 may treat 10.0.10.x as local;
• it may ARP for the destination instead of sending traffic to its gateway;
• routing and firewall behavior then appears inconsistent.

The fix is to use disjoint networks. If the segmented networks are /24, the old untagged network must also be a non-overlapping /24, or it must be retired during migration.

Calculate before configuring

For a /24:

• network address: 10.0.20.0;
• usable host range: 10.0.20.1 to 10.0.20.254;
• broadcast address: 10.0.20.255;
• netmask: 255.255.255.0.

I reserve a predictable address for the Sophos interface, usually .1, and divide the remaining range conceptually:

• low addresses for gateways and infrastructure;
• a static or reserved range for servers;
• a DHCP pool for clients;
• unused space for growth.

The exact split matters less than documenting it.

Do not overload VLAN 1

VLAN 1 is often the switch default and may carry untagged traffic unless changed. It can be used deliberately, but relying on it implicitly makes trunks harder to understand. The design should state:

• whether the trunk has untagged/native traffic at all;
• which VLAN receives untagged traffic;
• whether VLAN 1 is an actual production network or only a temporary migration mechanism;
• which switch ports are access ports and which are trunks.

The same VLAN must be represented consistently on Sophos XG, the switch, and any VLAN-aware access point or hypervisor.

Plan DHCP and DNS together

Each client VLAN needs an address-assignment strategy. Sophos Firewall can run a DHCP server on VLAN interfaces, or another DHCP server can be used with relay where appropriate. A typical scope supplies:

• an address from the correct subnet;
• the Sophos VLAN-interface address as default gateway;
• the intended DNS resolver;
• optional NTP or vendor-specific options.

DNS design also affects firewall rules. If every network uses a central internal resolver, clients need access to it, while direct DNS to the internet can be blocked if that matches the policy.

Keep an address-plan table

My working documentation gained columns for:

This table is more valuable than a beautiful diagram that omits operational details.

Migration strategy

I did not want to move every device at once. A safer sequence is:

1. Create a new, non-overlapping subnet.
2. Add its VLAN interface and DHCP scope.
3. Configure the VLAN on the trunk.
4. Move one test port or SSID.
5. Verify gateway, DNS, internet, and permitted internal flows.
6. Move the remaining devices in that class.
7. Remove transitional rules after validation.

With a non-overlapping address plan, routing behavior becomes predictable. The next task is to create the VLAN interfaces that make Sophos XG the gateway for those networks.

References

• Add a VLAN interface — Sophos Firewall 19.0
• DHCP — Sophos Firewall 19.0