Why should you use sshuttle instead of a traditional VPN?
Imagine you’re at a coffee shop and need urgent access to your company’s internal IP range 10.10.x.x to fix a bug. Usually, you’d struggle with connecting to Cisco AnyConnect or OpenVPN. But what if the VPN server is down or you haven’t been granted access yet?
That’s where sshuttle shines. It’s the perfect “instant” solution for DevOps and SysAdmins. You don’t need complex server-side installations, root privileges on the remote server, or the hassle of configuring certificates.
Previously, I used to use ssh -D to create a SOCKS proxy. However, the biggest drawback was having to manually configure the proxy for every browser or application. sshuttle solves this completely by creating a transparent proxy. All traffic is automatically routed via SSH without needing any additional settings in your applications.
Valuable advantages of sshuttle
- One-side installation: Only needs to be installed on your local machine. The remote server just needs Python 3.6 or higher.
- Smart routing: It interacts directly with the routing table (iptables/nftables) on your local machine to redirect packets.
- DNS Support: Access internal domains like
gitlab.company.localwith ease. - Optimized transmission: sshuttle doesn’t just wrap TCP packets inside TCP (which causes bandwidth drops). It intelligently converts data streams to maintain the most stable speed possible.
Quick setup in a flash
To get sshuttle working, you must have sudo privileges on your local machine. On the server side, a standard SSH account is all you need to get started.
For Linux (Ubuntu/Debian/Fedora):
# Ubuntu/Debian
sudo apt update && sudo apt install sshuttle -y
# Fedora/CentOS
sudo dnf install sshuttle -yFor macOS:
brew install sshuttleAfter installation, type sshuttle --version. If you see the version number (usually 1.x.x), you’re ready.
Real-world usage scenarios
Below are the 3 commands I use most frequently in my daily work.
1. Accessing internal networks only (Recommended)
If you only want to access servers in the 192.168.1.0/24 range while still using your home network for faster Facebook browsing, use this command:
sudo sshuttle -r user@remote-server-ip 192.168.1.0/24At this point, only traffic directed to the 192.168.1.x range goes through the tunnel. Other traffic continues through the internet as usual.
2. Full VPN Mode (0/0)
If you want to be completely anonymous or access geo-blocked services, push all traffic through the server:
sudo sshuttle -r user@remote-server-ip 0/0sshuttle is clever. It automatically excludes the SSH server’s own IP from the routing table to avoid an infinite connection loop.
3. Solving the internal DNS problem
Sometimes you remember the IP but not the domain name, or vice versa. To resolve domains like db.staging.internal, add the --dns flag:
sudo sshuttle --dns -r user@remote-server-ip 10.0.0.0/8Optimization tips and connection testing
How do you know if the tunnel is running? Don’t guess; check the actual data.
Checking IP and Ping
Open another terminal and try curl ifconfig.me. If the result returns the remote server’s IP instead of your home IP, you’ve succeeded. Next, try pinging a virtual machine on the internal network that is normally unreachable:
ping 10.0.0.50Troubleshooting slow speeds
Since it runs over SSH (TCP), sshuttle’s speed is typically around 70-80% of the raw SSH bandwidth. If you experience lag, try enabling verbose mode for debugging:
sudo sshuttle -v -r user@remote-server-ip 10.0.0.0/24If the server reports missing Python, SSH into that server and run sudo apt install python3. This is the most common error preventing sshuttle from initializing the server-side script.
Conclusion
sshuttle wasn’t designed to completely replace corporate VPN systems for hundreds of users. However, for individual technical professionals, it is a lightning-fast “weapon” for remote work. It’s lightweight, secure, and extremely flexible for all modern SSH tunneling needs.
