Oddity with Viscosity/OpenVPN
Cyber-Wizard last edited by
I realize this is more of a Viscosity issue but I'd like to pose it here as it impacts the pfSense OpenVPN implementation in a way that I wouldn't expect.
I have a customer that has been running OpenVPN on a virtualized pfSense instance for many years virtually issue free.
At the moment they're running 2.3.4p1 in a 64-bit instance on a 100Mbps fiber line. Most of their users use the OpenVPN client on their home computers for RDP sessions to their in-office desktops. The company has purchased copies of Viscosity to give out to a handful of OSX users.
pfSense is paired with Duo for two-factor authentication and there is a local Duo proxy running that pulls authentication from Active Directory before handing the result off to Duo.
If the Viscosity user gets disconnected for any reason, Viscosity attempts to reconnect automatically. It is actually set not to reconnect automatically but that's an issue I can approach SparkLabs about later.
My issue is that when Viscosity does it's 10 re-connection attempts once per minute, any other users who are already connected to OpenVPN are disconnected and cannot reconnect until that Viscosity client abandons it's attempt to reconnect. Running through the 10 connections of course involves the user missing or ignoring the Duo notifications on their mobile but the disconnects generally happen within the first 2 re-connection attempts. We have disabled client-side caching on Windows clients so auto-reconnecting is only an issue with Viscosity clients.
I've confirmed this issue in testing with Viscosity v1.7.3 and 1.7.4.
While I agree that this is not entirely pfSense or OpenVPN issue, I believe that the fact that the Viscosity client is able to do something to disconnect other users simply via an automated reconnect is a little concerning.
Has anyone else experienced a single client being able to seemingly swamp OpenVPN like this?
I haven't heard of that happening before, it shouldn't be able to kick anyone else off though.
Everyone has their own unique (not shared) certificates? Or is this auth only?
What shows up in the OpenVPN status, and in the log file, when this happens?
Cyber-Wizard last edited by
It's definitely pretty weird.
I found some references on the Viscosity support forums to disabling reconnects in the advanced config. It's not a solution but it should be the next best thing. Interestingly enough I installed a copy of Viscosity on a Windows client today and couldn't reproduce the problem. This business of it auto-reconnecting, even though the auto-reconnect setting is disabled, seems to be expressly an issue with the Mac client.
They're using cert and auth. There is a common cert for all users. Auth is done via the Duo proxy lookup using RADIUS. RADIUS server checks AD for creds and then pushes out to Duo for Two-Factor.
When issue occurs a log entry shows up for each of the 10 reconnection attempts as follows:
Sep 8 15:19:44 openvpn: username/XXX.XXX.XX.XXX:1194 TLS Error: Unroutable control packet received from [AF_INET]XXX.XXX.XX.XXX:1194 (si=3 op=P_CONTROL_V1)
This seems to be a pretty generic error.
If you're watching the OpenVPN status when the issue occurs all connected users simply disappear. We don't permit cached creds so their reconnect attempts have to be manual and are fruitless as long as the Mac client is still going through it's reconnect cycle.
I've set OpenVPN to use debug level logging and am pushing those logs out to Splunk in the hopes of getting more information.
During testing I set up a Mac client on my bench and after forcing a disconnect from the OpenVPN status screen I can readily duplicate the issue. Once the Mac exhausts it's 10 reconnection attempts, both the Mac user and other users are able to reconnect without issue. Even with only 4 or 5 Mac users this is causing quite a bit of havoc.
I can live with perhaps needing to find a workaround for Viscosity but it creeps me out that this impacts the OpenVPN service so dramatically.
Pippin last edited by
but it creeps me out that this impacts the OpenVPN service so dramatically.
Not a solution but with regards to OpenVPN "locking up", it is known it happens during the authentication. Normally this goes unnoticed.
There is a way around it, maybe it can be applied/integrated to pfSense…