sslvpn stuck on "waiting for connection"

Hello,
Time to time clients (version 12.5.2) stuck on "waiting for connection" message. OS is Windows 10. Sometimes working ok. Any ideas, how it can be fixed ?

Comments

  • Without logs to help - no idea.
    Make sure that your firewall is not at max SSLVPN user sessions when this happens.

    Consider opening a support incident to get WG help in resolving this.

    You can turn on diagnostic logging for SSLVPN which may show something to help:
    In WSM Policy Manager: Setup -> Logging -> Diagnostic Log Level -> VPN -> SSL
    In the Web UI: System -> Diagnostic Log
    Set the slider to Information or higher

  • OK. Where I can see the logs then ?

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @indrek
    You'll need to set the logging levels like Bruce mentioned above, they'll appear in traffic monitor (try searching for "sslvpn" in it.)

    There are also logs on the client, if you right click the client icon in the system tray and go to view logs.

    Opening a support case will allow a technician to look at the logs and assist more quickly than here. If you do post logs here, please ensure that anything personally identifiable (like IP addresses, names, etc) are removed.

    -James Carson
    WatchGuard Customer Support

  • You can post private IP addrs/subnets - posting those incurs no security risk

  • In fact, we already opened the case, but no real solution so far. I'm just curious, are we the only one in the world with such problem.
    I turned on logging and what I see for this user:
    2020-03-04 09:13:48 FW1 sslvpn Mobile VPN with SSL user user@company logged in. Virtual IP address is 0.0.0.0. Real IP address is x.y.z.113. msg_id="2500-0000" Debug
    2020-03-04 09:13:48 FW2 admd Authentication of SSLVPN user user@company from x.y.z.113 was accepted msg_id="1100-0004" Event
    2020-03-04 09:13:48 FW2 sslvpn Mobile VPN with SSL user user@company logged in. Virtual IP address is 0.0.0.0. Real IP address is x.y.z.113. msg_id="2500-0000" Debug

  • The issue is: Virtual IP address is 0.0.0.0
    However, I don't know the cause of this.
    On the old Forum, occasionally there were posts with this result, but there was no obvious solution.

    A reboot will likely stop this, at least for a while.

    If you get no help from your current support rep, ask for your case to be escalated.
    Should you find a resolution, please post it.

  • @Bruce_Briggs said:
    A reboot will likely stop this, at least for a while.

    A reboot of what do you mean ?

  • your firewall

  • RalphRalph WatchGuard Representative

    Hello Indrek,

    Does changing the log level on the client to Debug change behaviour ? right-click tray icon / properties

  • Same issue here on an M470. Intermittently connections stall at the same point - waiting for connection after authentication is confirmed - system manager shows a 0.0.0.0 address. Keep disconnecting/reconnecting it will eventually make the connection.

    What I have found is if I completely uninstall ESET Security client (av, firewall, IPS) it will connect flawlessly. Manually disabling the AV or individual modules does not change the situation.

    This worked without issue up until the M470 replaced our old M300.

  • edited March 2020

    Hello,
    First, I finally caught one of the user with problems and he set client log to Debug level, and he able to connect. Does it say about what ?
    Second, we do have ESET antivirus, yes. What if to add our vpn site to "allowed url list" ?

  • Hello,
    I've just noticed a similar issue on our M270.
    Recently upgraded from XTM330 and notice SSL VPN wouldnt connect every time.
    We're using ESET too.
    I've tried disabling the firewall on ESET and it still fails intermittently.
    Only just started troubleshooting so not much else to add I'm afraid.

  • RalphRalph WatchGuard Representative

    Has anyone tried setting the client's log level to debug, as suggested earlier ? This changes internal timing between components and may help here. A new client is being released next week.

  • No, disabling anything on ESET doesn't help. Only full de-installation of ESET.
    I filed a ticket to ESET (company), but still no solution.

  • Same issue, super frustrating and it takes approx 7-13 tries to connect with system reboots.

  • edited March 2020

    We had the same issue, started a support ticket. Tried the workaround, It did work on some Clients, but we ended up downgrading our Fireboxes (M500 Active/Passive Cluster). We chose XTM V12.1.3 since we had a Customer running this version without any problems. The Downgrade solved the issues for us.

  • edited March 2020

    I just had this same issue on a windows 10 build v1909 laptop running SSL VPN app v12.5.2 (XTM850 Cluster). Quick fix was to download the SSL VPN app v12.2 from watchguards site and it then connected. Submitting ticket to support to figure out a resolution.
    http://cdn.watchguard.com/SoftwareCenter/Files/MUVPN_SSL/12_2/WG-MVPN-SSL_12_2.exe

  • edited March 2020

    The workaround to downgrade to 12.2 worked for us in some cases not all. Waiting for new VPN SSL software.

  • Article ID :000016567 helped me.

    For users that experience this specific failure issue, you can change the client diagnostic log level to allow the connection. To change the client diagnostic log level:

    1. Right-click the Mobile VPN with SSL system tray icon and select Properties.
      
    2. From the Log Level dropdown menu, select Debug.
      
    3. Click OK.
      
  • edited March 2020

    Windows 10 1909, also ESET Endpoint Antivirus (7.2) here.
    Sometimes restarting the process "C:\Program Files (x86)\WatchGuard\WatchGuard Mobile VPN with SSL\wgsslvpnsrc.exe" fixes it, but sometimes it doesn't. Complete uninstall of ESET fixed it permanently.

  • edited March 2020

    Mornin Peeps. We have a variety of Watchguards, and use ESET as our main AV program. Think we found a fix this morning by doing the following:

    To find If your issue is caused by the same thing:
    On the client machine you are using to connect to the VPN, go to Advanced setup -> Web and Email and disable protocol filtering. Now try connecting, if this now works try the following:

    1) Add the Ip address of the Watchguard to Protocol filtering -> "Excluded IP Addresses"

    2) Add Watchguard SSL VPN Client to Protocol filtering -> "Excluded applications"

    3) Set to "Learning Mode" in Network protection -> Basic -> Filtering mode.

    4) Connect the SSL VPN.

    5) Set the filtering mode back to "Automatic Mode".

    Hope this helps.

    Steve

  • I can confirm Watchguard VPN SSL client version 12.5.3 works like a charm.
    We we're using ESET too... no issues now with 12.5.3
    Here you have the KB of ESET and link for download new client: https://support.eset.com/en/kb7470-watchguard-mobile-vpn-connection-issue-with-eset-endpoint-antivirus-eset-endpoint-security

  • Not sure if you resolved this or not. We had a problem similar this, including ESET in the mix, and we found a solution here. It ended up being the TAP driver. Complete solution at the StarNet Technologies link above.

  • I have this exact issue today. Using client 12.5.3. User has it working on mobile hotspot but not Cox internet wifi. No resolution yet.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @R9IS3
    If it's not working on just one Internet connection, it's very likely that the port you're using is being blocked.

    I'd suggest opening a case if you haven't done so already, so that the support team can look at your logs and assist.

    -James Carson
    WatchGuard Customer Support

  • @R9IS3 said:
    I have this exact issue today. Using client 12.5.3. User has it working on mobile hotspot but not Cox internet wifi. No resolution yet.

    Are you using port 443? If so, I cannot imagine that Cox would block it because it would kill any HTTPS web site access.

    Try using Telnet to your Firebox from the problem device, accessing whatever port you have set for the SSLVPN. If telnet answers, you outbound port is not blocked by Cox.

    Gregg Hill

Sign In to comment.