What's new

A question about VPNDirector routing implementation

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

eugenezh

New Around Here
Hi everyone,

my question is regarding the VPNDirector routing. Since the introduction of VPN Director, all VPN-related routing for a vpn client is managed by the router, and not by the client (I use OpenVpn). On ovpn client startup, the router creates a separate table (e.g. ovpnc1 for tun11) and a rule that uses the table.
I have noticed the routes from the main table are always copied to the newly created ovpnc1 table, no matter how the option "Redirect Internet traffic through tunnel" is configured.
I can understand why it the routes should be copied if all traffic is redirected via the tunnel.
But if redirect traffic is set to "No", or "VPNDirector", why should such copying be done at all?
My concern is that if routes in the main table are changed later, while the vpn client is still running, there will be an outdated set of routes in the ovpnc1 table. As the ovpnc1 table has higher priority than the main table, this might cause problems in some configurations.
I haven't found any signs that those tables are somehow synchronized while the vpn client is running: it seems like routes are copied to ovpnc1 table on client startup and stay there until the client is stopped.

Would be grateful for any insights why the route copying is always performed.
Thanks.
 
The implementation is indeed imperfect, as you described. In fact, even the individual alternative routing tables (ovpcn1 thru ovpnc5) can suffer from the same problem during normal operations.


Workaround #1:

Workaround #2:

In fairness to the developers, users often treat the router environment as if it was intended to be more dynamic than it is really is supposed to be. For example, the idea of starting and stopping OpenVPN clients at will, although supported, just isn't a good idea. Ideally, it's expected you'll define a specific configuration, reboot, and LEAVE IT ALONE! Same thing w/ static routing and many other common changes. Otherwise, you can end up w/ various anomalies.

All that said, I do believe the example I provided in the links above should be corrected in the firmware since it is common for both the OpenVPN server and client(s) to be established on bootup, and may result in missing information in the routing tables through no fault of the user. IOW, it should be synced. And in the case of John's fork, that's exactly what he did. He used my fixup script as a model for that particular firmware. But AFAIK, it remains a problem w/ Merlin.
 
Last edited:
Thanks for your comments!
it only confirms that if table copying approach is used, the tables should be synced. And at least for configurations when redirect traffic is set to "No", or "VPNDirector", I would not have copied the main table at all (=> no table contents sync is required at least for these modes).
On my router, I have "redirect traffic" = "No" and I added to the openvpn-event script commands that flush the ovpnc1 table and delete the corresponding rule => works great for me.
But I think it might be better to have such behavior out-of-the box for all users.
 
All that said, I do believe the example I provided in the links above should be corrected in the firmware since it is common for both the OpenVPN server and client(s) to be established on bootup, and may result in missing information in the routing tables through no fault of the user. IOW, it should be synced.
Finding a clean way to do so without flat out restarting all clients wasn't obvious, but I think I got an elegant solution now that does not involve that.

I couldn't do it by calling the existing up handler to refresh the whole table because they rely on environment variables only passed on as the client calls the hook at start time.
 
Finding a clean way to do so without flat out restarting all clients wasn't obvious, but I think I got an elegant solution now that does not involve that.

I couldn't do it by calling the existing up handler to refresh the whole table because they rely on environment variables only passed on as the client calls the hook at start time.

Looks good, Thanks! I didn't even realize you were working on it.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top