0

I have a server used as a Web and SSH server under Linux. There runs a VPN client, with OpenVPN. If I have properly understood, the VPN changes the routing tables, leading to forwarding all the traffic through the VPN.

Then, when I try to request my Web site hosted on the server, it has become unavailable. I have a very primary knowledge in networking, but what I can assume (feel you free to correct me if I am wrong) is that the request is correctly received by the server through the usual interface, let's name it eth0, but given that the route has changed and passes now through the VPN, the response should be sent on the VPN's interface, which is obviously impossible for security sake.

I looked up the following threads:

https://superuser.com/questions/753736/accessing-a-webserver-hosted-behind-vpn-with-closed-ports-remotely

Reply on the same interface as incoming with DNATed IP

https://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-incoming

but unfortunately, they have been unhelpful.

Let's call the VPN's interface tun0. What I would like to do, is to reply to requests on eth0 on the same interface, namely eth0 itself, instead of tun0 as the VPN runs. Another precision, my server is behind a gateway which is different from it (two different IP addresses).

1) Is it possible to do so?

2) What are the different ways to do that?

Thank you in advance for your feedback.

moth
  • 145
  • 5
  • 1
    It is posssible to do such a setup. The question is, what is the purpose of the VPN and which traffic (e.g. destination range) needs to be routed through the VPN tunnel. In such situation I'd try to only route the needed traffic through the tunnel. – hargut Jun 08 '19 at 18:03
  • The server is also a PC. I would like to route the browsers and torrent's traffic through the VPN tunnel, while not tunneling the traffic pertaining to server activities. – moth Jun 08 '19 at 18:30
  • 1
    So, in your situation it might be easier to only guide server traffic through eth0. Does the server need to be reachable through vpn inbound traffic? – hargut Jun 08 '19 at 20:31
  • For now, no, it does not. 1) How can we do that, namely guiding the server traffic through eth0? 2) But concerning what you pointed out, I wanted to know how to make my server reachable through the VPN inbound traffic, what would be the way to do that please? – moth Jun 08 '19 at 21:44
  • 1
    It is hatd to make any suggestion as there are still too little details on the setup available. The directions could be 1) setup iptable rules that match servers traffic (e.g. source port) and specify the output device device. 2) setup vpn in a routed mode, set iptable rules that match the vpn cidrs and the server traffic, specify the output device tun0. If you have WAN inbound server traffic through VPN it will be more complex. Full details for such setups are not someting that I will do in a serverfault comment. There are too many factors and too little time to explain/clarify all of these. – hargut Jun 09 '19 at 06:22
  • Thank you for this clarification. In my answer you will find how I finally handled this issue. – moth Jun 10 '19 at 09:34

1 Answers1

2

Finally, to my problematic I found a solution inspired from:

https://lartc.org/howto/lartc.rpdb.multiple-links.html .

Here is how to proceed.

To configure the routing of the server so that it is attainable behind a VPN client, a separate routing table ought to be used to avoid an overlap of routing configurations of the two interfaces.

Let <interface>, <table>, <ip>, <gateway> and <network> be the interface name, the table, the IP address of <interface>, the gateway's IP address, and the IP address of the network (that provided by the ISP), respectively.

The procedure to follow is:

  1. Creation of the specific routing table of <interface>: creating the new table <table> in /etc/iproute2/rt_tables.

  2. Setting a different routing configuration for the interface associated to <gateway> by means of a specific table.

    The traffic towards <network> is associated to the interface <interface> and follows the specific routing table <table>:

    ip route add <network> dev <interface> src <ip> table <table>

    Building a default route via this gateway:

    ip route add default via <gateway> table <table>

  3. On <interface>, forcing the traffic from <ip> passing through <network>, to use the interface <interface>:

    ip route add <network> dev <interface> src <ip>

    The src argument is specified to make sure the right outgoing IP address is chosen.

  4. Associating the interface to the appropriate <network>:

    ip rule add from <ip> table

Key idea:

The key idea to understand, concerning why to use this technique here, is that for any request passing through the ISP node, here <network>, the latter will be an intermediate node of the response's route. This seems obvious, but forgetting it leads to not understand why <network> does matter in the routing configuration of the interface normally used to communicate with the server from outside.

Optional:

  1. Setting the routes for all destinations to pass through <gateway> instead of through the VPN's gateway. Useful when it is needed to use the VPN only on a case-by-case basis.

    Let <vpn>, and <vpn's gateway> be the interface name of the VPN (generally tun0), and the IP address of the VPN's gateway, respectively. Then, the routes for any destinations passing through the VPN, more accurately its gateway <vpn's gateway>, have to be replaced by routes passing through <gateway>:

ip route del 0.0.0.0/1 via <vpn's gateway> dev <vpn>
ip route add 0.0.0.0/1 via <gateway> dev <interface>

ip route del 128.0.0.0/1 via <vpn's gateway> dev <vpn>
ip route add 128.0.0.0/1 via <gateway> dev <interface>

0.0.0.0/1 stands for IP addresses ranging from 0.0.0.1 to 127.255.255.255, and 128.0.0.0/1 from 128.0.0.1 to 255.255.254.

Voilà.

moth
  • 145
  • 5
  • Good solution path, via iproute2 instead of iptables. This is a great way to handle such situation. For the CIDR matcher suggestion, keep in mind that 0.0.0.0/1 and 128.0.0.0/1 match approx. half the internet, only parts of these ranges are reserved for specific purposes (e.g private networks). – hargut Jun 10 '19 at 10:42
  • Thank you for this lightening. What do you mean when you say that it matches approximately half the internet? You want to say that: 1. the other half is for private-purpose, or rather, that 2. it lacks the half of all the IP addresses? (the 2. seems unlikely, I don't think there are IP addresses beyond 255.255.255.255, at any rate with IPv4). – moth Jun 10 '19 at 14:30
  • The calculation of the ranges in your answer is correct 0.0.0.0/1 from 0.0.0.1 to 127.255.255.255 and 128.0.0.0/1 from 128.0.0.1 to 255.255.255. But each of the the two selectors covers (approx.) half of the ipv4 based internet, and both contain private and public ip's in its range (e.g. 10.0.0.0/8, or 172.16.0.0/16, ...). So if you match either 0.0.0.0/1 or 128.0.0.0/1 for routing through vpn-gateway or gateway it seems not very reasonable, still it could be intended when wanting (approx.) half traffic through vpn-gateway and (approx.) the other half through gateway. – hargut Jun 10 '19 at 14:54
  • Actually, in my answer **both** 0.0.0.0/1 **and** 128.0.0.0/1 are routed through `` and not through ``. But you are right, I think that `` and `` don't have to be routed in the ``, otherwise, the VPN would become unreachable. Am I right? – moth Jun 10 '19 at 20:40
  • Sorry, I've missed the fact that both are routed via the same gateway. In this case a single entry with 0.0.0.0/0 would be more clear. – hargut Jun 11 '19 at 05:19
  • Yes you are right, actually I just transposed the setting of the VPN which set separately the routes of 0.0.0.0/1 and 128.0.0.0/1. – moth Jun 11 '19 at 10:16