3

I'm using openvpn to route all user traffic over a server in an encrypted fashion when the user is connected to untrusted networks.

  • The openvpn gateway is 10.8.0.5.
  • The actual IP of the openvpn server is 50.1.1.1.
  • The untrusted networks gateway is 20.1.1.1.

This is the routing table on the client

default via 10.8.0.5 dev tun0 proto static metric 50 
default via 20.1.1.1 dev wlp6s0 proto static metric 600 
50.1.1.1 via 20.1.1.1 dev wlp6s0 proto static metric 600

In general, this setup works fine. All traffic is being routed through the openvpn server.

Now, the user wants to send an email using the company smtp server, which happens to be the same machine that the openvpn server is running on (=> same ip).

Because of the 3rd rule in the routing table, this traffic is now being routed through the untrusted network, which results in two problems:

  • traffic is not protected by the vpns encryption
  • if the untrusted network is only whitelisting port 80/443 or blocking smtp ports, the user cannot send his email

How can I mitigate this problem? Using a different IP for the vpn&smtp server is not a possibility.

Improve this question
2
  • Did you ever get this solved? I'm guessing the multiple table routing mentioned below is the solution, but I've been playing with it forever and can't make it happen.
    – Fmstrat
    Aug 9, 2018 at 12:25
  • @Fmstrat I wrote a python script which filters all dns traffic going through the vpn and spoofs the servers IP in the dns response packets. It's working pretty well.
    – Zulakis
    Aug 9, 2018 at 14:08

2 Answers 2

Reset to default
0

Using split horizon dns, it would be possible to resolve this by resolving the smtp server domain to the VPN-internal ip. However this is quite a complicated solution for a simple problem. A post-up and pre-down script on the client which edits /etc/hosts for the VPN connection would be a similar solution, but has other downsides, for example incorrect entries in the hosts file if the VPN process is exited in a non-standard manner.

Therefore, I'd prefer a different option (perhaps integrated with OpenVPN) which solves this in another way, so that all traffic except for the VPN port is routed over the VPN.

Improve this answer
0

You could implement policy based routing on the clients and route traffic over a different routing table depending on the destination port.

http://www.linuxhorizon.ro/iproute2.html

http://www.sparksupport.com/blog/application-based-routing-in-linux_port-based-routing

This ensures that all traffic that is not vpn traffic is correctly routed over the VPN, but needs some rather complicated changes on the client.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .