1

Goal: route all internet traffic from eth0 -> tun0 -> tun1 for double-hop VPN. Is the following routing table correct for that goal?

$ ip route show:

0.0.0.0/1 via 10.8.1.1 dev tun1 
default via 10.8.3.1 dev tun0 proto static metric 50 
10.8.1.0/24 dev tun1 proto kernel scope link src 10.8.1.6 
10.8.3.0/24 dev tun0 proto kernel scope link src 10.8.3.4 metric 50 
101.133.213.73 via 10.8.3.1 dev tun0 
127.0.0.0/8 dev lo scope link 
128.0.0.0/1 via 10.8.1.1 dev tun1 
191.72.65.45 via 182.160.0.1 dev eth0 proto static metric 100 
182.160.0.0/24 dev eth0 proto kernel scope link src 182.160.0.19 metric 100 
182.160.0.0/24 dev eth0 proto dhcp scope link src 182.160.0.19 metric 208 
182.160.0.1 dev eth0 proto static scope link metric 100
qatime
  • 13
  • 4
  • That routing table looks OK, but what do you mean by "all" and why are you asking? I wonder if you are using openvpn and are missing some directives... – davidgo Jan 20 '20 at 10:09
  • "all" meaning internet traffic. I am asking because I want to know if this routing table really shows a double-hop VPN connection. NetworkManager was used to create the first tun0. While still connected to the first VPN (tun0) OpenVPN was then used to connect to the second VPN (tun1). – qatime Jan 20 '20 at 19:25
  • Your update is incorrect. I'll answer it below. – davidgo Jan 20 '20 at 20:46
  • I see two VPNs where one is used for establishing second one. Technically all the traffic is going over all just encapsulated. In case the question is if entry point to the internet is tun1's GW than except local traffic and the traffic needed for VPNs directly is the answer yes - logically yes. – Kamil J Jan 20 '20 at 22:00

2 Answers2

0
eth0 : 182.160.0.19/24 (GW: 182.160.0.1)
tun0 : 10.8.3.4/24 (GW: 10.8.3.1 / VPN endpoint : 191.72.65.45 via eth0)
tun1 : 10.8.1.6/24 (GW: 10.8.1.1 / VPN endpoint : 101.133.213.73 via tun0)

This way all traffic (including incomming from tun0) will be routed via tun1 except local traffic on ethernet (182.160.0.0/24) and local traffic on tun0 / "VPN1" (10.8.3.0/24).

With this routing table also all traffic comming from eth0 will be routed via tun1 which is not mentioned / requested in the question... Is this situation OK for you? In case the answer is yes then you can keep this setting.

In case this is not willing situation (you don't want to route traffic from eth0 to tun1 / tun0) you have (at least) two options how to deal it.

  • "custom" routing table

There can be more than just one routing table and based on the rule / policy you can manage which traffic would be handled by the other than default one. This way you can set custom routing table where the default GW would be tun1 and only traffic comming from tun0 would be pointed to this custom routing table.

  • Network namespace

This way you can isolate whole tun interfaces from eth0 (with internal routing between namespaces) so you can have simple (default) routing table set up in the namespace so only traffic from tun0 can reach tun1.

Kamil J
  • 1,632
  • 1
  • 5
  • 10
  • This is not actually the correct answer to the question, and while almost true is not actually correct. Specifically traffic going to 101.133.213.73 does NOT go via tun1 because it is directly accessible via tun0, and traffic to 191.72.65.45 goes straight out the ethernet interface, and I would be certain that this is the remote point for tun0 – davidgo Jan 20 '20 at 21:03
  • @davidgo: In case you would check the table at the beginning of my answer you can see the summary what is in routing table. All the rest is routed via tun1. The IPs you are mentioning are endpoints of the VPNs - so tun0 is open against 191.72.65.45 using directly eth0 and next to it there is tun1 open against 101.133.213.73 using already established tun0. The most probably tun0 (the first VPN) is used just to access second VPN... That is what is visible "indirectly" in the question and summarize at the beginning of my answer ;-). – Kamil J Jan 20 '20 at 21:43
  • Your answer is accurate except that traffic from tun0 will not go across tun1 (due to the NAT that has been implemented for reachability). The question is specifically asking if traffic will go through both tunnels, and the correct answer is yes, but the take-away the OP got from your post appears to be incorrect. I confess the first time I read his post I also didn't get what he was asking. – davidgo Jan 20 '20 at 23:15
  • Double-hop VPN - the second VPN (tun1) does not know the public IP of eth0 because eth0 sent traffic through the first VPN (tun0). – qatime Jan 21 '20 at 01:30
  • This is what the output of `tcpdump -n -i any` looked like: ``` 191.72.65.45 > 182.160.0.19 # (nmanager tun0 IP > 182.160.0.19 and vice versa) 101.133.213.73 > 10.8.3.4 # (openvpn tun1 IP > 10.8.3.4 and vice versa) 10.8.1.24 > website ip addresses ``` It looks like eth0 is only communicating with tun0. And tun0 appears to be only communicating with tun1. And tun1 appears to be only communicating to the outside world. If so, then is this not a true double-hop VPN connection? I don't know. – qatime Jan 21 '20 at 01:40
  • On "low level" / technically all tun1 trafic is encaptulated in packets transferred through tun0 and also all tun0 traffic is encaptulated in the packets transferred through eth0.... you will not see tun1 traffic on eth0 directly but once you see tun0 traffic on eth0 there is transported also "double encaptulated" tun1 traffic... logically it is separated (it seems to be) but technically once tun1 is created with connection over tun0 and tun0 is created over eth0 all the traffic indirectly utilize eth0 (as you have no other connection) - tun1 will have lower speed then tun0 etc. – Kamil J Jan 21 '20 at 06:05
  • Thanks for everyone's answers (of which I will try to read over and over again) and for Kamil J's suggestion 'internal routing between namespaces'. – qatime Jan 21 '20 at 20:52
0

Assuming that the desired sequence is traffic from your LAN should go from the local machine -> tun0 -> tun1, this is likely what is happening, however it is happening in a way which is not visible on a tracreroute.

Lets take a packet destined to an arbitrary internet address - I'll use 8.8.8.8 in this example.

The computer picks up the packet and looks for how to send it. It sees that it should be sent via tun1 (because the 2 routes below are the equivalent of a default route, but more limited, so preferred over the default route - in this case the first route is hit) -

 0.0.0.0/1 via 10.8.1.1 dev tun1
 128.0.0.0/1 via 10.8.1.1 dev tun1

But here is the part which may not be obvious. If you look at the configuration for tun1, you will find it has an endpoint which is 101.133.213.73. There is a specific route for this IP address which goes over tun0

 101.133.213.73 via 10.8.3.1 dev tun0

Similarly, there is another route 

  191.72.65.45  via 182.160.0.1 dev eth0 proto static metric 100

This route makes traffic sent via tun0 directly accessible through the ethernet interface.

As this is a very specific route, traffic to 101.133.213.73 will go through tun0. Thus all traffic flowing to the internet (over tun1) must go through 101.133.213.73 which is itself a tunnel, so yes, data will be flowing through both tunnels.

A traceroute won't show this because the packet does not know it is being tunnelled through a tunnel. That said, you can still check that this is happening by looking at the lower levels - Generating traffic while in another window doing a "sudo tcpdump -n -i any". You will see that whenever a packet is sent to the wider internet, a packet will be sent through each of eth0, tun0, tun1, and the same will be true of returned packets. The packets associated with tun0 will all have the target of 101.133.213.73.

davidgo
  • 6,222
  • 3
  • 23
  • 41
  • Tunnel tun0 seems to be "transport" tunnel for tun1 - all the traffic using tun1 is encapsulated into VPN's packets transported via tun0 which is similar way transported over eth0. So technically all the traffic is going through the eth0. In case of capturing packet, you would "see" the traffic on all interfaces. I would understand the question for the logical flow so what would be entry point (or source IP) in case of traffic to the "wide internet". In this case except local communication and explicit IPs used for establishing VPN connection it is really tun1 - second VPN's GW. – Kamil J Jan 20 '20 at 21:53