OpenVPN Custom Configurations are getting mangled.

Been seeing this intermittently, but yesterday and today has occurred so often that I'm now sure it's not my imagination and is now occurring with enough frequency it's getting difficult to keep my VPN links up and running as well as time I have to spend re-checking the VPN configurations every time something stops working. So throwing this out to see if anyone has ideas as to what is going on here.

The problem that is occurring is that with multiple OpenVPN client links, the custom option configurations are intermittently not saving, or more so, getting mangled.

Either the changes to the configuration are not saved, even though gui suggest it has, or two of the configuration lines in the custom options section are merged into one line. The former of which results in configuration changed needed to be re-applied when it's discovered that the intended change is no longer present in the configuration, the later actually causes the VPN link to fail to start due to configuration syntax problems.

An example of the config mangling are two config lines:

pull-filter ignore "redirect-gateway"
route-delay 3

When the problem occurs become:

pull-filter ignore "redirect-gateway"route-delay 3

There is never any space between the end of the first directive and the start of the second directive, and so far does not seem to be specific to a given combination of directives.

So far, after frequent re-occurrences of this problem, I've noted the following:

A formerly working configuration is no longer working as configured due to merging two config directives into a single line.
A change to a configuration seems to not get applied; configuration has to be re-edited and re-saved.
Problem can occur when saving a configuration change, and re-opening to configuration to verify it,
or after a reboot with what a appears to be a fully functioning configuration, all VPN links up and running before the reboot and failing after the reboot.
The problems seem to only occur in the 2nd and 4th (out of 4) VPN clients, not sure about the 3rd, but definitely has not occurred with the first clients configuration, always in the 2+ clients.
Does not seem to be related the the specific configuration directives. Have seen it occur with various configuration lines.
The line merge thing seems to occur with the last two lines of the custom options, though not entirely positive about this.

I'm assuming that the line merging may have something to do with white space scrubbing, but it does not explain why a working configuration is suddenly broken after a just a reboot.
As for the not saving or reverting to a previous configuration, this isn't just a couple lines merging, the entire block of custom options can be re-arranged and the next time that client is edited, it's back to the previous incarnation, as if the configuration update was never saved.

In either case it has led to a lot of fussing around and re-checking & re-saving configurations to try and get links up and running, and just when all appears to be working, rebooting and the links are in various states of broken until the configurations are re-edited and re-saved, again.

Derelict

Try separating directives with semicolons.


pull-filter ignore "redirect-gateway";
route-delay 3

@Derelict:

Try separating directives with semicolons.
pull-filter ignore "redirect-gateway";
route-delay 3

Hadn't thought of that yet. Will definitely give it a try. Thank you.

I will note though these are not the only config directives in my custom options, the full set varies from 5 to 20 lines, and it's only the last couple of lines of any given custom options block that seem to get merged. And on that thought I will have to pay attention to the number of lines in a config and see if that correlates to the problem as well.

maverick_slo

@TechyTech:

@Derelict:
Try separating directives with semicolons.
pull-filter ignore "redirect-gateway";
route-delay 3
Hadn't thought of that yet. Will definitely give it a try. Thank you.

I will note though these are not the only config directives in my custom options, the full set varies from 5 to 20 lines, and it's only the last couple of lines of any given custom options block that seem to get merged. And on that thought I will have to pay attention to the number of lines in a config and see if that correlates to the problem as well.

Semicolons IS A MUST.
No bug here just misconfiguration
I run 150 ccd based clients sooo

jimp

Semicolons are always required for multiple lines.

Sometimes it works without them by chance. Different operating systems and browsers send newlines in different ways, however, so semicolons are the most reliable way to ensure the lines are broken properly in this case.

Doh, looked right past what was staring me in the face. :o

But it seems that this over-site is what flushed out the configuration saving problem.

Now that I've liberally sprinkled semicolons everywhere, I have been able to confirm that there is still some intermittent strangeness occurring when saving OpenVPN client configurations; specifically, the active running configuration gets updated, but the configuration database is not updated with the changes and is not isolated to the custom options section as it occurred with a couple of other gui checkbox settings as well.

So far here's what I been able to confirm:

Make a change to an OpenVPN client configuration and save that configuration.
Wait for client link and any restarted services to recover and link to stabalize.
Re-open client configuration edit pane.

At this point the client configuration will show the old configuration prior to being edited and saved.

Then to verify what state the current running OpenVPN configuration is at, go to ssh and login into firewall and open the active OpenVPN configuration file for the specific client (ie /var/etc/openvpn/client1.conf).

The configuration file will have the new saved changes active and running.

In order to eliminate any gui and browser cache issue at this workstation, go to a complete different computer, open a fresh browser window, login to pfSense and open the configuration editor for the specific OpenVPN client.

On this other computer the gui also shows the previous un-edited version of the configuration.

Go back and re-list the active OpenVPN configuration file to be sure nothing has changed and it still shows that new configuration settings.

Re-edit and re-save the configuration again, and repeat above, and now the new configuration settings are saved and appear in both the edit gui and the active configuration.

So, behavior also explains why configurations are breaking after a reboot; In the case where missing semicolons resulted in a broken configuration, editing to fix that results in the active config file being updated, and the link now working, but after reboot and the config file get's regenerated again from the old broken configuration because the change did not get updated to the configuration database.

I have not notice a cause as to when things don't get saved correctly other than using the procedure as describe above to note when it doesn't get saved in the gui, but isolated that the configuration change is being acted on, thus confirming that configuration changes are being generated to the active running configuration, but not being saved to the stored configuration database.