PureVPN updated TLS cert + R7000 + Eibgrad's ovpn script

Discussion in 'Networking Issues' started by Bunsen, May 31, 2018.

  1. Bunsen

    Bunsen Network Newbie Member

    I've been using Eibgrad's split tunnel script on my R7000 with PureVPN for about a year now. I'm also using 2017.3-kille72 firmware.

    PureVPN has updated its TLS certificate which is causing me to change the server i usually connect to. I've found that some of the servers function as expected, while others simply make a successful connection - but the clients assigned to the VPN tunnel cannot access the internet.

    The config is EXACTLY the same [aside from the name of the openvpn server] in both scenarios, and after finding a server that doesn't work, I can change it back to the one I've found that is working and traffic flows as expected once again.

    Frankly, I'm not sure how to troubleshoot it.
    In my novice view, the routing tables that get created by servers that work look just like the routing tables for servers that do not work.

    I'd like to figure out why it's not working on some servers, since the only "working" server with an updated TLS cert is in the US; which is very far from my current location and I'd like to enjoy better speeds from servers that are physically closer to me.

    Any advice is appreciated. Would posting iptables, or routing tables help?
  2. Bunsen

    Bunsen Network Newbie Member

    Routing tables for reference:
    Working pair:
    root@Main:/tmp/home/root# ip route via dev tun11 via dev tun11
    gw.from.the.isp dev ppp0 proto kernel scope link src my.ip.from.isp dev tun11 proto kernel scope link src dev br0 proto kernel scope link src dev lo scope link
    default via gw.from.the.isp dev ppp0

    root@Main:/tmp/home/root# ip route list table 200 via dev tun11 via dev tun11
    gw.from.the.isp dev ppp0 proto kernel scope link src my.ip.from.isp dev tun11 proto kernel scope link src dev br0 proto kernel scope link src dev lo scope link
    default via dev tun11 ​

    Non-working pair:

    root@Main:/tmp/home/root# ip route via dev tun11
    gw.from.the.isp dev ppp0 proto kernel scope link src my.ip.from.isp via dev tun11 dev br0 proto kernel scope link src dev tun11 proto kernel scope link src dev lo scope link
    default via gw.from.the.isp dev ppp0

    root@Main:/tmp/home/root# ip route list table 200 via dev tun11
    gw.from.the.isp dev ppp0 proto kernel scope link src my.ip.from.isp via dev tun11 dev br0 proto kernel scope link src dev tun11 proto kernel scope link src dev lo scope link
    default via dev tun11 ​
  3. Bunsen

    Bunsen Network Newbie Member

    @eibgrad: I don't think there is a problem with the script, but any chance you can help troubleshoot this weirdness?

    What can help point me in the right direction?

    Thanks in advance
  4. eibgrad

    eibgrad Network Guru Member

    I don't see anything in the routing tables that would suggest a problem. What I can tell though is that the alternate routing table (200) is configured to route traffic over the VPN, while the main/default routing table remains w/ the WAN/ISP. So I assume you used either route-nopull or route-noexec to stop OpenVPN from changing the default gateway from the WAN/ISP to the VPN.

    On the face of it, doesn't seem to me either that my script would explain your current problems. But did you try these various servers without the script, and determine if you had issues with accessing the VPN while not using PBR (policy based routing)? That's certainly something I would do, if only to eliminate the script as the culprit.

    Assuming it's not the script for the moment, this is just one of those cases where you need dig deeper, perhaps dumping connection tracking while things are running to see what's happening.

    watch -n5 "cat /proc/net/ip_conntrack"
    What I'd be looking for is connections being formed over the VPN and seeing if perhaps they were not getting replies (i.e., UNREPLIED). If it reports ASSURED, the connection received at least one reply.

    I'd try traceroute and ping on the router as well to see if perhaps the problem is only an issue for clients on the local LAN behind the OpenVPN client as opposed to the OpenVPN client itself.

    Then there's always the OpenVPN client and server logs. Sometimes they will provide clues. I know that sometimes when the OpenVPN client and server are using different versions (e.g., v2.3 vs 2.4), you can have compatibility issues. They're rare, but it sometimes does happen.

    IOW, you just have to start digging deeper, dumping the routing tables, iptables, connection tracking, the logs, etc., until you happen across something that just doesn't look right.
  5. eibgrad

    eibgrad Network Guru Member

    P.S. I did update that script back in Feb of this year (2018). Simplified a few things, and updated the way I detect which version of ipset is installed on the current firmware. So trying the update vs. your current version might be worth considering. Again, I don't see the script as being the issue, but I would never assume it's impossible either.
  6. Bunsen

    Bunsen Network Newbie Member

    @eibgrad - You're right, I am using the route-noexec directive. I'm also using the updated script [0.1.8] now, but just FYI, I experienced the same symptom in version 0.1.7 which prompted me to update a few weeks ago. I tried the watch command you suggested above; It does start to show several additional UNREPLIED connections when connecting to an ovpn server where I see the issue. I guess that confirms that it really isn't letting traffic flow the way it should.
    Finally, I did try without your script [commenting out both the route-noexec, and the calls to the script] and the connection appears to be working properly. All devices confirm the VPN public ip.

    iptables also looks ok to me... I'm not sure where else to look. I don't know enough about how it works.
  7. eibgrad

    eibgrad Network Guru Member

    Admittedly, this is not easy to debug given all the moving parts, esp. based just on feedback in the forum.

    You might try filtering that connection dump further and to see if perhaps they are all to the same destination IP, coming from the same source IP, same destination port (e.g., 53 for DNS), etc. IOW, any kind of pattern that might narrow the field.

    watch -n5 "cat /proc/net/ip_conntrack | grep UNREPLIED"
    Would hurt to see the syslog either around the time things go south, esp. if you left debugging ON in the script.
  8. Bunsen

    Bunsen Network Newbie Member

    A little more testing... Using the policy based routing in the GUI again doesn't work for the servers that don't work while using the script.
    So I now believe that something [routing] is missing when using the route-noexec directive.
    Feel free to blow my theory out of the water.

    Besides the obvious... How can I track what the difference is between using the route-noexec and not using it.
    Can I see what the server is pushing [or what the client is ignoring] when this is used?

    [I don't see anything that stands out in the syslog]
  9. eibgrad

    eibgrad Network Guru Member

    So what you're saying is, it doesn't matter the source of PBR, the GUI or my script, you get the same problem w/ the same OpenVPN servers?

    When route-noexec is NOT used, you should see lines similar to the following in the syslog.

    Jun 5 00:00:16 router daemon.notice openvpn[30225]: /sbin/ifconfig tun12 netmask mtu 1500 broadcast
    Jun 5 00:00:16 router daemon.notice openvpn[30225]: /sbin/route add -net 104.xxx.xx.x netmask gw 68.xxx.xx.x
    Jun 5 00:00:16 router daemon.notice openvpn[30225]: /sbin/route add -net netmask gw
    Jun 5 00:00:16 router daemon.notice openvpn[30225]: /sbin/route add -net netmask gw

    Those routes are being pushed by the OpenVPN server, and the OpenVPN client is responding by configuring its local routing table w/ those routes. The first line is the configuration of the tun12 network interface. The second is binding the remote IP used to establish the OpenVPN connection to the WAN/ISP. The last two are specifically overriding the current default gateway (which is the WAN/ISP) w/ that of the VPN tunnel.

    If you add route-noexec, all but the first should disappear from the syslog. Everything wrt routing remains exactly the same as it was before the VPN was started, only now there's a route to the VPN. And now you need PBR to be able to route traffic over that VPN.
    Last edited: Jun 5, 2018
  10. Bunsen

    Bunsen Network Newbie Member

    Yes, that's what I'm saying.
    But I'm also saying that when I do not use PBR on the "problem servers", the VPN connects and works well.

    I don't see the "ifconfig" command or the "route add" commands - what level debug is needed? [right now i do not specify a debug level, so it would assume the default]

    I do see several "ip route add ..." coming from the "route-up" script, not from the openvpn process. [I think this makes sense with the route-noexec directive present]
  11. eibgrad

    eibgrad Network Guru Member

    Use "verb 4" or higher in the Custom Configuration field to see it.
  12. Bunsen

    Bunsen Network Newbie Member

    I think it might be time to jump to PIA
  13. Bunsen

    Bunsen Network Newbie Member

    @eibgrad: Just out of curiosity... which VPN do you use?
    And would you be willing to try my PureVPN user/pw to see if you get the same weirdness?
  14. eibgrad

    eibgrad Network Guru Member

    I don't use a commercial VPN. Never have. Don't trust any of them. :)

    Only time I use a VPN is to develop and test my scripts, which just means trial versions, free versions, etc. Whatever I can get my hands for free or dirt cheap.

    And speaking of PureVPN, not particularly a fan.


    But if you want me to try it here and see if I can recreate the problem, fine. But make sure to provide enough details about what happens, w/ what servers (and which servers it doesn't happen with), how long it takes for the problem to develop, etc. Just so I have an idea about what to expect and what I'm looking for. I don't even know what you might be doing w/ the script in terms of settings or specific rules that might be causing the problem either. All I know is you're using the script.
    Last edited: Jun 6, 2018
  15. eibgrad

    eibgrad Network Guru Member

    P.S. Also include any information on your hardware and tomato version. I'm presently using Shibby v138 on an ASUS RT-AC68U (ARM). So there's always the chance that could make a difference as well. And if I can't reproduce it on my present system, I may have to setup another router in the lab, which could take some time.
  16. Bunsen

    Bunsen Network Newbie Member

    I'm on a Netgear R7000, running 2017.3-kille72 firmware.
    I do use the route-noexec directive.
    The symptom I experience is immediately apparent; The traffic that is supposed to go over the VPN appears to be interrupted someplace resulting in not being able to connect to the internet.

    I do NOT use route-noexec, I do not experience the symptom, and all devices can communicate over the VPN without an issue. [This is not the desired design]

    To keep it simple, I've only been testing on two servers:
    1) ussf2-ovpn-udp.pointtoserver.com [working]
    2) nl2-ovpn-udp.pointtoserver.com [not working]​
    I can list several others that are not working if needed, but #1 is the only one I've found that is working as I expect it to.

    When i connect to #1 PBR is working properly.
    When using #2, I experience the symptom immediately.

    I believe my config in the script is fairly simple as well...
    I'm just setting two source ip's that I want to use the VPN.
    add_rule -s
    add_rule -s​

    I'm ok to share all the above info. But I'd rather not past my username/pw here for all to view... How can I get this to you?

    [And also.. thanks for helping!]

    Oh, one more thing: The instructions for the openvpn setup don't appear to be updated. The servers listed above use "the new ca":
    -----END CERTIFICATE-----

    The rest of the instruction should be the same as shown here
    Last edited: Jun 7, 2018
  17. Bunsen

    Bunsen Network Newbie Member

    sent in email.
    Thanks for your help!
  18. Bunsen

    Bunsen Network Newbie Member

    I think the "verb 4" has helped to identify something I didn't see previously...
    These types of messages appear on the non-working servers.
    The working ones do not show this.

    I still don't know how to fix it. Seems like this is a problem from the server config side getting pushed to the client.
  19. eibgrad

    eibgrad Network Guru Member

    Never seen that message before. I'll check it out.
  20. Bunsen

    Bunsen Network Newbie Member

    I've tried "allow-recursive-routing" in the client config - it does remove the error, but the symptom remains.
  21. eibgrad

    eibgrad Network Guru Member

    I found the problem. I'll be reporting back shortly.
    Bunsen likes this.
  22. eibgrad

    eibgrad Network Guru Member

    Found the problem. But it has nothing to do w/ the script. It's the way the IP addressing is configured on those particular PureVPN servers, and the use of route-noexec that's causing the problem.

    In order to understand what's gone wrong, we need to look at a normal situation (or at least as normal as PureVPN can get it, more about that later).

    The PureVPN OpenVPN server domain name nl2-ovpn-udp.pointtoserver.com resolves to When connecting to the VPN, it returned a local IP of and remote IP of on the tunnel. And the DNS servers are and Notice that the remote IP of the OpenVPN server is in the *same* network as everything else. And that's the problem.

    That's highly unusual, and it *might* even be a misconfiguration on the part of PureVPN. It really doesn't make sense to be even using a public IP scope within the tunnel in the first place. But for some reason they've chosen to do so. When route-noexec is NOT specified, here's the routing table on the client after the OpenVPN client gets connected. via dev vlan2 dev vlan2 scope link dev br0 proto kernel scope link src dev tun11 proto kernel scope link src dev vlan2 proto kernel scope link src dev lo scope link via dev tun11 via dev tun11
    default via dev vlan2

    Btw, is my WAN/ISP gateway.

    Notice that the remote IP has been bound to the WAN/ISP. That's normal. When the OpenVPN client is NOT using route-noexec, the router itself is bound to the VPN. And if it didn't bind the remote IP for the OpenVPN server ( to the WAN/ISP, it would attempt to connect to that OpenVPN server over the tunnel, which makes no sense.

    But here's what happens when we add the route-noexec directive to the exact same OpenVPN client config.

    root@tomato-lab2:/tmp/home/root# ip route dev vlan2 scope link dev br0 proto kernel scope link src dev tun11 proto kernel scope link src dev vlan2 proto kernel scope link src dev lo scope link
    default via dev vlan2

    This time the router does NOT bind to the WAN/ISP. And it shouldn't have to since once you specify route-noexec, that takes the router off the VPN, so everything wrt the router and the OpenVPN server remote IP will be routed over the WAN/ISP anyway, by default. But because PureVPN has specified *everything* within the tunnel network, even the OpenVPN server remote ip (, it gets routed over the VPN due to the following route in that same table. dev tun11 proto kernel scope link src

    And now the routing system is confused since it's trying to route the OpenVPN client (the outer connection) through the VPN tunnel (the inner connection), and reports it as a recursive routing situation.

    This was easily verified by manually adding back the static route for to the routing table.

    ip route add via
    Even though this fixes it, it makes no sense to me why PureVPN is configuring some of their servers this way. As I said, you're strongly advised to use a private IP scope for the tunnel to avoid these kinds of problems. And if you must use public IPs for the tunnel, then at least keep the OpenVPN server IP outside its scope. But it appears they configured some of their servers such that everything (server, tunnel, dns, etc.), ALL OF IT, is on public facing servers sharing the same scope.

    So I don't know quite who to blame here. PureVPN certainly seems to deserve most of it. But perhaps you could also blame the router for assuming that it didn't need to bind the OpenVPN server remote IP to the WAN/ISP when it knew the default gateway would NOT be changed to the VPN, but remain w/ the WAN/ISP. Then again, I'm not sure if the router is responsible for that action, or perhaps the OpenVPN client itself. Because if it's the latter, then clearly the developers of OpenVPN did not anticipate this particular configuration. And if that's the case, then this probably falls under the category of a *misconfiguration* as far as OpenVPN is concerned.

    Am I surprised? Not really. Never been impressed w/ PureVPN for a variety of other reasons. I'm not convinced they fully understand what they're doing over there. IMO, this shouldn't have happened. It's the first time I've ever seen this type of configuration. It just doesn't make sense. It's asking for trouble.

    As far as a permanent fix, I recommended adding the following to the Custom Configuration field.

    route nl2-ovpn-udp.pointtoserver.com net_gateway
    This will *always* force that OpenVPN server domain name to be bound to the WAN/ISP, regardless whether you add or don't add the route-noexec (or route-nopull) directive. Of course, you could substitute an explicit IP as well.

    route net_gateway
    I might enhance the script to take care of this automatically if this is going to be an ongoing problem. But again, it has nothing to do w/ the script itself. Just throw route-noexec into the Custom Config field and that's sufficient to trigger the problem, script or no script.
    Last edited: Jun 12, 2018
    Bunsen likes this.
  23. eibgrad

    eibgrad Network Guru Member

    P.S. Just noticed the following warning on the OpenVPN client page once it got connected.

    Server is on the same subnet	 Warning: Cannot bridge distinct subnets. Defaulting to routed mode.
    Never seen that happen before, and I assume it's related to this problem.
  24. Bunsen

    Bunsen Network Newbie Member

    Unsurprisingly - I can confirm this fixed the issue.

    The more i learn, the more i agree with your statement:
    I will bring this up with the support guys, but in my experience with them... let's just say "I've not ever... not even once... gotten an answer that was worth 5% of what's written above".

    Thanks again for your time and effort!
    If you're interested, I'll add info to this thread if i get any reply from support.
  25. Bunsen

    Bunsen Network Newbie Member

    As expected the response is laughable...
    I'm not giving up yet - i've asked for an escalation to a team that can answer appropriately.
  26. eibgrad

    eibgrad Network Guru Member

    Doesn't surprise me. That's why I rarely pursue these things. I would just move on to other providers.

    Just in case PureVPN is listening ...

    The important point is that none of this is the fault of the router. It's the OpenVPN client itself (i.e., OpenVPN libraries) that are making the decision whether or not to bind the remote IP of the OpenVPN server to the default gateway prior to it being changed to the VPN. And if that remote IP ends up being within the scope of the VPN tunnel, and you use route-noexec or route-nopull to prevent the change in default gateway, you trigger the bug. And you can trigger the bug on *any* OpenVPN client by merely specifying the route-noexec or route-nopull directive while using those particular PureVPN OpenVPN servers. Just make sure you're using verb 4 or higher, then examine the syslog, and you'll see all the recursive routing warnings.

    Although we found a workaround, the fact that the OpenVPN client itself decided to NOT bind the remote IP of the OpenVPN server when the default gateway was NOT changed to the VPN tells me that OpenVPN does not consider having the remote IP of the OpenVPN server within the same scope as the tunnel to be a valid OpenVPN configuration. You might argue (w/ them) that perhaps this is an oversight on their part, but regardless, based on how OpenVPN client currently works, it's not a good idea. You're eventually going to find more and more ppl complaining about it. You're getting away with it at present because most ppl are not implementing PBR (policy based routing). But for those that do, the use of the route-noexec and route-nopull directives are a common means of implementing PBR, and as demonstrated, trigger the bug.
    Last edited: Jun 12, 2018
    Bunsen likes this.
  27. Bunsen

    Bunsen Network Newbie Member

    I'm still fighting with these guys, but I don't have much faith in them
    I have purchased a new VPN with https://mullvad.net/en/ They seem fantastic so far.

    Also, I had added a line in the script to work around this, in case anyone else runs into this thread.
        # always make sure the vpn server is routed to the wan gateway {PureVPN work around}
        ip route add $(env_get route_network_1) via $(env_get route_gateway_1)
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice