Office offline after VPN connection

Got a problem with Viscosity or need help? Ask here!

aapje

Posts: 4
Joined: Thu Jun 28, 2018 12:36 am

Post by aapje » Fri Jul 03, 2020 10:38 pm
Whenever I connect to a VPN with Viscosity and refer all traffic through the VPN Microsoft Office thinks it's offline.
It's because my gateway is an address from the OpenVPN stack as is given by the OpenVPN server. It's an invalid gateway. Everything else work fine. It has to do with the NLA service not being able to connect to http://www.msftncsi.com/ncsi.txt .

When I'm connected:

Connection-specific DNS Suffix . : bkx.intern
Description . . . . . . . . . . . : Viscosity Virtual Adapter V9.1
Physical Address. . . . . . . . . : 00-FF-71-D7-A8-8D
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::8906:3993:1cd0:6989%3(Preferred)
IPv4 Address. . . . . . . . . . . : 172.30.0.51(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.240
Lease Obtained. . . . . . . . . . : Friday, 3 July 2020 14:34:55
Lease Expires . . . . . . . . . . : Saturday, 3 July 2021 14:34:55
Default Gateway . . . . . . . . . : 172.30.0.49

172.30.0.49 is not a valid Gateway. It's a address within the OpenVPN range on my server. But there is no way to connect to it.

When I load up OpenVPN gui and import the exact same configuration everything works fine. So Viscosity is doing something different and I cannot change it. When I'm connected with OpenVPN and I look at my TAP adapter is does not have a default gateway configured.

Whenever I manually add a gateway for the viscosity connection it will always make it secondary to the already defined Gateway thus solving nothing.

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Mon Jul 06, 2020 1:33 pm
Hi aapje,

You should actually be having the opposite problem here. The gateway being reachable isn't actually relevant as OpenVPN will translate it, it is simply the first address being used in your pushed /31 subnet from your server. Windows requires a gateway/default route in order for NLA and NCSI to function. NLA (Network Location Awareness) is used for setting your network type, i.e. private/public/domain, in order for firewall policies, group policies, etc to be applied.

NCSI (Network Connection Status Indicator) is used to determine what type of network access you have, i.e. if you have no connectivity, local connectivity or internet. Without a gateway present, Windows will not check NCSI at all. This should be reflected by what appears in your network status, go to Network Connections -> Change Adapter options then double click the network connection to view the Connectivity for each IP version.

We used to receive a lot of support requests with this exact problem with Office before we had Viscosity apply the gateway as it uses the NCSI to check whether the machine has Internet access rather than just trying to connect like most applications. This is the first time we've heard of this problem with Office in many releases.

It sounds like something else is going on here, the most likely explanation is routes are not being applied correctly when using the OpenVPN GUI client and your traffic is still going through your local network.

To test this, you simply need to delete the 0/0 route applied by Viscosity, this will remove the gateway as well. Open a command prompt with Admin rights then run:

route delete 0.0.0.0 mask 0.0.0.0 172.30.0.49

I'd also recommend checking the logs and your routing table with both Viscosity and OpenVPN GUI to see if anything is incorrect with your configuration with either.

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

aapje

Posts: 4
Joined: Thu Jun 28, 2018 12:36 am

Post by aapje » Mon Jul 06, 2020 4:56 pm
Mon Jul 06, 2020 1:33 pmEric wrote:
Hi aapje,

You should actually be having the opposite problem here. The gateway being reachable isn't actually relevant as OpenVPN will translate it, it is simply the first address being used in your pushed /31 subnet from your server. Windows requires a gateway/default route in order for NLA and NCSI to function. NLA (Network Location Awareness) is used for setting your network type, i.e. private/public/domain, in order for firewall policies, group policies, etc to be applied.

NCSI (Network Connection Status Indicator) is used to determine what type of network access you have, i.e. if you have no connectivity, local connectivity or internet. Without a gateway present, Windows will not check NCSI at all. This should be reflected by what appears in your network status, go to Network Connections -> Change Adapter options then double click the network connection to view the Connectivity for each IP version.

We used to receive a lot of support requests with this exact problem with Office before we had Viscosity apply the gateway as it uses the NCSI to check whether the machine has Internet access rather than just trying to connect like most applications. This is the first time we've heard of this problem with Office in many releases.

It sounds like something else is going on here, the most likely explanation is routes are not being applied correctly when using the OpenVPN GUI client and your traffic is still going through your local network.

To test this, you simply need to delete the 0/0 route applied by Viscosity, this will remove the gateway as well. Open a command prompt with Admin rights then run:

route delete 0.0.0.0 mask 0.0.0.0 172.30.0.49

I'd also recommend checking the logs and your routing table with both Viscosity and OpenVPN GUI to see if anything is incorrect with your configuration with either.

Regards,
Eric
Hi Eric, thank you for taking the time to respond.

route delete 0.0.0.0 mask 0.0.0.0 172.30.0.49
Doesn't fix the issue. After restarting outlook it still thinks I am offline.


Viscosity log:
Code: Select all
Jul 06 8:43:15 am: State changed to Connecting
Jul 06 8:43:15 am: Viscosity Windows 1.8.5.1 (1669)
Jul 06 8:43:15 am: Running on Windows 10 2004 (19041) 64 bit
Jul 06 8:43:15 am: Running on .NET Framework Version 4.8.04084.528372
Jul 06 8:43:15 am: Bringing up interface...
Jul 06 8:43:15 am: OpenVPN 2.4.8 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [AEAD] built on Apr  1 2020
Jul 06 8:43:15 am: library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Jul 06 8:43:15 am: Checking reachability status of "xxxxxxxxx"...
Jul 06 8:43:15 am: Resolving address: "xxxxxxxxx"
Jul 06 8:43:15 am: Server reachable. Connecting to xxxxxxxxxxxx:1194:udp.
Jul 06 8:43:16 am: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Jul 06 8:43:16 am: TCP/UDP: Preserving recently used remote address: [AF_INET]xxxxxxxxxxxx:1194
Jul 06 8:43:16 am: UDP link local: (not bound)
Jul 06 8:43:16 am: UDP link remote: [AF_INET]xxxxxxxxxxxx:1194
Jul 06 8:43:16 am: State changed to Authenticating
Jul 06 8:43:16 am: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Jul 06 8:43:16 am: [OpenVPN-server] Peer Connection Initiated with [AF_INET]xxxxxxxxxxx:1194
Jul 06 8:43:16 am: State changed to Connecting
Jul 06 8:43:16 am: Awaiting adapter to come up...
Jul 06 8:43:16 am: TAP-WIN32 device [xxxxxxxxxxxxxx] opened: \\.\Global\{F5345A60-D6CA-4001-A627-3960F98F337D}.tap, index: 12
Jul 06 8:43:16 am: Set TAP-Windows TUN subnet mode network/local/netmask = 172.30.0.48/172.30.0.50/255.255.255.240 [SUCCEEDED]
Jul 06 8:43:16 am: Waiting for DNS Setup to complete...
Jul 06 8:43:16 am: Successful ARP Flush on interface [12] {F5345A60-D6CA-4001-A627-3960F98F337D}
Jul 06 8:43:17 am: Initialization Sequence Completed
Jul 06 8:43:17 am: DNS set to Full:
Server - 172.30.0.1:53; Lookup Type - Any; Domains - bkx.intern.
OpenVPN log:
Code: Select all
Mon Jul 06 08:46:15 2020 OpenVPN 2.4.9 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 16 2020
Mon Jul 06 08:46:15 2020 Windows version 6.2 (Windows 8 or greater) 64bit
Mon Jul 06 08:46:15 2020 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Enter Management Password:
Mon Jul 06 08:46:15 2020 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Jul 06 08:46:15 2020 Need hold release from management interface, waiting...
Mon Jul 06 08:46:15 2020 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Jul 06 08:46:16 2020 MANAGEMENT: CMD 'state on'
Mon Jul 06 08:46:16 2020 MANAGEMENT: CMD 'log all on'
Mon Jul 06 08:46:16 2020 MANAGEMENT: CMD 'echo all on'
Mon Jul 06 08:46:16 2020 MANAGEMENT: CMD 'bytecount 5'
Mon Jul 06 08:46:16 2020 MANAGEMENT: CMD 'hold off'
Mon Jul 06 08:46:16 2020 MANAGEMENT: CMD 'hold release'
Mon Jul 06 08:46:17 2020 MANAGEMENT: CMD 'username "Auth" "gerben"'
Mon Jul 06 08:46:17 2020 MANAGEMENT: CMD 'password [...]'
Mon Jul 06 08:46:17 2020 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Mon Jul 06 08:46:17 2020 MANAGEMENT: >STATE:1594017977,RESOLVE,,,,,,
Mon Jul 06 08:46:17 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]xxxxxxxxxxx:1194
Mon Jul 06 08:46:17 2020 Socket Buffers: R=[65536->65536] S=[64512->64512]
Mon Jul 06 08:46:17 2020 UDP link local: (not bound)
Mon Jul 06 08:46:17 2020 UDP link remote: [AF_INET]xxxxxxxxxxx:1194
Mon Jul 06 08:46:17 2020 MANAGEMENT: >STATE:1594017977,WAIT,,,,,,
Mon Jul 06 08:46:17 2020 MANAGEMENT: >STATE:1594017977,AUTH,,,,,,
Mon Jul 06 08:46:17 2020 TLS: Initial packet from [AF_INET]xxxxxxxxxxx:1194, sid=fe700d34 9e2bf845
Mon Jul 06 08:46:17 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Jul 06 08:46:17 2020 VERIFY OK: depth=1, CN=OpenVPN-CA
Mon Jul 06 08:46:17 2020 VERIFY KU OK
Mon Jul 06 08:46:17 2020 Validating certificate extended key usage
Mon Jul 06 08:46:17 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mon Jul 06 08:46:17 2020 VERIFY EKU OK
Mon Jul 06 08:46:17 2020 VERIFY OK: depth=0, CN=OpenVPN-server
Mon Jul 06 08:46:18 2020 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Mon Jul 06 08:46:18 2020 [OpenVPN-server] Peer Connection Initiated with [AF_INET]xxxxxxxxxxx:1194
Mon Jul 06 08:46:19 2020 MANAGEMENT: >STATE:1594017979,GET_CONFIG,,,,,,
Mon Jul 06 08:46:19 2020 SENT CONTROL [OpenVPN-server]: 'PUSH_REQUEST' (status=1)
Mon Jul 06 08:46:19 2020 PUSH: Received control message: 'PUSH_REPLY,route 172.30.0.0 255.255.252.0,persist-key,comp-lzo no,dhcp-option DNS 172.30.0.1,dhcp-option DOMAIN bkx.intern,dhcp-option WINS 172.30.0.1,route-gateway 172.30.0.49,topology subnet,ping 10,ping-restart 120,ifconfig 172.30.0.50 255.255.255.240,peer-id 0,cipher AES-256-GCM'
Mon Jul 06 08:46:19 2020 OPTIONS IMPORT: timers and/or timeouts modified
Mon Jul 06 08:46:19 2020 OPTIONS IMPORT: compression parms modified
Mon Jul 06 08:46:19 2020 OPTIONS IMPORT: --persist options modified
Mon Jul 06 08:46:19 2020 OPTIONS IMPORT: --ifconfig/up options modified
Mon Jul 06 08:46:19 2020 OPTIONS IMPORT: route options modified
Mon Jul 06 08:46:19 2020 OPTIONS IMPORT: route-related options modified
Mon Jul 06 08:46:19 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Jul 06 08:46:19 2020 OPTIONS IMPORT: peer-id set
Mon Jul 06 08:46:19 2020 OPTIONS IMPORT: adjusting link_mtu to 1525
Mon Jul 06 08:46:19 2020 OPTIONS IMPORT: data channel crypto options modified
Mon Jul 06 08:46:19 2020 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Jul 06 08:46:19 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Jul 06 08:46:19 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Jul 06 08:46:19 2020 interactive service msg_channel=660
Mon Jul 06 08:46:19 2020 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 I=9 HWADDR=e4:a4:71:99:b4:89
Mon Jul 06 08:46:19 2020 open_tun
Mon Jul 06 08:46:19 2020 TAP-WIN32 device [Local Area Connection] opened: \\.\Global\{67926BA2-BED4-4D2A-AFF4-D6CCE2F071A4}.tap
Mon Jul 06 08:46:19 2020 TAP-Windows Driver Version 9.24 
Mon Jul 06 08:46:19 2020 Set TAP-Windows TUN subnet mode network/local/netmask = 172.30.0.48/172.30.0.50/255.255.255.240 [SUCCEEDED]
Mon Jul 06 08:46:19 2020 Notified TAP-Windows driver to set a DHCP IP/netmask of 172.30.0.50/255.255.255.240 on interface {67926BA2-BED4-4D2A-AFF4-D6CCE2F071A4} [DHCP-serv: 172.30.0.62, lease-time: 31536000]
Mon Jul 06 08:46:19 2020 Successful ARP Flush on interface [10] {67926BA2-BED4-4D2A-AFF4-D6CCE2F071A4}
Mon Jul 06 08:46:19 2020 MANAGEMENT: >STATE:1594017979,ASSIGN_IP,,172.30.0.50,,,,
Mon Jul 06 08:46:24 2020 TEST ROUTES: 2/2 succeeded len=1 ret=1 a=0 u/d=up
Mon Jul 06 08:46:24 2020 C:\WINDOWS\system32\route.exe ADD xxxxxxxxxxx MASK 255.255.255.255 192.168.178.1
Mon Jul 06 08:46:24 2020 Route addition via service succeeded
Mon Jul 06 08:46:24 2020 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 172.30.0.49
Mon Jul 06 08:46:24 2020 Route addition via service succeeded
Mon Jul 06 08:46:24 2020 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 172.30.0.49
Mon Jul 06 08:46:24 2020 Route addition via service succeeded
Mon Jul 06 08:46:24 2020 MANAGEMENT: >STATE:1594017984,ADD_ROUTES,,,,,,
Mon Jul 06 08:46:24 2020 C:\WINDOWS\system32\route.exe ADD 172.30.0.0 MASK 255.255.252.0 172.30.0.49
Mon Jul 06 08:46:24 2020 Route addition via service succeeded
Mon Jul 06 08:46:24 2020 Initialization Sequence Completed
Mon Jul 06 08:46:24 2020 MANAGEMENT: >STATE:1594017984,CONNECTED,SUCCESS,172.30.0.50,xxxxxxxxxxx,1194,,
(I've redacted the hostname and ip address)

Routing table with Viscosity:
Code: Select all
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.178.1  192.168.178.229     40
          0.0.0.0          0.0.0.0      172.30.0.49      172.30.0.50   1000
          0.0.0.0        128.0.0.0      172.30.0.49      172.30.0.50     26
   94.228.143.164  255.255.255.255    192.168.178.1  192.168.178.229     85
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
     127.56.49.53  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
        128.0.0.0        128.0.0.0      172.30.0.49      172.30.0.50     26
       172.30.0.0    255.255.252.0      172.30.0.49      172.30.0.50     26
      172.30.0.48  255.255.255.240         On-link       172.30.0.50    257
      172.30.0.50  255.255.255.255         On-link       172.30.0.50    257
      172.30.0.63  255.255.255.255         On-link       172.30.0.50    257
    192.168.178.0    255.255.255.0         On-link   192.168.178.229    296
  192.168.178.229  255.255.255.255         On-link   192.168.178.229    296
  192.168.178.255  255.255.255.255         On-link   192.168.178.229    296
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link   192.168.178.229    296
        224.0.0.0        240.0.0.0         On-link       172.30.0.50    257
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link   192.168.178.229    296
  255.255.255.255  255.255.255.255         On-link       172.30.0.50    257
===========================================================================
Persistent Routes:
  None
Routing table with OpenVPN:
Code: Select all
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.178.1  192.168.178.229     45
          0.0.0.0        128.0.0.0      172.30.0.49      172.30.0.50    281
   94.228.143.164  255.255.255.255    192.168.178.1  192.168.178.229    301
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
        128.0.0.0        128.0.0.0      172.30.0.49      172.30.0.50    281
       172.30.0.0    255.255.252.0      172.30.0.49      172.30.0.50    281
      172.30.0.48  255.255.255.240         On-link       172.30.0.50    281
      172.30.0.50  255.255.255.255         On-link       172.30.0.50    281
      172.30.0.63  255.255.255.255         On-link       172.30.0.50    281
    192.168.178.0    255.255.255.0         On-link   192.168.178.229    301
  192.168.178.229  255.255.255.255         On-link   192.168.178.229    301
  192.168.178.255  255.255.255.255         On-link   192.168.178.229    301
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link       172.30.0.50    281
        224.0.0.0        240.0.0.0         On-link   192.168.178.229    301
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link       172.30.0.50    281
  255.255.255.255  255.255.255.255         On-link   192.168.178.229    301
===========================================================================
Persistent Routes:
  None
In both cases (OpenVPN & Viscosity) my traffic is successfully directed over the VPN. I need that to do my work so I would notice soon enough if that wasn't the case. (ip restrictions on endpoints I need to connect to) Also I can see my external ip is that of the VPN-server in both instances.

Any further help would be much appreciated.

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Mon Jul 06, 2020 5:38 pm
Hi aapje,

Could you please disconnect, then go to Preferences -> Advanced, tick "Use Windows DNS System for Full DNS", reconnect and try again.

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

aapje

Posts: 4
Joined: Thu Jun 28, 2018 12:36 am

Post by aapje » Mon Jul 06, 2020 11:11 pm
Mon Jul 06, 2020 5:38 pmEric wrote:
Hi aapje,

Could you please disconnect, then go to Preferences -> Advanced, tick "Use Windows DNS System for Full DNS", reconnect and try again.

Regards,
Eric
Hi Eric,

Thanks for the suggestion. I'm afraid that did not fix the issue.
Image

Do you need any additional logging for this situation please let me know!

kderby

Posts: 2
Joined: Tue Jul 07, 2020 12:51 am

Post by kderby » Tue Jul 07, 2020 12:56 am
There's something wrong with Win 10 v.2004 that's causing this issue.

I spent some time this weekend trying to troubleshoot this issue, and found that it's occurring on machines that have applied the v.2004 feature pack upgrade that are experiencing this issue.

I was able to remove it from a machine that had it, and this exact issue stopped occurring. Using a second machine, that did not originally have the feature pack, the issue wasn't present. Installing the feature pack broke Outlook (just like on my original machine), and removing the feature pack corrected the issue.

It also impacts the Windows Mail client, not just Outlook.

Part of the problem now is that if anyone installed it a while ago, the ability to roll back beyond 10 days goes away, and you'd have to do an ISO-based reinstall to bring it back prior to the v.2004 upgrade.

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Tue Jul 07, 2020 11:34 am
Hi kderby,

Thanks for your post, much appreciated!

@aapje, I'm afraid with the gateway removed and the DNS option, you effectively have the same setup as you do with OpenVPN GUI. Unfortunately I think Office is maintaining it's connection outside the VPN when using OpenVPN GUI. If you connect with Office already open, you should see the same thing with Viscosity, the connection should not be cut straight away unless office is obeying the gateway change, most software does not do this.

At a guess I would say something is wrong with NCSI over virtual adapters in Windows 10 2004, we've seen a few weird issues with this release. If you're unable to rollback to 1909, you may with to consider using a split tunnel setup if possible instead. We'll see if there's anything we can do for the next release.

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

kderby

Posts: 2
Joined: Tue Jul 07, 2020 12:51 am

Post by kderby » Wed Sep 09, 2020 8:35 pm
Has there been any progress on this?

Eric

User avatar
Posts: 1146
Joined: Sun Jan 03, 2010 3:27 am

Post by Eric » Thu Sep 10, 2020 10:06 am
Hi kderby,

I'm afraid there is not much we can do about this as we cannot control how Windows checks network connectivity. We have made reports to Microsoft. The problem even effects Windows built in VPN protocols like PPTP/L2TP. The problem does appear to be fixed in Windows 10 20H2 (Insider builds) due out soon hopefully.

We have made some adjustments in the latest beta to try and fool Windows into checking NCSI at a different stage but I'm afraid it is still hit and miss, you're welcome to give it a go - https://sparklabs.com/support/kb/articl ... -versions/

Regards,
Eric
Eric Thorpe
Viscosity Developer

Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs

pat

Posts: 1
Joined: Tue Oct 22, 2019 9:16 pm

Post by pat » Sat Sep 19, 2020 2:07 am
Hi

I can open a new thread if needed, but as I had a similar issue wanted to put my feedback, and not create duplicates.

I am seeing similar behaviour with office 365 hosted, when we connect to the full tunnel VPN, with no restrictions.
However what I have noticed kderby, is in my situation, if I open outlook first then connect to the VPN, I am not presented with the "we are unable to connect ...", and outlook works fine. The same with the other 365 apps such as word, excel if I open the app before connecting to the full tunnel then everything seems to work, but as soon as I close the app and re-open it fails.

@Eric if I use the same config but from an openVPN client native. This issue does not occur and 365 apps behave as expected, and always works regardless of which order I launch apps.

Platform Windows 10 - 2004
Viscosity: 1.8.6(1682)

Regards
Pat
18 posts Page 1 of 2