openvpn: CSO support for previously used freeform custom settings
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.
Custom options are no longer available which requires us to add new fields which can be validated properly.
Describe the solution you like
Add requested fields:
- ~
sndbuf 524288~ (increase system values if this is required, documentation isn't very enthusiastic about this) - ~
rcvbuf 524288~ (increase system values if this is required, documentation isn't very enthusiastic about this) push "sndbuf 524288"push "rcvbuf 524288"
Fields done:
route-gateway
Describe alternatives you considered
File based overrides for CSOs are not very elegant and a nightmare to handle for the user.
Additional context
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ https://forum.opnsense.org/index.php?topic=35149.0
As referred to #6801, necessity to push route-gateway 'gateway IP'.
Hello Sorry, I just wanted to know if it will be considered to be able to put the route-gateway option back in again. Unfortunately, I cannot upgrade from 23.1 to 23.7 as the CSO is also modified for those using the legacy part of openVPN.
@smeretech by default --route-gateway is set with the --server keyword (see https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/), if for specific cases this doesn't work, it might be good to offer some context on when this is. I don't have a strong feeling about leaving it out or adding it, but am interested to know the context before adding new options.
Thanks for your reply. the context in which I use it is to deliver a single OpenVPN instance/server on multi projects that need to be separated. In my specific case, the server adopts a /16 internal network. Through CSOs, I would assign different sub-networks of this /16 to each workgroup of users but the only way to set a gateway to clients that falls within this sub-network was to use route-gateway. Otherwise, OpenVPN assigns the first IP of the /16 as the gateway for a client session resulting in the error of not being able to reach it.
example: Tunnel network: 10.50.0.0/16
Group1 (CSO) IPv4 Tunnel Network: 10.50.0.0/28 (gateway 10.50.0.14) Group2 (CSO) IPv4 Tunnel Network: 10.50.0.16/28 (gateway 10.50.0.30) Group3 (CSO) IPv4 Tunnel Network: 10.50.0.32/27 (gateway 10.50.0.62)
@smeretech sounds reasonable, should be fixed with https://github.com/opnsense/core/commit/54ebcb00c6cac006e51f6f59dd2f4b476fe6bf60
thank you. in the migration processes from 23.1 to 23.7, will the system automatically take into account what I had in the advanced fields to date and refer precisely to route-gateway? In any case, I will wait until the next patch day to give it a try.
No, advanced fields have been deprecated without a migration (we added the note https://github.com/opnsense/core/commit/d62015df1cdb0c0711b488bd66ced631b9a4f37b 4 years ago to offer people the time to seek alternatives like opening tickets and explaining why features would be needed).
ok. to recap, during the upgrade to 23.7, the system will keep all CSOs and current network configurations (including "Local Networks" Subnets/hosts) but will not consider what we had within the Advanced field at all.
So, with the patch you just implemented, I will have to manually configure gateways for each CSO post upgrade.
In case, I could set one up and export the config file and then manually do the gateway addition for each CSOs and import the config file again. I hope it works.
yes
hello. only for your info, with 23.7.4 appears the same title name for both the settings
@smeretech thanks, should be fixed in https://github.com/opnsense/core/commit/9fb7c048d7077c65fa593581f458da27c2623672
I'm retiring this ticket since there was no further feedback in the last half a year.