When inter VLAN routing not working troubleshooting begins, avoid changing several devices at once. Communication between VLANs depends on multiple layers: endpoint membership, switch tagging, gateway interfaces, security policy, and return routing. A disciplined sequence helps you identify the failed layer before making a repair.
This guide assumes that devices in separate VLANs should communicate through a router, firewall, Layer 3 switch, or another routing appliance. The exact commands differ by vendor. Use read-only checks first, record current values, and confirm maintenance access before changing a live network. That approach keeps inter VLAN routing not working troubleshooting focused on evidence rather than guesswork.
Define the failure before testing
Start with two endpoints and write down their locations, VLAN IDs, IP addresses, subnet masks, and default gateways. Include one working comparison if possible. A working device in the same source VLAN can reveal whether the problem affects one endpoint or the whole segment.
Test one destination at a time. For example, check whether a workstation in VLAN 20 can reach a server in VLAN 30. Then test the destination gateway from the source device. Finally, test a known service rather than relying only on ping. Firewalls may block Internet Control Message Protocol (ICMP), while allowing application traffic.
- Does the source device have the expected IP address and mask?
- Does it use the correct default gateway?
- Can it reach its own gateway?
- Can another device in the same VLAN reach that gateway?
- Does the failure affect all traffic or one application?
Capture timestamps, source and destination addresses, test results, and relevant logs. This evidence keeps the investigation focused. Google’s structured troubleshooting guidance also emphasizes evidence, hypotheses, and controlled tests.
Confirm VLAN membership at the edge
First, verify the source and destination switch ports. An access port normally carries one untagged VLAN for an endpoint. A trunk carries multiple VLANs and uses tags to identify them. Confusing these roles can place a device in the wrong broadcast domain.
Check the configured VLAN and the operational state. A port may show the right setting while the switch suspends the VLAN, omits it, or marks it inactive. Confirm the VLAN exists locally and appears in the forwarding table where required.
Check the endpoint’s actual network identity
Do not assume a device received the intended network settings. Inspect its address, mask, gateway, and lease details. A stale lease, manual address, or incorrect mask can make a healthy routing design appear broken.
For DHCP networks, compare the client’s address with the expected scope. You can also review the related DHCP reservation diagnostic order when a device repeatedly receives an unexpected address.
Next, compare the port’s VLAN with the endpoint’s intended role. A phone, access point, server, and workstation may use different access or voice VLAN behavior. Check the vendor configuration and documentation before changing a port that may support more than one service.
Inspect trunks and VLAN tagging
If the source or destination VLAN crosses a switch link, inspect every trunk along the path. Confirm that the required VLAN is allowed on each trunk. A VLAN can exist on both switches yet fail to cross the link because the allowed list excludes it.
Tagging must also match at both ends. One side may send frames tagged while the other expects untagged traffic. Native VLAN settings can create especially confusing symptoms because some traffic appears to work while another VLAN fails.
- Confirm both links operate as the intended trunk or access mode.
- Compare allowed VLAN lists on both ends.
- Check native or untagged VLAN settings carefully.
- Review trunk counters for errors, drops, or unexpected state changes.
- Confirm the VLAN is permitted across intermediate switches.
Use a topology diagram and trace the full Layer 2 path. A single omitted VLAN on an intermediate trunk can produce a failure that looks like a router problem. If a switch port itself appears abnormal, consult this safe switch-port troubleshooting sequence before replacing hardware or changing unrelated settings.
Verify gateway interfaces and routes
Inter-VLAN traffic needs a Layer 3 gateway for each subnet. On a Layer 3 switch, these gateways are often switched virtual interfaces, or SVIs. On a router, they may use physical interfaces or tagged subinterfaces. A firewall may use VLAN interfaces attached to a trunk.
Confirm that each gateway interface exists, has the correct address and mask, and operates normally. The gateway address must belong to the corresponding subnet. Also check whether an administrator disabled the interface or the parent interface lacks the required configuration.
Review the routing table next. The router should have connected routes for the VLAN subnets. If the destination network does not appear as connected or otherwise reachable, the device may lack the required gateway configuration or may place it in the wrong routing context.
Separate local gateway failure from routed failure
From the source endpoint, test its own gateway. If that fails, return to VLAN membership, tagging, addressing, and local switching. If the source gateway responds, test the destination gateway. A failure there narrows the search toward the destination VLAN path or the Layer 3 device.
When both gateways respond but the host does not, inspect host firewalls, local isolation, and service bindings. A router can forward packets correctly while the destination operating system rejects them. The related guide on devices reaching a gateway but not one another covers that distinction in more detail.
Check ACLs and firewall policy
After confirming switching and gateways, inspect access control lists (ACLs). An ACL is a rule set that permits or denies traffic based on addresses, protocols, ports, interfaces, zones, or direction. A rule may block only one VLAN pair or one application.
Check policy in both directions. Some firewalls create stateful return rules automatically, while routers using stateless ACLs may require explicit permission for replies. Review rule order, address objects, service definitions, and logging. A broad deny rule below a narrower rule may not matter if an earlier rule already matches.
- Identify the ingress interface and egress interface.
- Check the source and destination address objects.
- Confirm the protocol and destination port.
- Review denies and hit counters during a controlled test.
- Check zone policy, security profiles, and host isolation settings.
Do not disable the firewall as a first test. A temporary, narrowly scoped permit can be safer, but it still needs an owner, expiration time, logging, and rollback notes. Preserve the original policy before testing.
Trace return paths and asymmetric routing
Successful forwarding in one direction does not prove that replies can return. The destination host may use the wrong gateway, a different router, or a more specific route. This creates asymmetric routing: packets take different paths in each direction.
Inspect the destination’s address, mask, and gateway. Then review routes on routers, firewalls, VPN devices, and Layer 3 switches. Look for overlapping subnets, policy-based routing, and static routes that point to an unavailable next hop.
Packet captures can show where the flow stops. Capture near the source gateway and destination interface when practical. If the request leaves but no reply returns, investigate the destination host, its gateway, and return policy. If the reply leaves but never reaches the source, inspect the reverse route and filtering.
A route table can contain a technically valid path that still conflicts with the intended design. The guide on wrong network routes explains how to compare route preference, overlapping networks, and policy behavior without guessing.
Apply the smallest verified correction
Once evidence identifies the failed layer, change only that layer. Correct one access VLAN, restore one allowed trunk VLAN, enable one gateway interface, or adjust one narrowly defined policy. Avoid combining a switch change, firewall change, and endpoint reset in one step.
Before applying a change, record the old value and define a rollback. Confirm who approved the change and whether a maintenance window is needed. For remote work, keep an alternate management path. A trunk mistake can disconnect the very device being used to repair the network.
After the change, repeat the original tests. Check both directions, the intended application, and an unaffected VLAN pair. Review logs and counters for unexpected side effects. Finally, document the cause, evidence, correction, and follow-up action.
When to involve remote network support
Inter VLAN routing not working troubleshooting becomes risky when the design spans several switches, firewalls, or routing domains. Professional help is appropriate when you lack current diagrams, cannot maintain management access, or need packet captures and coordinated changes. Tech Rescue Ops LLC can help organize evidence, review the path, and apply a controlled correction without unnecessary configuration changes.
For a repeatable investigation, keep this inter VLAN routing not working troubleshooting sequence with the network diagram and change records. That makes future checks faster and reduces the chance of unrelated configuration changes.