Page 1 of 1

Route Problem with VPN

Posted: 2019/07/30 18:31:26
by gw1500se
I am having a strange routing problem. I have a single homed host using en0s25 (192.168.0.3). I also have virtualbox installed so it generates the virtual interface virbr0 (192.168.122.1). With that configuration everything works as expected. However, when I connect to a VPN server (openvpn) it produces tun0 (192.168.228.222). The real NIC has an assigned VPN IP of 188.130.138.23. This is the routing table:

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.228.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 enp0s25
128.0.0.0 192.168.228.1 128.0.0.0 UG 0 0 0 tun0
188.130.138.23 192.168.0.1 255.255.255.255 UGH 0 0 0 enp0s25
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s25
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
192.168.228.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0

Now for the problem. When using a browser, the traffic goes over the VPN as expected. However, for some reason SMTP packets (postfix) try to use virbr0 rather than the VPN. Of course it times out and will not send any email when the VPN is active. Why are SMPT packets behaving different than HTTP packets and choosing that particular interface? The postfix folks assure me that it is the kernel routing that causes this and not postfix. Obviously I need to figure out how to fix that. TIA.

Re: Route Problem with VPN

Posted: 2019/07/30 18:42:40
by jlehtone

Code: Select all

ip ro
Shows (IMHO) much more readable "routing table".

Re: Route Problem with VPN

Posted: 2019/07/30 18:52:33
by gw1500se
FWIW

0.0.0.0/1 via 192.168.228.1 dev tun0
default via 192.168.0.1 dev enp0s25 proto static metric 100
128.0.0.0/1 via 192.168.228.1 dev tun0
188.130.138.23 via 192.168.0.1 dev enp0s25
192.168.0.0/24 dev enp0s25 proto kernel scope link src 192.168.0.3 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
192.168.228.0/24 dev tun0 proto kernel scope link src 192.168.228.222

Re: Route Problem with VPN

Posted: 2019/07/30 21:53:56
by jlehtone
Bit messy, but that is probably typical for some vpn implementations.

Your machine has three addresses on three interfaces:
* 192.168.0.3, enp0s25, on subnet 192.168.0.0/24
* 192.168.122.1, virbr0, on subnet 192.168.122.0/24
* 192.168.228.222, tun0, on subnet 192.168.228.0/24

The vpn client contacts remote vpn server 188.130.138.23 by sending packets via 192.168.0.1 (your router?) on subnet 192.168.0.0/24.
Practically all other non-linklocal traffic is sent via 192.168.228.1 on subnet 192.168.228.0/24, i.e. through the "vpn tunnel".
The 192.168.228.1 is essentially the same machine as the 188.130.138.23.

When you browse this forum, you send packets to VPN server that routes them to this site. Replies go to 188.130.138.23 that routes them via tunnel back to you.


Look at what processes listen for TCP:

Code: Select all

sudo ss -tlp
Some do listen on wildcard address *.
Some are bound to specific IP address/interface. Postfix (process "master") is one of them.

I have one machine, where postfix starts before any interfaces and therefore crashes on boot for not being able to bind what it is configured to listen. I have settled on restarting that service after reboots.

That does not explain why outgoing traffic (if it even uses postfix) would be limited and it definitely does not explain why anything would try out via virbr0 for there are no routes to support that.

You could test after VPN is up:

Code: Select all

sudo systemctl restart postfix.service

Re: Route Problem with VPN

Posted: 2019/07/31 19:00:51
by gw1500se
Thanks for the reply. Restarting the service after starting the VPN made no difference. The 'ss' command without VPN returned:

LISTEN 0 100 *:smtp *:* users:(("master",pid=31663,fd=13))
LISTEN 0 100 :::smtp :::* users:(("master",pid=31663,fd=14))

It appears even master is not bound to a specific address. The 'ss' command with VPN is different but I don't know the significance:

LISTEN 0 100 *:smtp *:* users:(("master",pid=31663,fd=13),("smtpd",pid=418,fd=6))
LISTEN 0 100 :::smtp :::* users:(("master",pid=31663,fd=14),("smtpd",pid=418,fd=7))

Re: Route Problem with VPN

Posted: 2019/07/31 21:47:16
by jlehtone
Never noticed that, but

Code: Select all

man 8 master
man 8 smtpd
hint that "master" listens all the time and when something actually initiates a connection, the master starts "smtpd" process to handle it.

You had started VPN, restarted postfix, tested mailing, and then peeked at what is (still) running. I'd guess.


I don't use postfix (knowingly). I do use openvpn, but reject VPN tunnel being the default route; my tunnels are to specific subnets and nowhere else. Therefore, I'm at loss at what to suggest.

Re: Route Problem with VPN

Posted: 2019/08/01 01:35:02
by gw1500se
Thanks anyway for trying.

Re: Route Problem with VPN

Posted: 2019/08/01 16:49:44
by aks
First of all we don't care about "listening" devices per se (yes, yes, postfix talks to listeners to send stuff out) - the issue is with sending.
Those listening entries just mean "all interfaces".
You have two default routes:

default via 192.168.0.1 dev enp0s25 proto static metric 100
default via 192.168.228.1 dev tun0

Hmm no metric on tun0 (bad!)
BTW, the two tun0 entries can be aggregated thus:
0.0.0.0/1 means 0.0.0.0 - 127.255.255.255/32
128.0.0.0/1 means 128.0.0.0 - 255.255.255.255/32
(a.k.a. default - so all things, including all broadcast types, muticast etc.)

The way this works is the destination address is significant. Linux will try to match the most significant match.
If I'm sending to (making some stuff up): 192.168.1.1
and I have the following (pseudo) routing table:
default via 192.168.1.10 eth0
192.168.1.0/30 via 192.168.1.2 eth1
then the packets match the second entry as the most significant entry (192.168.1.0/30 matches 192.168.1.0 - 192.168.1.3), rather than the default (as it is less significant - or a more accurate match).
The postfix folks assure me that it is the kernel routing that causes this and not postfix.
Pretty much true. When we have no significant matches to an address, we'll go by default. You have two and only one has a metric (metrics are there to favour one over the other) - there's probably a "default metric" - can't be assed looking up if that is true, nor the metric value of default, but if that is true, that's what'll apply to tun0 (or maybe not).

So given you know mail packets are going over vibr0 (192.168.122.0/24) you have visibility of those packets - so where are they supposed to be going? Why are we matching that entry as the most significant?