ASUS RT-AC86U Merlin 386.4 No internet traffic on OpenVPN

[whhaatt]

When you added the 'code' marks, you ended up replacing the output from the routing tables w/ the output from ifconfig. I still have the original output from the latter saved, but it might be confusing to others.

Based on what I'm seeing in the ip rules and routing tables, it should be working. I don't see anything wrong. At least not yet.

Each of the IPs listed in the VPN Director are using a different OpenVPN client. And I can see that in the ip rules. And each routing table is configured w/ the correct default route for its OpenVPN client.

emm very strange, so the external ip for each vpn is the same on all devices.

Good to know that my config is ok

 

[eibgrad]

Configure each OpenVPN client w/ "Yes (all)", then try connecting to each OpenVPN client, one at a time (making sure only one is connected at any given time). See what public IP is reported in each case.

 

[whhaatt]

done, still same behaviour, all external ips point to London, even though ovpn1 was stopped, I am stumped

 

[eibgrad]

BTW, it might be better sometimes to determine how a given client is being routed by using a traceroute (on Windows it's called tracert), rather than depending on the public IP. Esp. when you have multiple, concurrent OpenVPN clients. Even some smartphone network apps have this feature. Usually the second line/hop of the response will tell you which gateway the router used for the given traceroute.

# Windows
tracert -d google.com

# Linux
traceroute -n google.com

The -d and -n options simply prevent the traceroute from trying to do a reverse name lookup on the raw IP addresses. It's just faster.

 

[whhaatt]

BTW, it might be better sometimes to determine how a given client is being routed by using a traceroute (on Windows it's called tracert), rather than depending on the public IP. Esp. when you have multiple, concurrent OpenVPN clients. Even some smartphone network apps have this feature. Usually the first line of the response will tell you which gateway the router used for the given traceroute.

# Windows
tracert -d google.com

# Linux
traceroute -n google.com

The -d and -n options simply prevent the traceroute from trying to do a reverse name lookup on the raw IP addresses. It's just faster.

OVPN2
C:\Users\whhaatt-lenovo>tracert -d www.google.com

Tracing route to www.google.com [172.217.168.196]
over a maximum of 30 hops:

  1     1 ms    <1 ms     1 ms  192.168.2.1
  2    13 ms    13 ms    13 ms  10.121.208.1
  3    16 ms    15 ms    14 ms  212.102.63.124
  4    13 ms    12 ms    18 ms  138.199.0.78
  5    14 ms    13 ms    12 ms  5.56.17.177
  6    23 ms    23 ms    23 ms  81.95.2.137
  7    24 ms    23 ms    23 ms  72.14.209.160
  8    26 ms    26 ms    26 ms  108.170.252.18

ovpn3
traceroute to google.com (142.250.179.206), 30 hops max
Hop 1:
    From RT-AC86U-E1B8 (192.168.2.1), 1 ms

Hop 2:
    From 10.121.208.1, 14 ms

Hop 3:
    From 212.102.63.124, 19 ms

Hop 4:
    From 138.199.0.74, 18 ms

Hop 5:
    From 5.56.17.177, 14 ms

Hop 6:
    From 81.95.2.137, 44 ms

Hop 7:
    From 72.14.209.160, 27 ms

Hop 8:
    From 108.170.251.145, 54 ms

Hop 9:
    *

Hop 10:
    From 108.170.236.120, 48 ms

Hop 11:
    From 216.239.41.208, 46 ms

Hop 12:
    From 108.170.241.161, 42 ms

Hop 13:
    From 142.251.48.179, 39 ms

Hop 14:
    From ams15s42-in-f14.1e100.net (142.250.179.206), 39 ms

Traceroute complete: 14 hops, time: 10719 ms

cannot test ovpn1 as it is a smarttv

The routes seem the same

 

[whhaatt]

When I stopped OVPN1 then OVPN2 showed the correct external IP - edinburgh and all subsequent devices (eg ovpn3) also showed ovpn2 external IP, it looks like OVPN1 then 2 then 3 etc, work in priority no matter what the rules are set too

 

[eibgrad]

If you now go back to using the VPN Director and have all the OpenVPN clients connected concurrently, then do several traceroutes, each from a LAN client that is bound to a different OpenVPN client, do those traceroutes differ (what matters is actually the second line/hop, NOT the first)? And if that requires temporarily removing the TV from the VPN Director in favor of some other device that can run a traceroute, do so.

What ultimately matters is whether each LAN client is correctly bound to its OpenVPN client, and not so much what public IP is reported. When using a single OpenVPN client, that's typically how you tell if it's working. The public IP will differ from your ISP assigned public IP. But when using multiple, concurrent OpenVPN clients, I'm not so sure you can count on that behavior. For all I know, the VPN provider is doing something funky when he sees you coming into his servers from the YOUR public IP. Maybe he's routing all that traffic through a common, secondary server! Who knows.

Again, all that really matter is if the routing is correct. And as I said before, I see nothing wrong in those routing tables. A traceroute is more informative in this case, at least if you start comparing the output among various LAN and OpenVPN clients.

 

[whhaatt]

Laptop OVPN2

C:\Users\whhaatt-lenovo>tracert -d www.google.com

Tracing route to www.google.com [142.251.39.100]
over a maximum of 30 hops:

  1     1 ms     1 ms    <1 ms  192.168.2.1
  2    14 ms    13 ms    18 ms  10.123.40.1

Android OVPN3

2nd hop is the same as above

 

[whhaatt]

seems to be working, I forgot to change the client vpn settings to use VPN director policy.

The 2nd hops are now different

 

[eibgrad]

Good to hear it's working.

 

[whhaatt]

Good to hear it's working.

Thanks for all your help