Hi, I was tasked with connecting Ubuntu server to VPN server. That is, I had to start OpenVPN client on the server, that would connect it to a VPN server. But the moment I did, the server became inaccessible. I seem to have found a solution, and I probably understand what was off, but I don't really understand how exactly it was solved. The reason must be VPN server adding these routes: [code] 0.0.0.0/1 via tun0.gw dev tun0 128.0.0.0/1 via tun0.gw dev tun0 [/code] [u]To investigate[/u] I added the following rules to iptables: [code] iptables -A INPUT -p tcp --dport 443 -j LOG iptables -A OUTPUT -p tcp --sport 443 -j LOG [/code] Started tmux, in one console ran: [code] echo ------------------------ | tee /dev/tty | systemd-cat; sleep 60; pkill openvpn [/code] In the other: [code] openvpn vpn.conf [/code] 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. [u]Then[/u] I've found [url=https://serverfault.com/questions/659955/allowing-ssh-on-a-server-with-an-active-openvpn-client/793700#793700]this solution[/url]. That is, I ran the following commands: [code] 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 [/code] There were still no entries from iptables in systemd journal, and the server remained inaccessible while openvpn was running. [u]Then,[/u] I found [url=https://unix.stackexchange.com/questions/182220/route-everything-through-vpn-except-ssh-on-port-22/242808#242808]another solution[/url]. I undid the four commands above and ran: [code] ip rule add table 128 from eth0.ip ip route add table 128 default via eth0.gw [/code] This time it worked. And I saw log entries from iptables in systemd journal. [u]My understanding[/u] 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 [b]why then were there no entries from iptables in systemd journal?[/b] The last solution supposedly made packets return via hoster's default gateway (eth0.gw). But when I do "traceroute 8.8.8.8", 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. [b]How does it decide?[/b] This is routing table before connecting to VPN server: [code] default via eth0.gw dev eth0 onlink eth0.subnet/25 dev eth0 proto kernel scope link src eth0.ip [/code] This is what VPN server added: [code] vpn.server.ip via def.gw dev eth0 tun0.subnet/24 dev tun0 proto kernel scope link src tun0.ip 0.0.0.0/1 via tun0.gw dev tun0 128.0.0.0/1 via tun0.gw dev tun0 [/code] These lines seem like they should route most if not all packets originating from the server to go via eth0.gw: [code] ip rule add table 128 from eth0.ip ip route add table 128 default via eth0.gw [/code] On second thought, it may depend on source IP chosen. But [b]how does it choose?[/b] [u]To sum it up,[/u] I'm not sure if I understand [b]what was off[/b]. And I certainly don't understand [b]how it works now[/b]. Any help is welcome. Including suggestions where to ask for help, and what to read. Thanks in advance.

It seems like packets plain [url=https://lists.debian.org/debian-user/2018/05/msg00780.html]disappear[/url] when OpenVPN is running. Unless you do that voodoo magic.

locked out of my server while running OpenVPN client on it

x-yuri

Hi,

I was tasked with connecting Ubuntu server to VPN server. That is, I had to start OpenVPN client on the server, that would connect it to a VPN server.

But the moment I did, the server became inaccessible. I seem to have found a solution, and I probably understand what was off, but I don't really understand how exactly it was solved. The reason must be VPN server adding these routes:

0.0.0.0/1 via tun0.gw dev tun0 
128.0.0.0/1 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 8.8.8.8", 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 server:

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
0.0.0.0/1 via tun0.gw dev tun0 
128.0.0.0/1 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.

x-yuri

It seems like packets plain disappear when OpenVPN is running. Unless you do that voodoo magic.

ecrist

Those two routes being added are there because the server is pushing "redirect-gateway def1" in an attempt to override the local routing. You need to do one of two things:

1) Ask the server administrator to exclude that system from the push.
2) Add --route-nopull to your local configuration file.

Generally, the best approach is to have the server push the correct configuration.