1

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
  • 175

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
  • 175