Project

General

Profile

Feature #3244

Check that OpenVPN tunnel network does not overlap any other subnet

Added by Phillip Davis over 6 years ago. Updated 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
OpenVPN
Target version:
Start date:
09/29/2013
Due date:
% Done:

100%

Estimated time:

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?

Associated revisions

Revision 19a0636d (diff)
Added by Jim Pingle 3 months ago

Prevent OpenVPN tunnel network reuse. Fixes #3244

Ensures that a submitted tunnel network is not already in use on other
OpenVPN client or server instances, to avoid conflicts.

Revision 9449906b (diff)
Added by Jim Pingle 2 months ago

Prevent OpenVPN tunnel network reuse. Fixes #3244

Ensures that a submitted tunnel network is not already in use on other
OpenVPN client or server instances, to avoid conflicts.

(cherry picked from commit 19a0636d7c0e0178209406480cc383853f0d3f72)

History

#1 Updated by Jim Pingle 3 months 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.

#2 Updated by Jim Pingle 3 months ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#3 Updated by Jim Pingle 2 months 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.

#4 Updated by Jim Pingle 2 months 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