OpenVPN > Server > Advanced Configuration. Field gets rearranged on save. Bug?

scurrier

First off, a huge thank you to the developers and community of pfSense. I am loving this software and it is performing well for me.

I may have found a bug. I record this here for posterity and for your feedback on if I should submit a bug report to the pfSense bugbase on redmine.

Basically, I have entered an advanced config for an OpenVPN server which is in legal OpenVPN syntax. PFS first takes the advanced config, but then upon re-opening the server edit page, accidentally modifies it when displaying it again, which then becomes a bad config that can be saved and which will prevent OVPN server initialization.

Here's how I reproduce it.
On an OpenVPN server edit page such as this…
https:// <ip removed="">/vpn_openvpn_server.php?act=edit&id=0
...I will enter the "desired text" shown in the code block below to the "advanced configuration" section. Then, I save the server edit page. At this point, the OpenVPN server will initialize correctly. But, the next time that the server edit page is opened, the text will come up as the "resulting text" shown in the second code block below. At this point, if you save the server edit page again, you will get no immediate error messages, but the OpenVPN server will not initialize and the logged error shown below will appear in the log.

My desired text:

 <tls-auth>#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
 <key removed="">-----END OpenVPN Static key V1-----</key></tls-auth> ;
key-direction 0;

Resulting text:

<tls-auth>#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
 <key removed="">-----END OpenVPN Static key V1-----</key></tls-auth>;
key-direction 0;

Logged error on second save of server edit page:

openvpn[67486]: Options error: Unrecognized option or missing parameter(s) in /var/etc/openvpn/server1.conf:35: <tls-auth># (2.3.2)</tls-auth>
```</ip>

scurrier

I should add that I worked around this issue by using the tls auth feature that is expressly built into the edit page and then adding the key-direction directive in the advanced section alone like:

key-direction 0;

So perhaps my specific case is a trivial one. But, it should be possible to do these "inline keys" (and possibly other inline features that I don't know about) and we'd want the handling of that text to be correct. At the very least, the behavior I've described is unexpected and may cause someone to think their configuration is wrong when it's not. (Hopefully they would check the logs as their first debugging step, though, like I did.)