OpenVPN Client: Potentially wrong VPN gateway (aka, any ol' gateway will do)

Discussion in 'Tomato Firmware' started by eibgrad, May 15, 2019.

  1. eibgrad

    eibgrad Network Guru Member

    As I've reported in prior bug reports, the tomato OpenVPN client does NOT use the OpenVPN scripting engine. And that has lead to numerous problems.

    Code:
    May 15 09:43:06 tomato-lab2 daemon.notice openvpn[22168]: OPTIONS IMPORT: --ifconfig/up options modified
    May 15 09:43:06 tomato-lab2 daemon.notice openvpn[22168]: OPTIONS IMPORT: peer-id set
    May 15 09:43:06 tomato-lab2 daemon.notice openvpn[22168]: OPTIONS IMPORT: adjusting link_mtu to 1625
    May 15 09:43:06 tomato-lab2 daemon.notice openvpn[22168]: OPTIONS IMPORT: data channel crypto options modified
    May 15 09:43:06 tomato-lab2 daemon.notice openvpn[22168]: Data Channel: using negotiated cipher 'AES-256-GCM'
    May 15 09:43:06 tomato-lab2 daemon.notice openvpn[22168]: Initialization Sequence Completed
    May 15 09:43:08 tomato-lab2 user.notice vpnrouting[22173][tun12]: Got gateway for tun12 - IP 10.10.0.42 - ID 312
    May 15 09:43:08 tomato-lab2 user.notice vpnrouting[22173][tun12]: Type: 1 - add 192.168.1.14
    May 15 09:43:08 tomato-lab2 user.info preinit[1]: igmpproxy is stopped
    May 15 09:43:08 tomato-lab2 user.notice vpnrouting[22173][tun12]: Completed routing policy configuration for client2
    If you examine the above partial syslog, you'll notice that "vpnrouting" (which is managed by the Routing Policy tab) is done *after* the OpenVPN client has completed initialization. Had the OpenVPN client been using the scripting engine for these purposes, it would have likely used the OpenVPN route-up/route-pre-down directives/events to effect the same changes. And those events are called *before* initialization is completed. That's one of several ways you can tell the OpenVPN client is NOT using the scripting engine.

    Notice specifically the following line.

    Code:
    vpnrouting[22173][tun12]: Got gateway for tun12 - IP 10.10.0.42 - ID 312
    What the router is doing is parsing ifconfig (much like my soon to be released Routing Policy fixup script) to find the OpenVPN client's network interface and the assigned IP, and use it as the basis for the default gateway IP in the alternate routing table (in this example, table #312, because I'm using the second OpenVPN client instance).

    But that's a bit risky. What this assumes is that the OpenVPN server's local routing table has a default gateway (very likely does, but it's not guaranteed). And even if it does, it assumes that that default gateway is the one intended for OpenVPN clients. Again, that's not guaranteed.

    There's a reason the OpenVPN scripting engine returns the VPN's *actual*default gateway to the OpenVPN client. It may be a special default gateway intended only for its OpenVPN clients. The VPN provider may want to separate these users for a variety of reasons (e.g., he has a special firewall configuration, perhaps to filter those OpenVPN clients, or to configure port forwarding using a web-based GUI). Whatever the reasons, if you don't use the proper default gateway, there's the risk Routing Policy won't work, or stop working down the road.

    Now to be fair, I believe the likelihood of this happening is very remote. I suspect 99% of the time, you'll get away with it. But that's just a guess. Like everyone else, I don't have a large enough sample size to really know for sure. And when users have unexplained problems, who's to say this isn't at least one of the causes. I doubt anyone would even notice, it's such a subtle error.

    This is another example of how NOT using the OpenVPN scripting engine leaves you open to mistakes. And in this case, it would be VERY hard to detect. Things would just not work, or stopping working suddenly. And at least superficially, everything would appear normal, kosher.

    Like some of the other bugs, I don't see this being fixed anytime soon unless the OpenVPN client/server has a major overhaul to get it working w/ the OpenVPN scripting engine. But I wanted to present the problem just in case you experience odd or unexplained Routing Policy "outages" w/ the OpenVPN client. This is one to at least consider during your investigations.
     
  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