Verify the SSH Daemon Status
The most common cause for this issue is that the sshd service has crashed or failed to start correctly after the network configuration changed due to the VPN connection. Even if the VPS itself is reachable via ping through the VPN, the specific service handling SSH connections may be inactive. You should first establish a console session using your provider's web-based terminal or out-of-band management interface (such as AWS EC2 Instance Connect, DigitalOcean Rescue Mode, or similar tools provided by your host).
Once logged in via the console, check the status of the SSH service using the command systemctl status sshd (or ssh on some older distributions). If the service is inactive or failed, restart it with sudo systemctl restart sshd. Check for any immediate errors in the output. If the service starts successfully, attempt an SSH connection again. If it fails to start, review the journal logs with journalctl -xeu sshd to identify configuration syntax errors or permission issues on keys.
Check Network Interface Binding
SSH servers often bind to specific network interfaces or IP addresses. By default, OpenSSH listens on all available interfaces (0.0.0.0), but some security-hardened configurations restrict it to only the public-facing interface. When you connect via VPN, you are accessing the VPS through its private IP address, which is different from the public IP. If the SSH server is configured to listen only on the public IP, it will ignore packets arriving on the private VPN interface.
To verify this, run ss -tlnp | grep :22 or netstat -tlnp | grep :22 on the VPS. Look at the local address column. If you see 192.168.x.x:22 or 10.0.x.x:22 instead of 0.0.0.0:22, the server is restricted. Edit the /etc/ssh/sshd_config file and ensure the line ListenAddress is either commented out or set to 0.0.0.0. After making changes, restart the SSH service. Additionally, ensure that the AllowUsers or AllowGroups directives do not inadvertently exclude the user account you are trying to access via the VPN tunnel.
Validate Client-Side Connection Parameters
It is critical that your SSH client connects to the correct IP address. Many users mistakenly try to SSH into the public IP of the VPS while the VPN is active, which routes traffic directly over the internet and bypasses the VPN entirely, potentially hitting a firewall that blocks external SSH attempts. Alternatively, if the VPN assigns a gateway IP rather than the VPS's internal IP, you might be connecting to the wrong endpoint.
Identify the private IP address assigned to the VPS within the VPN subnet. This information is usually found in your VPN provider's dashboard or by running ip addr on the VPS console. Use the explicit IP in your SSH command, such as ssh user@. If you are experiencing timeouts, add the -v flag to enable verbose mode (ssh -v user@). This will show exactly where the connection hangs—whether during DNS resolution, TCP handshake, or key exchange—which helps isolate whether the issue is network routing or authentication.
Inspect Firewall and Security Groups
Even inside a VPN, firewalls can block traffic. Your VPS likely runs ufw, firewalld, or iptables. While these typically allow loopback and established connections, they might drop new incoming connections on port 22 if not explicitly permitted for the VPN subnet. Check your firewall status with sudo ufw status or sudo firewall-cmd --list-all. Ensure that port 22 is allowed for the entire subnet used by your VPN (e.g., allow from 10.8.0.0/24) or globally.
Furthermore, if your VPS provider uses cloud-based security groups (like AWS Security Groups or Azure NSGs), these act as a virtual firewall at the hypervisor level. These rules apply regardless of whether you are connected via VPN or the public internet. Verify in your provider's control panel that the security group associated with the VPS instance allows inbound TCP traffic on port 22 from the VPN CIDR range or from anywhere (0.0.0.0/0). If the security group blocks port 22, no amount of local firewall configuration will help. For more details on managing remote connectivity, you might find How to Access IP/Hostname on Windows using SSH Server useful for understanding client-side configurations.
Review SELinux and AppArmor Policies
In Linux distributions like CentOS, RHEL, or Ubuntu with strict profiles, mandatory access controls like SELinux or AppArmor can prevent SSH from binding to non-standard ports or interacting with network interfaces if policies are misconfigured. While rare for standard port 22 usage, a recent update or change in network policy can trigger these restrictions. Check SELinux status with sestatus. If it is enforcing, check audit logs with ausearch -m avc -ts recent for denials related to sshd. If you suspect interference, you can temporarily set SELinux to permissive mode with sudo setenforce 0 to test if it resolves the issue, though this is not a permanent fix.
Frequently Asked Questions
Why can I ping the VPS via VPN but cannot SSH?
Ping uses ICMP protocol, while SSH uses TCP on port 22. Your firewall or security group may allow ICMP traffic for diagnostics but block TCP port 22 for security reasons. You must explicitly permit TCP port 22 in both the local OS firewall and the cloud provider's security group settings.
Should I use the public IP or private IP when connected via VPN?
You should always use the private IP address assigned to the VPS within the VPN subnet. Using the public IP while the VPN is active may route traffic outside the tunnel, leading to connection failures if external SSH access is disabled or blocked by ISP firewalls.
How do I check if my SSH config file has syntax errors?
You can validate the configuration file without restarting the service by running sudo sshd -t. This command checks for syntax errors and reports them immediately. If it returns no output, the configuration is valid. If it reports errors, fix the indicated lines in /etc/ssh/sshd_config.
What if my VPN provider blocks port 22?
Some consumer-grade VPN providers block standard ports like 22 to prevent abuse or enforce their own paid SSH services. If you cannot connect even after verifying all server-side settings, try changing the SSH port to a non-standard number (like 2222) on the server and configure your client to connect to that port instead.
Can I use port forwarding to bypass this issue?
If direct SSH is blocked, you can create an SSH tunnel from a machine that has access to the VPS. However, if the VPS itself is unreachable via SSH, you need console access to set up port forwarding or alternative protocols. See Tunnel between machine and VPS with port forwarding for techniques on establishing secure tunnels when direct access is limited.