Project

General

Profile

Actions
Copy link

Bug #12887

closed

GUI does not reject an invalid OpenVPN tap mode configuration with an empty tunnel network "Bridge DHCP" disabled

Added by Viktor Gurov over 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Viktor Gurov
Category:
OpenVPN
Target version:
2.7.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.05
Release Notes:
Default
Affected Version:
2.6.0
Affected Architecture:

Description

If both "tunnel network" and "Bridge DHCP" options are disabled, an error occurs:

openvpn[95193]: Cipher negotiation is disabled since neither P2MP client nor server mode is enabled
openvpn[95193]: Options error: --client-connect requires --mode server
openvpn[95193]: Use --help for more information.

Input validation should prevent such configuration

Actions
Copy link
 #1

Updated by Viktor Gurov over 2 years ago

  • Target version set to 2.7.0
  • Plus Target Version set to 22.05
Actions
Copy link
 #2

Updated by Jim Pingle over 2 years ago

  • Status changed from New to Pull Request Review
Actions
Copy link
 #3

Updated by Viktor Gurov over 2 years ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #4

Updated by Danilo Zrenjanin over 2 years ago

  • Status changed from Feedback to Resolved

Tested against:

2.7.0-DEVELOPMENT (amd64)
built on Sat Mar 19 06:21:02 UTC 2022
FreeBSD 12.3-STABLE

I wasn't able to save the OpenVPN server setup with no tunnel network defined and disabled Bridge DHCP.

The following input errors were detected:

    TAP server mode requires an IPv4/IPv6 Tunnel Network or Bridge Interface to work.

I am marking this ticket resolved.

Actions
Copy link
 #5

Updated by Jim Pingle over 2 years ago

  • Subject changed from OpenVPN startup error if the tunnel network is empty and Bridge DHCP is disabled to GUI does not reject an invalid OpenVPN tap mode configuration with an empty tunnel network "Bridge DHCP" disabled

Updating subject for release notes.

Actions
Copy link
 #6

Updated by Yousif Hassan almost 2 years ago

Can someone explain this bug fix to me? It seems like it may have been driven by a change in OpenVPN itself, but this actually prevents setting up a P2P VPN in tap/bridge mode. Consider the following simple scenario:
- tap mode on client and server
- peer-to-peer mode
- bridge interface successfully created in "Interfaces", bridging the LAN and the OpenVPN interfaces together, as required

In this case, the error requests either a "bridge interface" to be set, or an IPv4/6 tunnel network to be set, but here is the problem with that:
- I do not want to set an IPv4 tunnel network, because this is a bridged VPN, so these should theoretically be blank
- I can not select a bridge interface, because "Allow clients on the bridge to obtain DHCP" is required for the bridge interface drop down to function and it's disabled in P2P mode (which, btw, makes sense, since only 2 peers are talking)

The only workaround is to select "Client-Server" mode rather than P2P mode, which allows you to choose "Allow clients on the bridge to obtain DHCP" but this isn't even behavior that I want. I shouldn't be required to send DHCP over the bridge, what if I want to statically assign IPs on the LAN on both sides?

Conclusion: "TAP server mode requires an IPv4/IPv6 Tunnel Network or Bridge Interface to work" is in and of itself contradictory, because TAP mode should not really use IPv4/6 tunnel networks, even according to Netgate docs! So basically, the upshot of this change is that bridging two site-to-site VPNs is not possible. I recognize it is "deprecated" or not recommended, but it should be possible.

Is this not possible in OpenVPN anymore?

Actions
Copy link
 #7

Updated by Marcos M almost 2 years ago

I shouldn't be required to send DHCP over the bridge

From what I understand, if no DHCP range is set, then there won't be DHCP. Hence, enable Bridge DHCP and leave the other options blank. The text could be clarified, though that would be a separate request.

Actions
Copy link
 #8

Updated by Yousif Hassan almost 2 years ago

Marcos M wrote in #note-7:

I shouldn't be required to send DHCP over the bridge

From what I understand, if no DHCP range is set, then there won't be DHCP. Hence, enable Bridge DHCP and leave the other options blank. The text could be clarified, though that would be a separate request.

Thank you for the response. That is indeed what I am going to try to do. However, the additional step that is going to be required is for me to change the VPN type from "Peer to Peer" into "Client/Server" so that the checkbox to "Allow clients on the bridge to obtain DHCP" is even selectable.

I find this to be an unnecessary step / change. After all, I don't want a client-side topology dictated by OpenVPN - I just want to bridge two LANs together. What would be the problem with allowing the previous behavior when the VPN server is set to "Peer to Peer" mode, and one wants to use bridging?

Thanks again for your attention. :)

Actions
Copy link

Also available in: Atom PDF