1

My server should be connected to a VPN as a client. When I run the OpenVPN script (from HMA), the connection from my local machine to the server over SSH gets lost - connecting is not possible any more and I have to manually kill the VPN process. Additionally, a hidden TOR service (.onion page) is unavailable in that time.

Is is possible somehow that the TOR page is available and I can connect over SSH while the server is connected to the VPN?

2

I have a similar problem. My Ubuntu desktop is on a VPN and my normal SSH connection doesn't work from outside the home network.

Something I did just think of, though. Do you still have the ports forwarded to that computer?

The VPN assigns a new IP address from the VPN site so the router can no longer find that IP address to connect to.

I would assume that you would need to know the new IP address assigned by the VPN host to know what address to connect to.

I am only giving educated guesses, not known fix; so please don't abuse me if it doesn't work. :)

On further investigation, I discovered that you need to forward the ports through your VPN (I think) because the VPN is redirecting port 80 and your SSH tunnels usually use port 22. I think you need to forward port 22 through your VPN so that when you connect to your vpn on port 80 it redirects you through to your forwarded port required by your SSH tunnel ie. PuTTy.

I'm still not 100% sure this is how to do it. If someone can confirm that, it would be great.

2

The problem is that the default gateway gets changed by OpenVPN, and that breaks any connection coming in on the non-VPN interface. Linux will send responses to packets that came in on the real interface out the VPN interface! You need to set up appropriate routes before you start OpenVPN.

What follows works for me. It uses iptables and ip (iproute2). Below, it is assumed that the default gateway interface before OpenVPN is started is "eth0". The idea is to ensure that when a connection to eth0 is made, even if eth0 is not the default gateway interface anymore, response packets for the connection go back on eth0 again.

You could use the same number for the connection mark, firewall mark and routing table. I used distinct numbers to make the diffences between them more apparent.

# set "connection" mark of connection from eth0 when first packet of connection arrives
sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234

# set "firewall" mark for response packets in connection with our connection mark
sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 table 3412

# route packets with our firewall mark using our routing table
sudo ip rule add fwmark 4321 table 3412

===

UPDATE:

The above works fine for me on Debian Jessie. But on an older Wheezy system I have just found that I need to add "via" to the routing table entry:

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 via 12.345.67.89 table 3412

There "12.345.67.89" must be the original non-VPN gateway.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.