SSL VPN and Outlook Trying to connect

After connecting to the VPN, Outlook will not connect, even after entering credentials again. The bottom message on Outlook states Trying to connect.

«1

Comments

  • Nothing in Traffic Monitor to help understand this?
    Is Routed VPN Traffic option selected in your SSLVPN setup ?
    If not, it needs to be.

  • I don't see any errors for the connected IP. I suspect the Routed VPN traffic isn't configured correctly. I didn't check one. Should I check allowed network address, which selects all of them.

  • Start with "Force all client traffic through tunnel"
    This will allow Internet access.

  • Turn on Logging on the Allow SSLVPN-Users policy to see packets allowed by it in Traffic Monitor.

  • When I ping the mail server name used in outlook, it resolved to a private IP. We are using outlook 2010. Why does that route not work through the VPN?

  • I don't know about the behavior if you have an onsite mail server, but with Outlook trying to connect to Office 365 via an SSLVPN, you'll need to modify the "TAP-Windows Adapter V9" network connection to add a gateway IP to it. Use the SSLVPN IP of the Firebox. So, if your SSLVPN Firebox IP is 192.168.35.1, put that IP into computer's "TAP-Windows Adapter V9" network connection as the gateway. I have posted in the forums about it a few times, but I don't know if that was the old forums whose information is now gone.

    Gregg Hill

  • I saw your post on the "TAP- Windows Adapter V9" in other posts. Unfortunately, that didn't work. I don't see any failed messages in the network monitor. Should I see those if the outlook client isn't connecting. We are using office 2010.

  • To what are you connecting?
    Where is it located? On the Internet?
  • The email server is located at another location, so I believe I need a branch office VPN setup since the mail server isn't at the location of the WatchGuard. Is that the best way to connect the two networks?

  • Can you access the email server from behind the WG firewall when not connected to SSLVPN?

  • I have no issues accessing the Internet when connected to SSLVPN, and no issues with Outlook connecting to Gmail - my mail server.
    I have never needed to make a change to the TAP driver for this to work.
    I am connected now using SSLVPN, posting here and accessing my email using Outlook.

  • The email server can't be accessed from the Internet.

  • Then it would seem that you need to set up a BOVPN between these 2 sites.

    Start here:
    Manual Branch Office VPN Tunnels
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/other/chapters/manualbovpntunnels.html

  • edited February 2020

    @Bruce_Briggs said:
    I have no issues accessing the Internet when connected to SSLVPN, and no issues with Outlook connecting to Gmail - my mail server.
    I have never needed to make a change to the TAP driver for this to work.
    I am connected now using SSLVPN, posting here and accessing my email using Outlook.

    Bruce,

    You "never needed to make a change to the TAP driver for this to work" because you are not using Office 365 with Modern Authentication. It has to do with the certs used by Office 365. It MAY also apply to Exchange 2016 and higher.

    Gregg

    Gregg Hill

  • Chris,

    I don't think that my comments apply to you. I wasn't aware (missed something!) that your email server is not Internet-facing.

    Gregg Hill

  • Gregg:
    Looking at Status when I am connected to SSLVPN shows
    Virtual IP addr: 192.168.222.2
    Gateway connected: 192.168.222.1

    So I am not seeing the blank gateway addr that you had previoulsy seen.
    Not sure if this addresses the Office 365 with Modern Authentication problem or not.

  • On my laptop, in Control Panel\Network and Internet\Network Connections, I have to set the TAP adapter to have an IPv4 gateway BEFORE I connect to the SSLVPN. Otherwise, it shows no gateway in "ipconfig /all" and Outlook won't connect to Office 365 when using the SSLVPN from a remote location such as my office away from home, Starbucks.

    If I don't set the gateway in the TAP adapter, I get a blank gateway for the SSLVPN subnet (192.168.35.0):

    Description . . . . . . . . . . . : TAP-Windows Adapter V9
    Physical Address. . . . . . . . . : 00-FF-snip
    DHCP Enabled. . . . . . . . . . . : Yes
    Autoconfiguration Enabled . . . . : Yes
    Link-local IPv6 Address . . . . . : fe80::snip(Preferred)
    IPv4 Address. . . . . . . . . . . : 192.168.35.2(Preferred)
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Lease Obtained. . . . . . . . . . : Friday, February 21, 2020 4:24:52 PM
    Lease Expires . . . . . . . . . . : Saturday, February 20, 2021 4:24:51 PM
    Default Gateway . . . . . . . . . :
    DHCP Server . . . . . . . . . . . : 192.168.35.254
    DHCPv6 IAID . . . . . . . . . . . : 201391999
    DHCPv6 Client DUID. . . . . . . . : 00-01-00snip
    DNS Servers . . . . . . . . . . . : 192.168.16.11
    NetBIOS over Tcpip. . . . . . . . : Enabled

    Gregg Hill

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

  • @StarNet_Actual said:
    Not sure if you resolved this or not. We had a problem similar this and we found a solution here. It ended up being the TAP driver. Complete solution at the StarNet Technologies link above.

    The Win 10 file is detected as having a Trojan: https://www.virustotal.com/gui/file/d8f861de1519c680c4e506b4e08b4d80db7c385a4ccc2fcc56e2278d41c1cabe/detection

    Could be a false-positive.

    Gregg

    Gregg Hill

  • When I ran the check on the OpenVPN-Hosted installer, it came back clean, as expected.
    https://www.virustotal.com/gui/url/93741f5fddcf9be2ac34efb7f95493781f1fb174e7c4a8e921686c2fcde644f2/detection

  • edited March 2020

    @StarNet_Actual said:
    When I ran the check on the OpenVPN-Hosted installer, it came back clean, as expected.
    https://www.virustotal.com/gui/url/93741f5fddcf9be2ac34efb7f95493781f1fb174e7c4a8e921686c2fcde644f2/detection

    There was only one site that had it flagged when I checked. Incidentally, the new SSLVPN client 12.5.3 has a newer TAP-Driver built into it and it pops up a separate message for it during the installation, which is an OpenVPN dialog box. It is version 9.0.0.21, dated 4/21/16. I have yet to test it.

    EDIT: Your linked TAP-Driver is even newer, version 9.24.2.601, dated 9/27/19. I wonder why WatchGuard didn't use that version.

    Gregg Hill

  • Even using the new 12.5.3 SSLVPN client with its updated (although still outdated version 9.0.0.21, dated 4/21/16) TAP-Adapter driver, or when using the current OpenVPN TAP-Adapter driver (version 9.24.2.601, dated 9/27/19), Outlook 365 trying to connect to an Office 365 email account via SSLVPN still fails unless the TAP-Adapter is modified.

    When Outlook 365 is trying to connect to an Office 365 email account via SSLVPN, I still have to modify the "TAP-Windows Adapter V9" network connection to add the SSLVPN gateway IP to it. My LAN default gateway is my T35's IP of 192.168.16.1, and my SSLVPN is using 192.168.35.1 as its gateway. I have to add 192.168.35.1 as a default gateway to the TAP-Adapter's IPv4 properties.

    I do not have any issues with IKEv2 VPN and Outlook 365 connecting to an Office 365 mailbox.

    My Office 365 email accounts are set up to use modern authentication, if that matters.

    Gregg Hill

  • Try V12.5.3 which is just out.

    From the V12.5.3 Release Notes:
    To make sure Office 365 traffic uses a full-tunnel SSL VPN, you can now enable the default-route-client CLI option. [FBX-16838]

    Known Issue:
    Office 365 fails for Mobile VPN with SSL users
    https://watchguardsupport.secure.force.com/publicKB?type=Known Issues&SFDCID=kA10H000000g3SPSAY&lang=en_US

    Tracking ID: FBX-16838
    Status: Resolved
    Resolved In: Fireware v12.5.3
    Description

    Users that connect to your network through Mobile VPN with SSL cannot connect to Office 365. This happens because the Mobile VPN with SSL TAP adapter does not set a default gateway when you connect to the VPN. Because Office365 cannot detect a gateway, Office 365 traffic does not go through the tunnel.
    Workaround

    To make sure that Office 365 traffic goes through the mobile VPN tunnel, use one of these options:

    Enable the default-route-client option in the Fireware CLI (Fireware v12.5.3 or higher)
    Manually configure a default gateway on the client
    Use a different Fireware mobile VPN method
    

    Option 1—Enable the default-route-client CLI Option (Windows only)

    If you select the Force all client traffic through tunnel option in the Mobile VPN with SSL configuration, the Firebox pushes the routes 0.0.0.0/1 and 128.0.0.0/1 to the Windows computer. These routes are added instead of a more general route to avoid replacing existing routes.

    In Fireware v12.5.3 or higher, you can enable the default-route-client option in the CLI. When you enable this option, the Firebox pushes the general route 0.0.0.0/0.0.0.0 to Windows computers, and the default gateway of the TAP interface on each Windows computer is set to the VPN gateway IP address. The default-route-client command affects only Windows computers. Computers with other operating systems do not receive the 0.0.0.0/0.0.0.0 route.

    To enable this option, specify this command from the Firebox CLI:

    WG(config/policy)#sslvpn resource default-route-client

    To disable this option, specify this command from the Firebox CLI:

    WG(config/policy)#no sslvpn resource default-route-client

    By default, the default-route-client option is disabled.
    Option 2—Manually Configure a Default Gateway on a Windows Client

    From Control Panel, open Network and Internet > View network status and tasks > Change adapter settings.
    Find the network adapter with TAP-Windows Adapter V9 in the description.
    Right-click the network adapter and select Properties.
    Double-click Internet Protocol Version 4 (TCP/IPv4). The properties dialog box appears.
    Click Advanced. The Advanced TCP/IP Settings dialog box appears.
    Below Default gateways, click Add.
    In the Gateway text box, type the Firebox IP address for the virtual IP address range. This is typically the first usable IP address of the virtual pool.
    Click Add.
    On each open dialog box, click OK.
    

    Option 3—Use a Different Mobile VPN Method

    This issue affects only Mobile VPN with SSL. If you do not want to enable the CLI option or manually configure a gateway on the client, you can avoid this issue by using a different mobile VPN method. Fireware supports three other mobile VPN methods: Mobile VPN with IKEv2, Mobile VPN with L2TP, and Mobile VPN with IPSec.

  • edited March 2020

    Geez, Bruce when you say "Try V12.5.3 which is just out", you really mean it. I checked a few hours ago and it was still 12.5.2 Update 1 as the latest! I have been checking a few times a day for the last week. Downloading it now.

    Gregg Hill

  • Fireware 12.5.3 just fixed a site I was not able to reach, https://www.geapplianceparts.com. Now it goes right to it.

    Gregg Hill

  • edited April 2020

    subscribe

  • Has anyone tried option 1 changing the default route through CLI yet? Just wondering if it solved the problem and if it introduces any other issues. In all the years managing WG devices, I've never had to touch the CLI. Will the option be added to the gui eventually?

    Option 2 is kind of a waste of time because as soon as the clients update their ssl vpn clients to the next version, the changes are reverted back to defaults with no gateway.

  • edited May 2020

    Quick note for this thread: All SSL clients will be disconnected after entered the cli command.

  • I made the change a month ago, so far all the issues are gone. Not sure why this isn't the default and why we can't change it in the gui. Maybe they saved that for a future release.

Sign In to comment.