Bug #7156
closed
Change in 'Block bogon networks' or 'Block private netowrks' GUI options kills routing entries for OpenVPN interfaces.
Added by Karl Fife over 7 years ago.
Updated over 7 years ago.
Affected Architecture:
All
Description
It appears that toggling in the 'Block bogon networks' and/or 'Block private netowrks' GUI option kills the automatic routes inserted for openvpn server service (and/or client service).
Steps to recreate (server-side example):
- Validate that server side routes exist for OpenVPN server assigned to interface ovpns1
e.g. 10.1.128.0/17 172.30.1.130 UGS 40038923 1500 ovpns10
- ENABLE 'Block bogon networks' on the corresponding interface. Save, Apply.
- Refresh server-side routes.
- Note the route is absent, and that new connections fail.
- Now RESTART the OpenVPN server service.
- Note that the routes have been re-inserted into routing table, and new connections can again be established.
I observe the same behavior again when the 'Block bogon networks' option is DISABLED
I observe the same behavior when toggling 'Block private networks' instead of 'Block bogon networks'
I observe the same behavior when toggling client side interfaces for OpenVPN client service.
I have observed this on multiple versions including 2.2.6 (amd64-Full) and 2.3.2-RELEASE-p1 (i386-nanobsd).
- Status changed from New to Rejected
Any time you save/apply changes on an assigned OpenVPN interfaces you have to restart the VPN. It's always been that way. Nothing to do with the options you select.
How is one supposed to know that this is a requirement? It's exactly not self-evident that changing something as simple as the interface name would break OpenVPN functionality (which in fact, it appears to do). I've never seen it documented.
Shouldn't that seemingly idiosyncratic detail be documented somewhere to prevent prevent disruptive lockouts? I haven't ever read about this requirement. I think a case could be to have the 'save' action conditionally restart the OpenVPN service, if OpenVPN is the underlying interface type (e.g. ovpns{n}).
As I've thought about this more, it seems to me that the correct behavior is for "Apply Changes" to trigger a restart the OpenVPN service if changes are made to the interface, and if the underlying interface type is OpenVPN.
The case to be made is that otherwise it's not possible to make a changes to a remote interface without a lockout condition. Documentation/knowledge of the restart requirement is irrelevant.
Even if it were possible for a remote administrator to restart OpenVPN, it seems more consistent with the goal of the project in general to have the GUI to restart/reload any underlying dependencies/rules/services when changes are applied, rather than relying on a sysadmin to keep track of such things.
Also available in: Atom
PDF
Updated by 
Updated by