Route Problem with VPN
Posted: 2019/07/30 18:31:26
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.
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.