Alias use in OpenVPN - Broken on Reboots (and possibly other edge cases)
-
OK, is this something that has just started happening? After an upgrade etc?
-
I just setup the openVPN servers using aliases a few weeks ago. It's a fresh install and appears to have been acting this way since I setup the servers a few weeks ago.
-
Have you only seen this in 2.7.2?
Can't replicate it here in 24.11. There were quite a few commits into the alias system recently.
-
Correct, but I only have been using 2.7.2, so no idea if it is present in 24.11.
-
Hmm, which aliases are actually not populating there? Anything with nested aliases? Only those host aliases that have to be resolved?
-
host and network aliases are failing to populate (CIDR Notation for networks, and FQDN for hosts). It appears that the type of alias doesn't matter based on what I'm seeing.
-
@azeliff3 said in Alias use in OpenVPN - Broken on Reboots (and possibly other edge cases):
are used in OpenVPN configurations
Client ? Server ?
What happens when pfSense starts, and the OpenVPN server ? Client ?) start before the resolver starts ....
What is the state of the aliases at that moment ? Are the known with the 'IP addresses' known from before the reboot ? Or unknown, as they are getting used before they are resolved ...
IP (or network aliases should 'work' because their content is known right out of the box.
But you have also Host(s) and these have to get resolved first.A 'broken' solution : I don't know if process like OpenVPN can get delayed upon system boot, but I guess, with cron, you could setup a cron script that reboots the openvon process '300' seconds after reboot, as aliases hosts are typically resolved every 5 minutes.
Btw : when resolved, and the aliases content changed (for example : the IP addresses changed) I'm not sure if OpenVPN will be aware of that. It starts with its config files, and if these change, the process has to restart to take them in account. -
Your screenshot above shows it still has routes for those 10.x.x.x subnets which I assume are the network alias?
There's no need to obscure private subnets.
-
The configurations shown and in question are the server configurations.
I apologize for obscuring the private subnets. I've dealt with people panicking when they see any IP publicly posted in other venues, so I default to obscuring.
Here's a more detailed breakout of after reboot vs re-applying the settings:
It appears to match with what @Gertjan implied regarding resolution of host names, where they may not be resolved before the openVPN server starts on a fresh boot. Unfortunately, restarting the OpenVPN service (even after 5-6 minutes uptime) does not appear to get those resolved hostname aliases to show in the configuration. They only seem to show up when I re-apply the settings.
The fact that server configs get generated and skip over host aliases that are valid (but perhaps not resolved at that instant in time after a reboot) seems like a problem. Since restarting the openVPN service individually doesn't fix the missing aliases, it seems like there is a dependency in the service boot order on pfSense that was introduced when the use of aliases was allowed, which may not have been properly handled. Since all the host aliases are resolved and configured in pfSense, I feel like the resolution should be incredibly quick.
I'm not really sure where to go from here -- is this a bug with service startup dependencies?
I realize in my original post I mentioned CIDR aliases not showing up. I haven't been able to replicate what I had seen earlier for screenshots regarding CIDR, so I'm currently trying to recreate that.
-
Hmm, still can't replicate that here in Plus. The start order could well have changed since 2.7.2.
How are those aliases being resolved? If you add one as a host override locally does it make it into the conf. Though that doesn't work here with a near default setup
-
I'm not sure I am interpreting your question correctly, so if I am not answering your question, I apologize.
The aliases are pfSense firewall aliases. For instance, K12A_Devices is an alias for two hosts:
k12a-outlet.k12.benchpress.lan,k12a-bulb.k12.benchpress.lanThe host records referred to in the aliases are DHCP static mappings under pfSense DHCP server (for instance
k12a-outletis statically assigned a 192 address).I tried adding a host override for k12a-outlet, and it still did not make it into the configuration after reboot. It does show up after clicking "save" in the UI for the settings though (same behavior as static mappings).
-
Ok, that's the same thing I'm seeing. It can only resolve it against Unbound when static mappings are added and that is not running when the file is created in 2.7.2.
Also those are not added at boot but host overrides and other resolved hosts are.
I don't think that is a bug though since it has never worked AFAIK and was not expected to. It should be opened as a feature request though so:
https://redmine.pfsense.org/issues/15922 -
Thanks for opening the feature request and working through it! I appreciate it!
-
@azeliff3 said in Alias use in OpenVPN - Broken on Reboots (and possibly other edge cases):
Unfortunately, restarting the OpenVPN service (even after 5-6 minutes uptime) does not appear to get those resolved hostname aliases to show in the configuration
Restarting by clicking here :
does not recreate ".opvn" config file from the pfSense GUI settings.
It's more a "if a config file exist, start the openvpn binary".However, with some minimal scripting you can do what is done when you click here :
My problem is : I don't have 2.7.2. anymore ...
If you're not afraid of some PHP (re)searching, I can already tell you that all you need is in
/etc/inc/services.inc
/etc/inc/services-utils.inc
/etc/inc/openvpn.inc
/usr/local/www/vpn_openvpn_server.php (for reference)
I'll be assisting you.
