Configuring VLAN Interfaces on Sophos XG

How Sophos VLAN interfaces become gateways for segmented homelab networks.

The address plan becomes real when Sophos XG receives one logical interface per VLAN. These interfaces terminate the tagged networks, provide their gateway addresses, and give firewall rules a place to classify traffic.

What a Sophos VLAN interface represents

A VLAN interface is attached to a parent interface. If Port6 is connected to the switch as a trunk, logical interfaces such as Port6.10, Port6.20, and Port6.30 can carry the corresponding tagged traffic.

Each VLAN interface needs at least:

  • a descriptive name;
  • the parent interface;
  • a VLAN ID;
  • a zone;
  • an IP address and prefix.

For an example Office network, the values might be:

Name: Office
Parent interface: Port6
VLAN ID: 20
Zone: LAN (or an appropriate custom zone)
IPv4 address: 10.0.20.1/24

The address 10.0.20.1 is then the default gateway for hosts in 10.0.20.0/24.

Parent-interface design

The parent port and the switch port must agree about tagging. My intended structure was:

  • one firewall port used as the VLAN parent;
  • one switch trunk carrying all intended VLAN IDs;
  • no accidental mixing of an unrelated untagged subnet on that link;
  • a separate firewall port retained for administration.

During planning, different physical port numbers were considered. That detail changed; the architectural decision did not. A configuration should document the actual cabling rather than treating an early port-number sketch as permanent.

Zones are policy groups

Sophos zones group interfaces and participate in rule matching. Putting several VLANs in the LAN zone does not automatically mean they should communicate freely. It does mean that a same-zone rule may be required and that an overly broad LAN-to-LAN rule could undermine segmentation.

Two reasonable strategies are:

  1. Use a small number of zones and make network objects and rules very explicit.
  2. Create custom zones for materially different trust levels.

The second can make the intent clearer, but too many zones create administrative overhead. I prefer zones that represent security posture and network objects that represent the individual subnets.

Add network objects

Firewall rules are easier to read when they refer to named objects instead of raw CIDR ranges. For example:

NET_Office        10.0.20.0/24
NET_IoT           10.0.30.0/24
NET_HomeAuto      10.0.40.0/24
HOST_MqttBroker   10.0.10.25

Consistent prefixes make object selection less error-prone and make exported configurations easier to review.

Add DHCP deliberately

If Sophos supplies addresses, create a DHCP server for the VLAN interface and verify:

  • the pool belongs to the interface subnet;
  • the gateway points to the interface address;
  • static infrastructure addresses are outside the pool or reserved;
  • DNS points to the intended resolver;
  • lease duration fits the device class.

Do not interpret a DHCP lease as proof that routing works. DHCP proves that the client reached an appropriate server or relay. Gateway, DNS, firewall, and NAT still need separate tests.

Configure one VLAN at a time

For each new network I use the same small validation loop:

  1. Create the VLAN interface.
  2. Create or verify its network object.
  3. Add DHCP if required.
  4. Allow the VLAN on the switch trunk.
  5. Configure one switch access port for the VLAN.
  6. Connect one test client.
  7. Check its address, prefix, gateway, and DNS settings.
  8. Ping or connect to the Sophos gateway.
  9. Test DNS and internet access.
  10. Test only the intended cross-VLAN services.

This sequence limits the number of variables. Creating six VLANs, multiple SSIDs, many switch ports, and all firewall rules before the first test makes diagnosis unnecessarily difficult.

Do not confuse routing with permission

When Sophos owns two directly connected VLAN interfaces, it knows routes to both networks. That does not mean traffic is automatically permitted. The route answers “where”; the firewall rule answers “whether.”

Likewise, NAT is normally not required between internal VLANs. Source NAT can hide the real client address and complicate logging. Internal flows should usually be routed and explicitly permitted, while outbound internet traffic uses the appropriate masquerading or SNAT configuration.

Validate the result on both sides

If the VLAN interface is correct but the switch does not carry its tag, no client will reach it. If the switch is correct but the Sophos VLAN ID or parent interface is wrong, the symptom is similar. Always compare these three facts side by side:

Sophos XGSwitchClient edge
Parent port and VLAN IDTrunk port and allowed VLANAccess VLAN or tagged interface
Gateway address/prefixNo conflicting routed interfaceMatching client subnet
Zone and rulesTagged/untagged behaviorCorrect default gateway

Once the VLAN interfaces exist, the next challenge is transporting them reliably over the switch trunk.

References