I'm using an anonymizing VPN, but want SSH access to internal computer.
How do I access my internal computer through SSH? When I do ssh 98.123.45.6, the connection times out.
- IP address from cable provider: 98.123.45.6
- Anonymous IP through VPN: 50.1.2.3
- Internal computer: 192.168.1.123
When searching around, I found recommendations to either set up iptables rules, routing rules, or to add ListenAddress to sshd_config. Which of these applies to my case?
Here is my route:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.115.81.1 10.115.81.9 255.255.255.255 UGH 0 0 0 tun0 10.115.81.9 * 255.255.255.255 UH 0 0 0 tun0 50.1.2.3-sta ddwrt 255.255.255.255 UGH 0 0 0 eth0 192.168.1.0 * 255.255.255.0 U 202 0 0 eth0 169.254.0.0 * 255.255.0.0 U 204 0 0 vboxnet0 loopback * 255.0.0.0 U 0 0 0 lo default 10.115.81.9 128.0.0.0 UG 0 0 0 tun0 128.0.0.0 10.115.81.9 128.0.0.0 UG 0 0 0 tun0 default ddwrt 0.0.0.0 UG 202 0 0 eth0
To resolve this issue you will need to set up both iptables and routing rules. The specific problem you're encountering is that outgoing SSH packets are being routed via your anonymous VPN tunnel interface instead of your Ethernet interface. This is happening because your VPN software set up a routing rule to send any and all unhandled traffic via the tunnel interface. Good for anonymizing your network traffic; bad for establishing SSH connections to your computer.
There are a few ways to fix this problem, but I will share with you the one which worked for me in an identical situation. Here's what we need to do:
Note: I was working with Raspbian while doing the following, so you might need to adjust the commands a little to fit your distro.
Creating a new IP rule table
Begin by inspecting iproute2's table definition file. We want to make sure we don't use the name or number of any existing rule tables.
You'll likely see something along these lines:
Pick an arbitrary number and name for your new rule table -- anything not used above. I will use number 201 and name
novpn
for the remainder of this answer.Append a definition directly to the definition file or edit it in the text editor of your choice:
Add a new IP rule to lookup the no-VPN table
Check for any existing ip rules that deal with netfilter masks:
If grep turns up nothing, you're in the clear. If it does print some lines, take note of the hexadecimal number to the right of the word
fwmark
in each line. You will need to pick a number that is not currently in use. Since I had no existing fwmark rules, I chose the number 65.What this does is cause any packets with netfilter mask 65 to lookup our new
novpn
table for instructions on how to route the packets.Direct all traffic in our new table to use the Ethernet interface
The important thing to note here is
dev eth0
. This forces all traffic that passes through thenovpn
table to only use the hardware Ethernet interface, instead of the virtual tunnel interface that your VPN creates.Now would be a good time to flush your iproute cache, to make sure your new rules and routes take immediate effect:
Instruct firewall rule to mark all SSH traffic with the designated netfilter mask
There are too many options here for me to explain in any great depth. I strongly encourage you to read the manual page for iptables to get a sense of what's going on here:
In a nutshell: we are appending an output rule to the firewall's mangle table (for specialized packet handling) that instructs it to mark any TCP packets originating from source port 22 with our designated netfilter mask 65.
What next?
At this point, you should be ready to test SSH. If all goes well, you should be met with the happy "login as" prompt.
For security's sake, I recommend you instruct your firewall to drop any incoming SSH requests from the tunnel interface:
Note that the all of the instructions above are transient (except for the creation of the rule table ID) -- they will clear the next time you restart your computer. Making them permanent is an exercise I leave to you.