Issue with SSLVPN 12.2 and latest Outlook Office 365

Hi,

We have been having issues to access outlook after latest builds (1902,1903)
This only occurs with SSLVPN 12.2 that we use, configured as force tunnel.

IKEv2 VPN works fine with remote gateway on.

Error msg from outlook is "Sorry, we can’t connect to your account. Please try again later"
If i flushdns after connecting to SSLVPN it's working again.
After reboot or reconnect same issue comes again.

Don't know if it's related to SSLVPN or Outlook or actually both but really annoing feature that is causing lot of problems.

Maybe some bug with client?

Comments

  • Best to open a support incident on this.

  • I opened case for it. I can reply result or solution here if someone needs it. This is only happening towards Office365 users using MFA and tenant has Modern authentication enabled.

  • ToniJoronen, Can you reply for the solution as we are having the exact same issue. Thanks

  • I had the same issue and it's due to the "TAP-Windows Adapter V9" network connection. Open the "TAP-Windows Adapter V9" network properties, and add a gateway to it that matches the IP address of the SSLVPN connection to the Firebox.

    Gregg Hill

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @DavidJ

    If you're running into an issue that's causing your VPN to not work, I'd suggest opening a support ticket so that one of our technicians can help.

    You can open a case online or via the phone here:
    https://www.watchguard.com/wgrd-support/contact-support

    Thank you,

    -James Carson
    WatchGuard Customer Support

  • edited August 2019

    James,

    In my case, the SSLVPN worked fine with everything except for Outlook connecting to Office 365 with multi-factor authentication and Modern Authentication enabled on the Office 365 tenant. The fix is the TAP adapter change I noted.

    EDIT:This issue is some of the information already answered on the old forums that did not get carried over to this new forum.

    Gregg Hill

  • The TAP Adapter change fixes it.. but... I don't want to do that for 250 people manually. Is there a baseline fix in the firewall yet?

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @CodyP

    I'd suggest opening a ticket if that won't work. If the fix that gets applied on the client (tap driver) is what fixes it, it's doubtful a change on the firewall will correct it.

    -James Carson
    WatchGuard Customer Support

  • @James_Carson said:
    Hi @CodyP

    I'd suggest opening a ticket if that won't work. If the fix that gets applied on the client (tap driver) is what fixes it, it's doubtful a change on the firewall will correct it.

    "...it's doubtful a change on the firewall will correct it."

    Can the firewall be made to set the correct gateway in the SSLVPN installer agent that it hands out on the login page?

    Or have DHCP on the firewall hand out the gateway to the remote computer as it hands out an IP and DNS when the computer connects? I just connected to my SSLVPN and the default gateway is blank.

    Gregg Hill

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @Greggmh123
    The gateway config is in the SSLVPN config that is downloaded, but the TAP driver has nothing to do with that config. It's part of the SSLVPN install itself.

    -James Carson
    WatchGuard Customer Support

  • James,

    The more I think about it, the more I wonder why DHCP on the SSLVPN does not hand out the gateway of the firewall's SSLVPN subnet. If it gave out the gateway, the problem would be solved.

    My LAN subnet is 192.168.16.0 and my SSLVPN is 192.168.35.0. Is there a reason that DHCP on a Firebox does NOT hand out the 192.168.35.1 address of the firewall as the gateway on the SSLVPN connection?

    Gregg

    Gregg Hill

  • Gregg - what issue are you having with a blank default gateway?
    I also see a blank gateway IP addr in V12.5.1 U1, but I don't have any issues with my setting of all traffic going over SSLVPN.

  • @Bruce_Briggs said:
    Gregg - what issue are you having with a blank default gateway?
    I also see a blank gateway IP addr in V12.5.1 U1, but I don't have any issues with my setting of all traffic going over SSLVPN.

    Bruce,

    The SSLVPN worked fine with everything except for Outlook 2016 connecting to Office 365 with multi-factor authentication and Modern Authentication enabled on the Office 365 tenant. The fix is the TAP adapter change of adding the gateway address to it. My SSLVPN subnet is 192.168.35.0, so the gateway manually added on the TAP adapter of the remote client is 192.168.35.1. That setup allows Outlook to connect. I never had the problem until I enabled MFA with Modern Authentication on my Office 365 tenant account.

    Gregg

    Gregg Hill

  • Time for a support incident

  • I only have two computers that ever use the SSLVPN. Not worth hassling with an incident...yet.

    Gregg Hill

  • Hi,
    We have encountered the same issue. Any solution for this?
    Thanks.

  • edited March 2020

    Did you try Gregg's solution above?

  • Yes, I saw that and wondering if there is another fix from the firewall end. As another user has mentioned, we have lots of users and not sure how to get this fix rolled out successfully.
    Thanks for your understanding.

  • A support incident is your best approach here

  • Verify that you have the "Auto reconnect after a connection is lost" SSLVPN Authentication option selected.

    From the docs:

    If you want the Mobile VPN with SSL client to be able to automatically reconnect, select Auto reconnect after a connection is lost. If you enable this option, mobile users can select a check box on the Mobile VPN with SSL client to control whether the client automatically reconnects. You must also enable this option if you want the client to automatically use the secondary IP address when it cannot connect to the primary IP address.

  • Did anyone get a resolution from Watchguard on this issue? Thanks!

  • @Kevin said:
    Did anyone get a resolution from Watchguard on this issue? Thanks!

    No. Also, my previous "The more I think about it, the more I wonder why DHCP on the SSLVPN does not hand out the gateway of the firewall's SSLVPN subnet. If it gave out the gateway, the problem would be solved." comment is incorrect.

    Even if DHCP on an SSLVPN connection handed out the gateway, that is not the problem; the problem is the TAP-Adapter not having the gateway of the firewall's SSLVPN subnet.

    Gregg Hill

  • Just wanted to chime in and say we have this Outlook \ VPN issue as well.

  • edited March 2020

    Been running into this issue across the board for several different configs and a variety of WG/firewall models. No common thread between them updating gateway fixes it but with the COVID issues, it is going to drive me up a wall anyone finds anything else out? Updating hundreds of clients doesn't seem fun.

  • There is now a workaround as of today.
    https://watchguard.force.com/customers/wgknowledgebase?SFDCID=kA10H000000g3SPSAY&lang=en_US

    Must update firebox to 12.5.3. And then use the CLI to enable the setting outlined in the article.

  • I have installed 12.5.3 on my T35 and done the CLI command. I can confirm it fixes the issue.

    Gregg Hill

Sign In to comment.