Feature #3244
closed
Check that OpenVPN tunnel network does not overlap any other subnet
Added by Phillip Davis about 11 years ago.
Updated almost 5 years ago.
Description
Lots of newbies just paste 10.0.8.0/24 as the tunnel network on their OpenVPN instances. This comes from an example setup somewhere. Then they put the same tunnel network in multiple OpenVPN instances (servers and clients). The tunnel networks should all be different, and different from any subnet defined on any interface.
In the GUI validation of OpenVPN settings, check that the tunnel network does not overlap any other tunnel network, or any other subnet. Check needed for both IPv4 and IPv6 tunnel network boxes.
Are there any unusual use cases where the same tunnel network is OK on multiple OpenVPN instances?
- Assignee set to Jim Pingle
- Target version changed from Future to 2.5.0
Thinking about this a bit since I noticed the lack of validation when implementing #5851. It makes sense that an OpenVPN tunnel network should not overlap another OpenVPN tunnel network exactly, but it is possible for the tunnel network to be a small portion of a larger subnet already in use, or vice versa. In those cases, advanced users could purposefully take advantage of how longest match routing works and have working configurations that, while unconventional, are valid and functional.
So if this check is added it should only look at other OpenVPN instances and exactly compare tunnel networks. That would catch the worst cases without preventing the other scenarios from working.
- Status changed from New to Feedback
- % Done changed from 0 to 100
- Target version changed from 2.5.0 to 2.4.5
Picked this back to 2.4.5, since #5851 is already on 2.4.5 and this error will be more common with that available.
- Status changed from Feedback to Resolved
Works as expected on 2.4.5.a.20191217.2126, exact matches are rejected.
Also available in: Atom
PDF
Updated by