Skip to content
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:
Routing table with Viscosity:
Any further help would be much appreciated.
Thanks for the suggestion. I'm afraid that did not fix the issue.
Do you need any additional logging for this situation please let me know!
Office offline after VPN connection
Got a problem with Viscosity or need help? Ask here!
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::89061cd0: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.
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::89061cd0: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.
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
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
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
Mon Jul 06, 2020 1:33 pmEric wrote: Hi aapje,Hi Eric, thank you for taking the time to respond.
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
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
OpenVPN log:
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.
Code: Select all
(I've redacted the hostname and ip address)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,,
Routing table with Viscosity:
Code: Select all
Routing table with OpenVPN:
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
Code: Select all
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.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
Any further help would be much appreciated.
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
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
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
Mon Jul 06, 2020 5:38 pmEric wrote: Hi aapje,Hi Eric,
Could you please disconnect, then go to Preferences -> Advanced, tick "Use Windows DNS System for Full DNS", reconnect and try again.
Regards,
Eric
Thanks for the suggestion. I'm afraid that did not fix the issue.
Do you need any additional logging for this situation please let me know!
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.
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.
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
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
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
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
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
Viscosity Developer
Web: http://www.sparklabs.com
Support: http://www.sparklabs.com/support
Twitter: http://twitter.com/sparklabs
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
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