Feature #3244


Check that OpenVPN tunnel network does not overlap any other subnet

Added by Phillip Davis about 8 years ago. Updated almost 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:


Lots of newbies just paste 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?

Actions #1

Updated by Jim Pingle about 2 years ago

  • 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.

Actions #2

Updated by Jim Pingle about 2 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #3

Updated by Jim Pingle almost 2 years ago

  • 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.

Actions #4

Updated by Jim Pingle almost 2 years ago

  • 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