Skip to content
Display "Connecting" Message?
Got a problem with Viscosity or need help? Ask here!
We use out-of-band 2FA (push notifications) as part of our VPN authentication system and I was thinking it would be nice to display a simple "Please check your mobile device to complete login" message for some of our road-warrior contractors to remind them that they need to complete the auth cycle before the VPN will connect. Not a critical thing, but maybe a quality-of-life improvement? I thought it could look something like this in the .ovpn config:
Thanks!
Code: Select all
(I've been scouring the Knowledge Base and don't see that this feature exists, so please let me know if I've missed something!)#viscosity connecting-message "Please check your mobile device to complete login"
Thanks!
Hi beornlake,
Viscosity 1.11.1 (currently in beta) already has such an option available - you can more information about it at:
https://www.sparklabs.com/support/kb/ar ... cknowledge
Cheers,
James
Viscosity 1.11.1 (currently in beta) already has such an option available - you can more information about it at:
https://www.sparklabs.com/support/kb/ar ... cknowledge
Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Bluesky: https://bsky.app/profile/sparklabs.com
Support: https://www.sparklabs.com/support
Bluesky: https://bsky.app/profile/sparklabs.com
Thanks, James. Unfortunately, this isn't quite working for me... The prompt box does appear very briefly, but immediately closes before the push notification is sent out. We don't use the static-challenge-password command – could that have something to do with it?
Some implementation background that might help:
Our OpenVPN server does user cert + username/password authentication, with the username/password auth being provided by an LDAP server that itself is connected to the 2FA system. So when a user authenticates, the cert is checked by the OpenVPN server, then authentication is handed off to LDAP. The LDAP server checks username/password, then sends off a 2FA request and doesn't respond to OpenVPN until the push notification is accepted/rejected by the user (or the request times out).
Here's a "successful" connection log, and I inserted an extra line where the pause happens when the client is waiting for the server:
If the user rejects the 2FA prompt, this is what the log looks like:
Curiously, while testing these permutations, I managed to get Viscosity to crash, so I submitted a crash report for that with a brief description.
Some implementation background that might help:
Our OpenVPN server does user cert + username/password authentication, with the username/password auth being provided by an LDAP server that itself is connected to the 2FA system. So when a user authenticates, the cert is checked by the OpenVPN server, then authentication is handed off to LDAP. The LDAP server checks username/password, then sends off a 2FA request and doesn't respond to OpenVPN until the push notification is accepted/rejected by the user (or the request times out).
Here's a "successful" connection log, and I inserted an extra line where the pause happens when the client is waiting for the server:
Code: Select all
May 08 7:37:05 PM: State changed to Connecting
May 08 7:37:05 PM: Viscosity Windows 1.11.1b6 (1812)
May 08 7:37:06 PM: Running on Microsoft Windows 11 Pro 64 bit
May 08 7:37:06 PM: Running on .NET Framework Version 4.8.09032.533320
May 08 7:37:06 PM: Checking reachability status of connection...
May 08 7:37:06 PM: Connection is reachable. Starting connection attempt.
May 08 7:37:06 PM: Interface Type: ViscTunTap
May 08 7:37:06 PM: Bringing up interface...
May 08 7:37:06 PM: OpenVPN 2.6.10 Windows [SSL (OpenSSL)] [LZO] [LZ4] [AEAD]
May 08 7:37:06 PM: library versions: OpenSSL 3.0.13 30 Jan 2024, LZO 2.10
May 08 7:37:06 PM: Resolving address: "<REDACTED>"
May 08 7:37:06 PM: Valid endpoint found: <REDACTED>:1194:udp
May 08 7:37:07 PM: TCP/UDP: Preserving recently used remote address: [AF_INET]<REDACTED>:1194
May 08 7:37:07 PM: UDPv4 link local: (not bound)
May 08 7:37:07 PM: UDPv4 link remote: [AF_INET]<REDACTED>:1194
May 08 7:37:07 PM: State changed to Authenticating
May 08 7:37:07 PM: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
May 08 7:37:07 PM: [<REDACTED>] Peer Connection Initiated with [AF_INET]<REDACTED>:1194
May 08 7:37:07 PM: State changed to Connecting
<----- PAUSE HERE WHILE WAITING TO COMPLETE PUSH NOTIFICATION ----->
May 08 7:37:18 PM: Awaiting adapter to come up...
May 08 7:37:19 PM: TAP-WIN32 device [Company VPN] opened: \\?\root#net#0003#{adda4c48-c32e-4ef6-9602-b3252f082583}, index: 16
May 08 7:37:20 PM: Waiting for DNS Setup to complete...
May 08 7:37:20 PM: Successful ARP Flush on interface [16] {9626BBBD-E24F-4C9F-B735-366DD32E3048}
May 08 7:37:21 PM: Initialization Sequence Completed
May 08 7:37:21 PM: DNS set to Split, report follows:
Server: <REDACTED>:53, Lookup Type: Any, Domains: <REDACTED>.
Server: <REDACTED>:53, Lookup Type: Split, Domains: <REDACTED>.
May 08 7:37:21 PM: State changed to Connected
If the user rejects the 2FA prompt, this is what the log looks like:
Code: Select all
. . .
May 08 7:53:22 PM: [<REDACTED>] Peer Connection Initiated with [AF_INET]<REDACTED>:1194
May 08 7:53:22 PM: State changed to Connecting
<----- PAUSE HERE WHILE USER REJECTS 2FA PROMPT ON PHONE ----->
May 08 7:53:32 PM: AUTH: Received control message: AUTH_FAILED
May 08 7:53:34 PM: SIGUSR1[soft,auth-failure] received, process restarting
May 08 7:53:35 PM: Valid existing endpoint found... <REDACTED>:1194:udp
May 08 7:53:36 PM: State changed to Disconnecting (Username/Password Cancelled)
May 08 7:53:36 PM: ERROR: could not read Auth username/password/ok/string from management interface
May 08 7:53:36 PM: OpenVPN has exited. Exitcode = 1
May 08 7:53:36 PM: State changed to Disconnected
Curiously, while testing these permutations, I managed to get Viscosity to crash, so I submitted a crash report for that with a brief description.
Thanks for the report. I believe this was fixed in the full 1.11.1 release in response to your crash report - but if you still encounter any issues please let us know.
Cheers,
James
Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Bluesky: https://bsky.app/profile/sparklabs.com
Support: https://www.sparklabs.com/support
Bluesky: https://bsky.app/profile/sparklabs.com
Fri May 10, 2024 4:19 amJames wrote: Thanks for the report. I believe this was fixed in the full 1.1.1 release in response to your crash report - but if you still encounter any issues please let us know.Updated to 1.11.1 (1814) this morning, but still have the issue where the prompt immediately disappears before the 2FA auth happens. Seems to be related to a difference in the way Viscosity handles the "Connecting" vs "Authenticating" phases of login?
Hi,
I have moved this topic to the Viscosity Windows support section, as it's a better fit for troubleshooting. If you're seeing this behaviour with the latest release version (1.11.1) please email us a copy of the items in the following link and we will see what is going on:
https://www.sparklabs.com/support/kb/ar ... ort-staff/
The Windows version should display the alert when the connection enters the Authentication state, and close it when the connection connects/disconnects (entering a Connecting state afterwards should not close the alert). It's possible there may be an edge case that needs to be handled for some setups, in which case the above log should allow us to add a fix.
Regards,
Aaron
I have moved this topic to the Viscosity Windows support section, as it's a better fit for troubleshooting. If you're seeing this behaviour with the latest release version (1.11.1) please email us a copy of the items in the following link and we will see what is going on:
https://www.sparklabs.com/support/kb/ar ... ort-staff/
The Windows version should display the alert when the connection enters the Authentication state, and close it when the connection connects/disconnects (entering a Connecting state afterwards should not close the alert). It's possible there may be an edge case that needs to be handled for some setups, in which case the above log should allow us to add a fix.
Regards,
Aaron
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Hi,
Thank you for emailing those details though. We have updated the latest beta version (1.11.2b1) to change the behaviour. Please give it a test and please let us know if you see the same problem.
https://www.sparklabs.com/support/kb/ar ... -versions/
Regards,
Aaron
Thank you for emailing those details though. We have updated the latest beta version (1.11.2b1) to change the behaviour. Please give it a test and please let us know if you see the same problem.
https://www.sparklabs.com/support/kb/ar ... -versions/
Regards,
Aaron
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
9 posts
Page 1 of 1