Understanding Inter-VLAN Routing and Firewall Rules on Sophos XG

After creating VLAN interfaces, Sophos XG knows where the directly connected networks are. That does not mean hosts may communicate between them. Routing and firewall policy answer different questions.

Route first, authorize second

Suppose Sophos has these interfaces:

Office:          10.0.20.1/24
IoT:             10.0.30.1/24
Home automation: 10.0.40.1/24

The connected routing table tells Sophos that 10.0.30.0/24 is reachable through the IoT interface. When an Office client sends a packet to an IoT host, Sophos can determine the outgoing interface. The firewall policy then decides whether to allow the session.

No additional router is required for these directly connected VLANs. No static route is required either. Static routes are for networks behind another next hop.

Same-zone traffic still needs thought

Several VLAN interfaces may share the LAN zone. The source and destination zones of an inter-VLAN flow can therefore both be LAN. A LAN-to-LAN rule may be necessary, but it should still name the source networks, destination networks, and services.

This is too broad:

Source zone: LAN
Source: Any
Destination zone: LAN
Destination: Any
Services: Any
Action: Accept

It allows routing while removing most of the security value of segmentation.

A clearer rule is:

Name: Office_to_NAS_SMB
Source: NET_Office
Destination: HOST_NAS
Services: SMB
Action: Accept
Log: Enabled during rollout

Build rules from flows

I describe each permission using five fields:

This avoids vague statements such as “Office needs access to Infrastructure.” Usually only one host needs two services on one destination.

Rule order matters

Sophos evaluates rules according to its rule-processing order. Specific rules should be placed so they match before broader rules that would produce a different action. Give rules names that explain direction and purpose, group related rules, and remove temporary diagnostic permits after testing.

Enable logging where it helps answer questions, but avoid turning every high-volume permitted flow into noise forever. Logs are most valuable when rule names and network objects already communicate intent.

Return traffic is stateful

For a normal stateful TCP connection, permitting the initiating flow allows the response packets belonging to that session. You do not create a mirrored reverse rule merely for replies.

The distinction matters when documenting direction:

• Office may initiate HTTPS to a server.
• The server may reply within that connection.
• The server may not necessarily initiate a new connection to Office.

Internal NAT is usually unnecessary

Do not add masquerading between internal VLANs merely to make routing work. It hides original client addresses and can complicate server logs and access control. Use routed internal traffic unless a specific legacy constraint requires translation.

Internet-bound traffic is different. It commonly uses masquerading or SNAT toward the WAN. Diagnose the internal route and the WAN NAT path separately.

Essential shared services

Even strongly isolated networks often need a short list of shared services:

• DNS;
• NTP;
• DHCP, locally or by relay;
• MQTT or another message broker;
• controller services;
• logging and monitoring;
• selected NAS shares.

Create service-specific rules instead of one “shared services” rule with Any as the service. Named host objects also prevent a whole server subnet from becoming reachable when only one server is needed.

Test policy, not only connectivity

For every VLAN, verify positive and negative cases:

• an allowed DNS query succeeds;
• an allowed application connection succeeds;
• a prohibited management connection fails;
• a prohibited cross-VLAN ping or TCP test fails, if ICMP is not intentionally allowed;
• the firewall log shows the expected matching rule or drop.

A successful internet test proves little about internal segmentation. A good acceptance test confirms both what works and what remains blocked.

References

• Configure inter-VLAN routing — Sophos Firewall
• Firewall rules — Sophos Firewall