0

I took the material from how to understand the routing table on an OpenVPN client.

Here is the route table:

# route -n
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
54.202.18.143   10.0.2.2        255.255.255.255 UGH   0      0        0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U     1      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
0.0.0.0         10.8.0.5        128.0.0.0       UG    0      0        0 tun0
128.0.0.0       10.8.0.5        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0

I configured the OpenVPN, and I am confusing about two things:

  1. TCP packets via tun0
  2. UDP OpenVPN packets via 54.202.18.143 (public VPN IP)

Question:

  1. Why does OpenVPN need this line: 54.202.18.143 10.0.2.2 255.255.255.255 UGH 0 0 0 eth0?
  2. Which packets are going through the tun0?
  3. Which packets are going through the 54.202.18.143?

Thanks for your help!

Improve this question

1 Answer 1

Reset to default
2

Confusions:

  1. It's not just TCP packets flowing through tun0. It could be UDP and ICMP too.
  2. UDP is the protocol that encapsulates your OpenVPN traffic

Question answers:

  1. This is an explicit route to the VPN gateway (the 255.255.255.255 ensure that 54.202.18.143 matches exactly that one IP address: nothing more and nothing less):

    54.202.18.143   10.0.2.2        255.255.255.255 UGH   0      0        0 eth0

    I assume that 10.0.2.2 is your LAN router, so this is telling your client that all traffic for the VPN endpoint is to be sent out via eth0 to your router (and onward). This ensures that because your pseudo-default route has been updated to send all traffic via your VPN, the encapsulated packets themselves don't get routed through the VPN too. (Like a snake eating its tail, this is not a good situation to be in.)

    The pseudo-default route is built from these two lines:

    0.0.0.0         10.8.0.5        128.0.0.0       UG    0      0        0 tun0
128.0.0.0       10.8.0.5        128.0.0.0       UG    0      0        0 tun0

    These have a higher priority than your real default route but lower than priority than any other lines in your routing table. Together they match all traffic except that which matches other lines in your routing table.

  2. All packets except the OpenVPN UDP encapsulation traffic will go through tun0
  3. Only the OpenVPN UDP encapsulation traffic will go via 54.202.18.143.
Improve this answer
4
  • Thanks for your answer, but I still don't understand why I need both routes (1st tun0 and 2nd 54.202.18.143). Why can't I use only one? Commented Feb 2, 2018 at 14:20
  • @Vova as I said in my answer, you need a route to the VPN endpoint so that OpenVPN traffic can get to that endpoint, and you appear to want a route through the VPN tunnel for all your other traffic. Commented Feb 2, 2018 at 14:22
  • Which application knows to send packets to that specific IP '54.202.18.143'? Through which interface the browser's traffic is going through? Commented Feb 2, 2018 at 14:44
  • This is a kernel routing table. Applications neither know nor care how their traffic gets to an end-point as long as it gets there. Traffic for 54.202.18.143 goes there outside the VPN. Traffic for anywhere else goes through the VPN and out of the VPN server's end-point to the true destination. Commented Feb 2, 2018 at 15:20

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.