Bug after replacing VPN provider ?

[Koent]

Hello,

Could it be there is a bug in the VPN Client ?

I’m evaluating VPN providers so I do a lot of adding, changing and deleting clients, interfaces and gateways.

What I did :

I had three clients to provider A
I added three clients to provider B
I had to reboot once during the process.
I created two new interfaces to to connect the clients and renamed and changed the interface on one client, added NAT rules and gateways etc
I verified and everything worked.
I deleted the old clients, interfaces gateways, NAT-rules etc

After half an hour I tried to tune some of the settings of the clients. All clients are now a mix of settings from provider A and provider B. Provider B doesn’t use TLs but I see the TLs certificates from provider A. Both available and allowed NCP algorithms are empty.  I tried to cleanup the settings but it is not possible to save them. All the time, the firewalled continued to function normally.  I tried to restart the clients but this didn’t solve the problem, although after restarting the TLs settings from the old provider were gone. It was still impossible to save a client after selecting algorithms in the available NCP algorithms section.

I rebooted the server after deleting all clients, interfaces, rules etc and recreated everything. All problems are gone now.

It is the second time that I experienced this. First time was on 2.4 RC, this time in 2.4.

[sgorbach]

I also have an upgraded pfSense install that after getting 2.4 has an empty NCP Algorithms list on OpenVPN Client settings. The openvpn service won't come up for that connection. There are no custom configurations set on the client.

No luck after deleting the openvpn client and rebooting. Can't try deleting all the interfaces and rules as described on the OP right now.

In case it helps, it's a VM running on an "older" cpu that doesn't support aes-ni.

I'm going through the logs now to see if anything relevant comes up.

[Koent]

I replicated the situation by doing exactly the same and the issue appears again.
I selected all AES-256 variations in available protocols. The ones that are needed show up as null.
(See screenshot).  After this, it is impossible to edit an existing client or create a new client.

This time, a reboot didn’t fix the issue. A restore was needed.

[Koent]

Following error message is generated when NCP is disabled and I try to save.
When NCP is enabled and the null algorithms are selected, it creates a line for each null interface.

[sgorbach]

I've had three different outcomes after upgrading some pfsense installs to v2.4 regarding OpenVPN, most of the settings were pretty much the same (openvpn over udp-ipv4, tun, aes-256-cbc, sha1); results in order from best to worst:

1. The tunnel kept working as before, only on the tunnels where the upgrade was done at the same time on both ends. Configuration was changed automatically from aes-256-cbc to aes-256-gcm+aes-128-gcm by the upgrade process (even theoretically downgrading security by adding a 128bit key option where only a 256bit key was being used, which while not horrible is still worrisome) and had to be manually fixed.

2. The tunnel was broken, mostly when one of the sites was unable to be upgraded (either risky because of no chance restoring at that time, because one site was on x86 and cannot be upgraded to 2.4 or because the endpoints don't use pfsense). The issue is probably caused by the unexpected modification to the configuration the upgrade brought to the openvpn server/client (i.e.: changing from aes-256-cbc only to aes-256-gsm+aes-128-gsm on the upgrade, with no intention to do so).

3. The upgrade broke something as described on the posts above, can't list NCP algorithms, can't save any changes to the openvpn client/server configuration at all and had to be restored quickly, in this case without much time to play log-hunting (will investigate further if time allows).

So, based on my experience so far (limited to upgrading ~10 installs of pfsense) I'd recommend to people using openvpn over pfsense either as client or server who plan on upgrading to v2.4 soon to wait until this issues have been sorted out.

[jimp]

@sgorbach:

1. The tunnel kept working as before, only on the tunnels where the upgrade was done at the same time on both ends. Configuration was changed automatically from aes-256-cbc to aes-256-gcm+aes-128-gcm by the upgrade process (even theoretically downgrading security by adding a 128bit key option where only a 256bit key was being used, which while not horrible is still worrisome) and had to be manually fixed.

OpenVPN changed their defaults in 2.4 to enable NCP. In all of our testing, backward compatibility worked fine. If you had a specific crypto algo selected, OpenVPN treated it as if it was part of the NCP list internally, and a peer could connect using that or any other NCP algorithm in the list.

It will always select the best algorithm in the list, so with both AES-GCM 128 and 256 selected, it will always pick 256. Given the usefulness of NCP and the sanity of the way OpenVPN handles it, we left it enabled by default on upgrade. If you don't want it, just uncheck "Enable Negotiable Cryptographic Parameters" on the server or client instance.

@sgorbach:

2. The tunnel was broken, mostly when one of the sites was unable to be upgraded (either risky because of no chance restoring at that time, because one site was on x86 and cannot be upgraded to 2.4 or because the endpoints don't use pfsense). The issue is probably caused by the unexpected modification to the configuration the upgrade brought to the openvpn server/client (i.e.: changing from aes-256-cbc only to aes-256-gsm+aes-128-gsm on the upgrade, with no intention to do so).

Unlikely. See above. I'd like some more information about what happened, logs, etc. But it was almost certainly not from NCP being enabled. OpenVPN was very careful and deliberate with its implementation.

@sgorbach:

3. The upgrade broke something as described on the posts above, can't list NCP algorithms, can't save any changes to the openvpn client/server configuration at all and had to be restored quickly, in this case without much time to play log-hunting (will investigate further if time allows).

From the screenshots above there is definitely something odd there. None of the browsers I have on hand show the control looking like that, though. I'd like to know what OS and Browser that is, since it's likely something related to how it handles that control. It definitely should not have 'null' in the list anywhere though.

If that came up after a save, please also go to Diagnostics > Backup/Restore on the Config History tab and do a diff between the last couple configuration changes to see what the config.xml looks like for the NCP list. If I can get a copy of the broken config.xml line(s) for NCP that behave this way it should be easy for us to reproduce and fix. It normally looks like this, and emptying the right-hand side is not how you disable it, it is disabled by unchecking the box just above the list.

[Koent]

The browser was Safari on iOS 11.03. However, I did the original configuration in Firefox and I saw the errors first in Firefox. The iPad was simply used to type the message and take the screenshots.

I try to make time tomorrow to replicate the problem, send you the required XML’s  and take screenshots in Firefox.

I had no problems after the upgrade from 2.4rc to 2.4.  I tested several VPN-providers in 2.4c and I experienced this problem and when replacing providers in 2.4, the problem occurred again.

Thanks for your quick reaction and for taking this seriously (from a newbie).

[jimp]

While you're at it, please also list the exact steps you took, the exact set of inputs, and what exactly appears in each box along the way.

I have tried a few different variations of saving with the control in various states and I can't seem to break it, so the info here doesn't appear to be enough on its own.

[jimp]

@Georget27:

Quick note : I work for a network integrator who obviously sells a lot of WiFi. I’m very busy at the moment so it will be something for tomorrow or even Wednesday.

Or even longer once this WPA2 flaw info gets more publicity. My condolences. :-)

@Georget27:

Can I take a video of the screen, and send you a wetransfer link in PM please ?

A video is probably overkill, let's start with a listing of the settings and steps.

[Koent]

It’s complicated. I tried to replicate the problem and succeeded two times, only to see that when I replay the actions after a full reinstall without restore, the problem disappeared.

My impression is that the problem occurs when one replaces a VPN provider that uses TLS (NordVPN), add a new provider that doesn’t use TLS and then replace the client in the interfaces. When I deleted the interfaces first, save and then recreated the interfaces I never had troubles. I’ve spend more than 12 hours now on trying to create a decent and easy to replicate big report but it is complicated. I’ll have  more time in a couple of weeks and I will do a follow up then.