SSH Connecting Via VPN Fails – How To Fix?

SSH often works from your normal connection but fails when a VPN is enabled. This post explains the causes and practical fixes, including handling cases where servers only allow specific IPs and VPNs use rotating addresses or different protocols.

The symptom

SSH works when you are not using a VPN:

ssh [email protected]

When you connect to a VPN, the same command either times out, hangs, or disconnects:

ssh: connect to host myserver.com port 22: Connection timed out

Why this happens

When you connect to a VPN your networking setup changes — routes are modified, DNS servers may change, and the VPN or its operator may impose firewall rules. Common causes:

• VPN forces all traffic through the tunnel (full-tunnel VPN) — SSH is routed through the VPN and may be blocked or misrouted.
• VPN firewall blocks outbound SSH (port 22) — some operators or corporate VPNs intentionally block SSH to reduce risk.
• DNS resolution changes — the VPN’s DNS servers may not resolve your hostname the same way as your regular network.
• Routing table conflicts — traffic to the SSH server goes to the wrong interface or is routed into the tunnel but cannot exit to the public server.
• Server-side IP whitelisting — the SSH server only allows certain client IPs; when your IP changes due to the VPN, you become blocked.

Diagnose quickly

1. Can you ping the server while on the VPN? ping myserver.com
2. Run a traceroute to see where traffic stops: traceroute myserver.com (or tracert on Windows).
3. Try connecting by IP instead of hostname: ssh user@<server_ip>.
4. Try a different port if your server supports it: ssh -p 2222 [email protected].
5. Check your routing table: ip route (Linux/macOS) or route print (Windows).

You can also check if another VPN works. For example, ProtonVPN has a free plan that you can test.

Common fixes

1. Use split tunneling

If your VPN client supports it, configure split tunneling so traffic to the SSH server goes directly over your normal gateway rather than through the VPN tunnel. For OpenVPN you can add a route in the client config to bypass the tunnel for a particular IP:

route <server_ip> 255.255.255.255 net_gateway

That tells the system to reach the SSH server using the default (non-VPN) gateway.

2. Use an alternative SSH port

If the VPN blocks port 22, configure your server to listen on another port (for example 2222 or 443) and connect using ssh -p <port> user@host. Port 443 (HTTPS) is often allowed where other ports are blocked.

3. Bypass DNS issues

Try connecting directly by IP or set a trusted DNS resolver (for troubleshooting only) like 8.8.8.8 to see whether DNS is the culprit.

4. Add a static route

If traffic is routed incorrectly after VPN connection, add a specific route that sends your SSH destination out via your local gateway:

sudo ip route add <server_ip>/32 via <your_gateway_ip>

5. Check server-side IP rules

If the server uses IP whitelisting, firewalls or tools like fail2ban might block the VPN IPs. Confirm logs on the server and whitelist the correct addresses (see the section on rotating IPs below).

Special case: Server whitelists IPs and whitelisting doesn’t seem to work

When a server only allows specific client IPs, whitelisting the wrong address (or a single address) can still leave you blocked if the VPN changes IPs, protocols, or provides multiple egress points. Here are important nuances and recommendations:

Rotating VPN IPs and protocols

Many commercial VPN services (and some corporate VPNs) offer multiple protocols and multiple egress servers. Some providers use UDP-based tunnels (e.g., OpenVPN over UDP) or newer protocols like WireGuard that may shift your public IP frequently. If your VPN assigns a new public IP each session, whitelisting a single IP will fail.

Whitelist ranges vs. single IPs

To make SSH work while on such a VPN, admins sometimes whitelist an IP range owned by the VPN provider. Whitelisting ranges increases the chance that your current VPN exit node is covered, but it also broadens access and increases security risk.

Practical workflow

1. Identify the VPN egress IP(s) while connected (e.g., visit a “what is my IP” service from the VPN connection or check your public IP from the client machine).
2. Whitelist the IP or the smallest practical CIDR range on the server firewall to permit your SSH connection.
3. Perform the SSH session you need.
4. After you finish, remove the temporary broader whitelist entry to reduce attack surface and re-lock to the strict policy. Automating add/remove with a short-lived change-window reduces risk.

Note: If you control both ends, consider alternative secure options such as using a jump host with mutual TLS, VPN-aware access proxies, or ephemeral certificate-based SSH authentication that reduces reliance on IP whitelists.

Example: UDP protocols and why they matter

Some firewall or network appliances differentiate traffic by protocol at a deeper level; UDP-based VPN tunnels can be handled by different NAT/firewall rules compared to TCP. This can affect which egress address is used or whether port-forwarding/NAT behaves identically. If you see inconsistent behavior across protocols, test the VPN using both UDP and TCP modes (if the client supports it) to find the most stable option for your environment.

Provider-specific notes (user experience)

Different VPN providers behave differently. For example, some users find that a provider with rotating egress IPs (or many exit nodes) requires range whitelisting, while other providers with more stable exit IPs don’t need that. One user-reported experience is that ExpressVPN’s rotating/varied exit nodes required whitelisting ranges, whereas ProtonVPN gave consistent results for the same workflows. Your mileage may vary; always verify the egress IPs and provider behavior before permanently changing firewall policies.

Security considerations

Whitelisting broad IP ranges opens your server to more potential attackers. If you must whitelist ranges temporarily, follow these best practices:

• Whitelist as small a range as possible.
• Time-limit the whitelist change and remove it immediately after the task completes.
• Use strong authentication on the SSH server (public-key only, no password auth) and consider two-factor authentication for SSH where possible.
• Use logging, alerting and temporary access automation so whitelist additions/removals are auditable.

Summary checklist

Example commands

Useful commands referenced in this post:

• Connect via hostname: ssh [email protected]
• Connect via IP: ssh user@<server_ip>
• Connect on alternate port: ssh -p 2222 [email protected]
• Check routing (Linux/macOS): ip route
• Add a route to bypass the VPN (Linux): sudo ip route add <server_ip>/32 via <your_gateway_ip>
• OpenVPN client route example: route <server_ip> 255.255.255.255 net_gateway

Final thoughts

SSH failing only when a VPN is enabled usually comes down to routing, DNS, or firewall/whitelisting behavior — and in some cases the VPN provider’s use of rotating IPs or different transport protocols. Identify which layer is interfering, apply the least-permissive fix that works (split tunneling, minimal whitelist ranges, or alternative ports), and remove any temporary, broader access when you’re done.

If you’d like, I can adapt this post to include step-by-step OpenVPN / WireGuard / AnyConnect examples for a specific operating system (Windows, macOS, Linux) or a specific VPN client configuration.

Last Updated on 17 October 2025