SSH Connection Timeout While Enabling UFW is a common issue faced by linux administrators nowadays. Recently, I encountered a critical SSH connectivity issue on my OpenVZ-based VPS, which prevented me from accessing my server remotely when I enabled UFW. Despite having UFW and iptables rules configured to allow SSH (port 22), every attempt to connect resulted in a timeout. After extensive troubleshooting, I discovered that misconfigured firewall rules and OpenVZ limitations were causing the problem. Now we can discuss how I diagnosed and fixed the issue. Using this guide you can resolve SSH Connection Timeout While Enabling UFW .
Understanding the SSH Connection Timeout While Enabling UFW
Initially, I ensured that SSH was allowed in UFW before enabling it to prevent accidental lockout. However, despite explicitly allowing SSH (port 22), I still experienced connection failures. Upon further investigation, I found that my iptables firewall had a DROP rule that blocked all inbound traffic unless explicitly permitted. While SSH requests were being accepted, the server’s response packets were likely being dropped, causing the connection failure. This indicated a conflict between UFW and iptables, preventing SSH from functioning correctly.
Additionally, because my VPS was running on OpenVZ, standard iptables rules using conntrack or state tracking failed with the error:
iptables: No chain/target/match by that name.This is a known limitation of OpenVZ, where stateful connection tracking is not supported. Since I couldn’t rely on ESTABLISHED, RELATED rules, I had to configure iptables manually.
Steps To Fix SSH Connection Timeout While enabling CSF
Reset and Clean Up iptables Rules
I realized that having multiple conflicting rules was causing issues. To fix this, I first flushed the existing iptables rules:
sudo iptables -FThen, I re-added only the necessary rules:
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p icmp -j ACCEPT
sudo iptables -P INPUT DROP # Block everything else
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT
I saved the rules to ensure they persisted after a reboot:
sudo netfilter-persistent save
sudo systemctl restart netfilter-persistent
Verify SSH Service and Listening Port
I checked if the SSH daemon was running and listening on port 22.
sudo systemctl status ssh
sudo netstat -tulnp | grep ssh
Since the SSH service was active, I restarted it for good measure.
systemctl restart ssh
Configure UFW Correctly
Since UFW was causing SSH to be blocked, I explicitly allowed SSH before enabling UFW:
ufw allow 22/tcpThen enabled UFW.
ufw enableAfter implementing these fixes, your SSH connection will not exited when the UFW is enabled.
Major issues Identified
UFW and iptables Conflicts
-> UFW and iptables were both managing firewall rules, leading to unexpected behavior.
-> iptables had a DROP rule (DROP all -- 0.0.0.0/0 0.0.0.0/0) that was blocking all traffic except explicitly allowed rules.
-> SSH responses were likely dropped, preventing successful connections.
OpenVZ Limitations
Your VPS runs on OpenVZ, which does not support conntrack or state tracking in iptables.
-> Standard firewall rules like;
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTfailed because OpenVZ lacks connection tracking.
-> This meant return SSH traffic could be blocked unintentionally.
UFW Was Not Configured Correctly
- UFW was enabled before SSH was explicitly allowed.
- UFW’s default policy blocks all incoming connections, including SSH.
- When UFW was active, SSH was silently dropped.
Conclusion
Enabling UFW without proper configuration can lead to SSH connection timeouts, making remote management difficult. To prevent this, always allow SSH traffic before enabling UFW, verify listening ports, and clear conflicting iptables rules. Additionally, be aware of virtualization-related limitations that may affect firewall functionality. Following these steps ensures that SSH access remains uninterrupted while securing the server with UFW.
Also Read:
