opnsense
OpenVPN: Add More Advanced Options to Instances
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
- [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
- [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue
Is your feature request related to a problem? Please describe.
My VPN provider uses a few advanced options that with Instances I am unable to use. These include:
auth-nocache
remote-cert-tls server ## Getting warnings in my log because I don't have this ##
nobind
resolv-retry infinite
explicit-exit-notify 5
push-peer-info
comp-lzo no
data-ciphers CHACHA20-POLY1305:AES-256-GCM:AES-256-CBC:AES-192-GCM:AES-192-CBC:AES-128-GCM:AES-128-CBC
data-ciphers-fallback AES-256-CBC
I would also include:
mlock
mute-replay-warnings ## Too many AEAD Decrypt error: bad packet ID (may be a replay) in my log ##
replay-window 128 ## Might fix the AEAD errors ##
Describe the solution you like
Would just like the ability to use these advanced options but since they have been removed in Instances I cannot.
Describe alternatives you considered
I can add these options to the .conf files in /var/etc/openvpn but they will be removed if I ever make changes in the WebGUI.
Additional context
Options have better change of getting including when explaining why they should be in there (which problem their aimed to solve). We have seen quite some options that have very little value or sometimes just do not reach their set goals under FreeBSD. Some of the mentioned options are already available under advanced by the way...
These three options I would consider the most useful:
auth-nocache - Don't cache --askpass or --auth-user-pass username/passwords in virtual memory.
remote-cert-tls server - WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Is the warning I'm getting in my logs, should be self-explanatory.
mlock - Using this option ensures that key material and tunnel data are never written to disk due to virtual memory paging operations which occur under most modern operating systems.
I didn't notice before but I guess the mssfix and tun-mtu options are there so I need to play around with those to get rid of the AEAD errors. Although the mute-replay-warnings would be nice because it's taking up 100+ pages of logs.
I suppose the following are redundant:
nobind
resolv-retry infinite
explicit-exit-notify 5
push-peer-info
comp-lzo no
data-ciphers CHACHA20-POLY1305:AES-256-GCM:AES-256-CBC:AES-192-GCM:AES-192-CBC:AES-128-GCM:AES-128-CBC
data-ciphers-fallback AES-256-CBC
How long is the legacy client going to be supported?
How long is the legacy client going to be supported?
There are no plans for a sudden removal, but there is a feature freeze (which also means if openvpn changes cause the old one to stop working, we can't guarantee much time being spend from our end).
auth-nocache only makes sense from the client's end, which is rather useless if passwords are already stored on the firewall itself. Best check earlier tickets about the new instances as well, quite some questions already have been answered in the past about which options do or don't make sense to add...
We had also several of above options in our optimized server side configuration so far;
Checking out seems that newer OpenVPN servers only use the dataciphers I want, so there is e.g. no actual need for this options but maybe again in future.
We use the resolv-retry infinite but in client and not server
The explicit-exit-notify parameter is in pfSense given in "Exit Notify": "Disabled / Reconnect try once/twice" and is a very useful functionality which should be implemented also in new OpenVPN interface as hopely already Dynamic Client from legacy servers is done?.
Additionally I found in a security setup blog article 2 years ago especially maybe this senseful parameter:
tls-version-min 1.3
maybe still to be combined with:
tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
ncp-ciphers AES-256-GCM:AES-192-GCM:AES-128-GCM
Finally as in https://github.com/opnsense/core/issues/7287 with "This is not how it's supposed to work" wrongly blocked the possibility to give "static IP blocks" within the OpenVPN range easily by setting right tunnel parameter IP/mask.
The tunnel network parameter works as expected from writer but has the problem that the IP address would be maybe assigned previous to a wrong user so we had to reserve ranges for static IPs like: e.g.:
server 10.30.7.0 255.255.255.0 nopool
ifconfig-pool 10.30.7.20 10.30.7.200
which should be not too difficult to implement; we need only the "nopool" attached and the optional line by checkbox with start and end IP addresses.
The tunnel network parameter works as expected from writer but has the problem that the IP address would be maybe assigned previous to a wrong user so we had to reserve ranges for static IPs like
@Reiner030 It probably would also make sense to allow ifconfig-pool-persist for the pool to survive reboot during firmware updates.
auth-nocache prevents passwords from being cached in the clients memory, combinded with auth-gen-token on the server side, this is a good/secure combination
explicit-exit-notify client/server inform each other, about restarts, so a reconnect can be startet faster
resolv-retry infinite as far as I understand, this is anyway the default, if it is not set, so could be omitted
Another one that'd be good to have for servers is ifconfig:
--ifconfig l rn
Set TUN/TAP adapter parameters. l is the IP address of the local VPN endpoint. For TUN devices in point-to-point mode, rn is the IP address of the remote VPN endpoint. For TAP devices, or TUN devices used with --topology subnet, rn is the subnet mask of the virtual network segment which is being created or connected to.
In my case, $vpnNet.1 is already in use.
This should only need a new "local VPN IP" field added and then manual expansion of the server flag if an IP was specified.
I plan to look at this myself when I've got the time, as that's the main thing preventing me from moving my openvpn instances to opnsense.
This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.
