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!

0

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.
  • 1
    54.202.18.143/32 is not a default route. You could say it is the exact opposite; you can't get more specific than a host route. 0.0.0.0/0 is the default route. – Johan Myréen Jan 29 '18 at 6:16
  • @Johan you're quite right. It was late (no excuse, I know) and I misread the netmask. I'll correct my answer momentarily. – roaima Jan 29 '18 at 10:13
  • 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? – Vova Feb 2 '18 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. – roaima Feb 2 '18 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? – Vova Feb 2 '18 at 14:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.