[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

How does "making VPN accessible" works?


I wasn't able to find the answer neither on Stack Overflow, nor on
OpenVPN forum. I had a server I had to connect to VPN, but make it
accessible over SSH (via it's physical NIC). I've found a solution,
but I don't really understand how it solves the issue. Just telling a
good place to ask this question is okay too.

The reason it became inaccessible are probably the following routes
that were pushed from VPN server: via tun0.gw dev tun0 via tun0.gw dev tun0

To investigate I added the following rules to iptables:

iptables -A INPUT -p tcp --dport 443 -j LOG
iptables -A OUTPUT -p tcp --sport 443 -j LOG

Started tmux, in one console ran:

echo ------------------------ | tee /dev/tty | systemd-cat; sleep 60;
pkill openvpn

In the other:

openvpn vpn.conf

While it was running, I ran a https request to the server from my
local computer. It hang, I waited for a while, then interrupted it. It
didn't reach nginx running on the server, and there where no entries
from iptables in systemd journal.

Then I've found this solution
That is, I ran the following commands:

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j
CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default dev eth0 via eth0.gw table 3412
ip rule add fwmark 4321 table 3412

There were still no entries from iptables in systemd journal, and the
server remained inaccessible while openvpn was running.

Then, I found another solution
I undid the four commands above and ran:

ip rule add table 128 from eth0.ip
ip route add table 128 default via eth0.gw

This time it worked. And I saw log entries from iptables in systemd journal.

My understanding is that before tinkering with iptables and routing
table, packets from my computer arrived to the server, but the ones
coming back were routed via VPN server's gateway (tun0.gw). There they
were probably NAT'ed (different source IP), and as such were not
recognized as a response by my local computer. But why then were there
no entries from iptables in systemd journal?

The last solution supposedly made packets return via hoster's default
gateway (eth0.gw). But when I do "traceroute", I see them
going via tun0.gw. And "curl -sS ipinfo.io/ip" returns my VPN server's
public IP. So, some packets are going via eth0.gw, some via tun0.gw.
How does it decide? This is routing table before connecting to VPN

default via eth0.gw dev eth0 onlink
eth0.subnet/25 dev eth0  proto kernel  scope link  src eth0.ip

This is what VPN server added:

vpn.server.ip via def.gw dev eth0
tun0.subnet/24 dev tun0  proto kernel  scope link  src tun0.ip via tun0.gw dev tun0 via tun0.gw dev tun0

These lines seem like they should route most if not all packets
originating from the server to go via eth0.gw:

ip rule add table 128 from eth0.ip
ip route add table 128 default via eth0.gw

On second thought, it may depend on source IP chosen. But how does it choose?

To sum it up, I'm not sure if I understand what was off. And I
certainly don't understand how it works now. Any help is welcome.
Including suggestions where to ask for help, and what to read. Thanks
in advance.


Reply to: