bug report ovpn3\OpenVPN Connect .json

S1lent

Hi community. My OS - Win10 Pro, 22H2, 19045.6456.
My client version of OpenVPN Connect - 3.8.0 (4528)
I found an interesting bug that doesn't seem to have been reported yet—correct me if I'm wrong.
When I add a config file containing multiple remote entries to the OpenVPN Connect client, everything works as expected. However, if I access the profile via the GUI and change even a single setting, the multiple remote entries stop working; the profile breaks. This happens because ovpn3 rewrites my configuration file into its own .json format and corrupts it. For multiple remote entries to function, the "selectedServer": { "server": null } setting is critical; as long as the value remains null, everything works fine. But when saving the profile, ovpn3 replaces that null value with the first server listed in selectedServer. Consequently, config.json gets updated to "selectedServer": { "server": "your first server" }. It doesn't matter what specific setting you change in the GUI—clicking "Save Changes" causes the "selectedServer": { "server": null } line to be overwritten. The workaround found so far is simply not to edit the imported profile via the GUI.

*Just an update: I tried solving the issue by setting the config.json file to read-only. I expected everything to work normally, but Java is throwing errors about being unable to overwrite data whenever I perform any action. That’s likely the intended behavior.

JosephS

Hi S1lent ,

To an extent the issue with multiple remote entries and them not failing over has been discussed in this thread:

https://forums.openvpn.net/d/46603-ovpnc-intermittently-fails-to-advance-to-second-remote-entry-after-wan-failure

But it seems you may have found the root cause itself, I'll escalate your detailed findings to the dev team regarding values being corrupted in the config.json file.

Thank you,
JosephS

Mohammad Montazeri

Two things that would probably make this easier for the dev team to act on, if S1lent can still reproduce it:

Does the same corruption happen when the endpoints are written as <connection> blocks instead of repeated remote lines? If connection blocks survive a GUI save, that narrows it to how the remote list is re-serialised rather than to the selectedServer write itself.
After a GUI save has set "selectedServer": { "server": "<first remote>" }, does the stored profile body still contain all of the original remote entries? If it does, this isn't really a corrupted profile - it's a pinned server selection overriding failover, which is a much smaller fix and also explains why clearing the value back to null restores normal behaviour.

On the read-only config.json attempt: that one is a dead end rather than a workaround. OpenVPN Connect keeps mutable client state in that file, so the Java write errors are expected once it can't be updated, and you risk other state not persisting. I'd set it back to writable.

Practical stopgap until it's fixed: import the profile and don't open its settings at all. If something needs changing, edit the .ovpn in a text editor and re-import it as a new profile rather than editing through the GUI. Splitting the remotes into separate profiles also avoids the rewrite, but you lose the automatic failover that was the point of having multiple entries.