Devices on different VLANs often fail to connect via SSH until a ping is sent because stateful firewalls block unsolicited inbound TCP traffic while allowing outbound ICMP requests. This behavior indicates that the routing infrastructure is correct, but security policies are enforcing strict connection tracking rules that require an existing session or explicit permit for new connections.
The Role of Stateful Firewalls
The core issue lies in how modern network devices handle packet inspection. Unlike simple layer three switches that forward packets based solely on IP addresses and subnets, most enterprise routers and next-generation firewalls operate as stateful devices. These devices maintain a connection table that tracks the state of active sessions. When you attempt an SSH connection from VLAN A to VLAN B, the firewall sees an incoming TCP SYN packet on port 22. If there is no existing entry in the connection table for this flow, the firewall drops the packet by default unless a specific rule permits it. However, when you initiate a ping from the source device, the firewall logs this as an outbound ICMP Echo Request. Some firewall configurations treat ICMP differently than TCP. In many default setups, outbound ICMP is permitted to allow basic connectivity diagnostics. Crucially, some older or misconfigured stateful firewalls may associate the established ICMP flow with the source IP address, inadvertently relaxing restrictions for subsequent traffic from that same source, or more commonly, the act of pinging forces the creation of a temporary state entry that the administrator mistakenly believes allows TCP. It is vital to understand that ICMP does not technically "open" TCP ports. The real solution involves configuring explicit access control lists (ACLs) rather than relying on side effects of ICMP traffic. For a deeper dive into why your SSH might be blocked independently of VLAN issues, review our guide on Troubleshooting SSH Connection Issues.Verifying Routing Between VLANs
Before adjusting firewall rules, you must ensure that Layer 3 routing is correctly configured. Each VLAN requires a distinct subnet and a corresponding interface or sub-interface on the router or switch acting as the default gateway. Use the commandshow ip route on Cisco IOS devices or display ip routing-table on Huawei equipment to verify that the destination VLAN’s subnet appears in the routing table. If the route is missing, the router does not know where to send the packets, regardless of firewall settings. Ensure that the default gateway on your client devices points to the correct VLAN interface IP address. Incorrect gateway configuration results in immediate timeouts that mimic firewall blocks but are actually delivery failures at the network layer.
Configuring Access Control Lists
The definitive fix for SSH timeouts between VLANs is to create explicit permit rules in your ACLs. Navigate to the firewall or router configuration interface associated with the source VLAN. You need to add a rule that explicitly allows TCP traffic destined for port 22 from the source VLAN subnet to the destination VLAN subnet. On Cisco devices, this typically involves applying an ACL to the VLAN interface in the inbound direction. For example:access-list 101 permit tcp 192.168.10.0 0.0.0.255 host 192.168.20.1 eq 22
interface Vlan10
ip access-group 101 inChecking NAT and Security Policies
In some complex environments, Network Address Translation (NAT) policies interfere with inter-VLAN communication. If your router performs NAT between VLANs, ensure that the translation rules do not strip necessary headers or alter source IPs in a way that breaks the return path. Additionally, check for any Zone-Based Firewall policies that might group VLANs into different security zones. Traffic between untrusted zones often requires explicit policy maps to allow specific protocols. If you are using a managed switch with advanced security features, verify that IP Source Guard or Dynamic ARP Inspection is not dropping packets due to mismatched DHCP snooping bindings, which can also cause intermittent connectivity failures.Testing and Validation
Once ACLs and routing are confirmed, perform a systematic test. Start by pinging the gateway of the destination VLAN from the source VLAN to confirm basic reachability. Then, attempt the SSH connection directly. Use tools liketcpdump or Wireshark on the source device to capture packets. Look for TCP Retransmissions; if you see these without any response, the packets are being dropped somewhere along the path. If you receive a TCP RST (Reset), the destination host is reachable but rejecting the connection, indicating a service-level issue rather than a network routing problem.
Frequently Asked Questions
Why does my SSH work after I ping but not before?
This usually happens because a stateful firewall has a permissive rule for outbound ICMP that creates a temporary state entry, or because an administrator incorrectly configured the firewall to allow traffic only after an ICMP exchange. The proper fix is to add an explicit TCP permit rule for port 22, rather than relying on ICMP behavior.Can I disable the firewall to fix this quickly?
While disabling the firewall will immediately restore connectivity, it is highly discouraged in production environments. This exposes all VLAN interfaces to potential attacks from other segments. Instead, refine your ACLs to allow only the necessary ports between specific VLANs.What if I am using a layer 3 switch instead of a router?
Layer 3 switches function similarly regarding ACLs. You must apply IP access-groups to the VLAN interfaces (SVIs). Ensure that the switch’s hardware forwarding table is updated by flushing the cache if necessary, though modern switches handle dynamic ACL updates seamlessly.Does IPv6 have the same issue?
Yes, IPv6 firewalls also use stateful inspection. If you are migrating to IPv6, ensure that your IPv6 ACLs explicitly permit TCP port 22, just as you would for IPv4. Do not assume that enabling IPv6 routing automatically allows management protocols.How do I find where the packet is being dropped?
Use debug commands likedebug ip packet on Cisco routers or equivalent trace functions on other vendors' gear. Enable logging to see if packets are matched by a deny statement in an ACL. Alternatively, check the firewall's hit counters for the relevant rules to see if traffic is hitting a deny rule.