Project

General

Profile

Actions

Feature #10633

closed

Add one a new "Server Mode" to the OpenVPN server configuration page or add the missing settings to an existing mode.

Added by alzee bum almost 4 years ago. Updated almost 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
OpenVPN
Target version:
-
Start date:
06/04/2020
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:

Description

"Server Mode" is a pfSense invention that determines what settings to expose in the GUI. The issue we're currently having is that there is no mode that allows for all of the following simultaneously:
- TLS + User authentication
- Pushing additional DNS settings to clients
- Routing traffic to client IP networks

This is because no "Peer to Peer" mode exposes the "Advanced Client Settings" or allows for user auth, while no "Remote Access" mode exposes the "IPvX Remote Network(s)" settings block.

Here are some possible options to address this:

1. Add the "IPv4 Remote Network(s)" and "IPv6 Remote Netowrk(s)" settings to all of the existing "Remote Access" mode pages. This is probably the simplest fix that directly addresses this particular problem, but it doesn't handle potential future issues that may arise from these arbitrarily defined "server modes."

2. Create a new "Peer to Peer" mode that allows for "user auth" authentication and also exposes the "Advanced Client Settings" configuration block that is available in the "Remote Access" modes. More to change here, and a new mode further muddying the issue make this a less desirable option.

3. Create a new mode that is neither "Remote Access" or "Peer to Peer" but is simply "Advanced" or "Native" or some other word that exposes all of the various OpenVPN server knobs available. This is the most desirable option since it is future proof and has no arbitrary restrictions placed on how a server can be configured, but it also is likely the most work to implement.

Actions #1

Updated by Jim Pingle almost 4 years ago

  • Status changed from New to Rejected

We've considered that before and rejected it for a few reasons:

1. You shouldn't be mixing purposes like that (peer to peer and remote access style)
2. Anything you can't do in the exposed GUI fields can be added as custom options easily (like route statements) for those who choose to ignore item 1.

Actions #2

Updated by alzee bum almost 4 years ago

Jim Pingle wrote:

We've considered that before and rejected it for a few reasons:

1. You shouldn't be mixing purposes like that (peer to peer and remote access style)

Says whom? OpenVPN supports and documents examples of exactly this use case: https://community.openvpn.net/openvpn/wiki/RoutedLans . It's not uncommon or otherwise considered a bad practice. What we're trying to do works perfectly in OpenVPN without pfSense getting in the way, and this is exactly what VPNs are for. Other networking products supporting e.g. IPSec also support configurations exactly like this.

2. Anything you can't do in the exposed GUI fields can be added as custom options easily (like route statements) for those who choose to ignore item 1.

Is this a joke? By this logic you should just get rid of pfSense's GUI entirely and just replace it with a bunch of boxes to paste in "custom options" for everything. Job done and you'll never have to update the GUI again no matter what any users or even paying customers want.

Actions

Also available in: Atom PDF