Openvpn breaks NLA and NCSI services for Windows / Office 365

jcheung22

Hi all. I'm using client version 2.4.6 on a Windows 10 Pro machine. When connected, the VPN seems to disrupt the Windows NLA service such that Outlook/Office 365 no longer authenticates. I can't even sign in to any Office apps to check account status. Of course, Outlook/email no longer authenticates. OWA and the Office portal works fine - that's just https in a browser. What is it about the VPN client that disrupts NLA?
Thanks.

shagdrum

Same issue here. Any solution to this?

Donchik

The method for determining the presence of an Internet connection these services use involves checking for a route. When OpenVPN program creates a VPN tunnel, the routing in the Microsoft operating system is changed for security associated with the VPN tunnel. The two Microsoft services above are unable to recognize the new VPN route and the existence of a way to get to the Internet, so a message comes back claiming there is no Internet access or no network connection. This is a failure on the part of Microsoft and the NLA and NCSI services.

Here is a long post with many people in a similar situation:
https://answers.microsoft.com/en-us/msoffice/forum/msoffice_other-mso_win10-mso_o365b/office-365-cloud-features-do-not-work-when-using-a/b6002038-744a-4d94-a6db-89d4338e99d4

A dangerous way around this is offered partway through the post above and provided here for transparency:
https://www.macwheeler.com/windows-10-office-365-cannot-connect-over-openvpn-fixed/

I use the word 'dangerous' because it involves creating a leak in your system to accommodate the Microsoft flaw.

Recognising that this is a flaw in the way the NLA & NCSI services have been programmed does not help much. Microsoft appear disinterested in resolving this problem and are obviously aware.

Do the OpenVPN team have any plans to resolve this through coding a fix without opening up the link? Do you feel it's possible to "Mimic" the NLA & NCSI service server. My understanding is that these services simply ping a fixed IP to validate the internet connection, so possibly OpenVPN could intercept this and respond positively as needed.

TinCanTech

Donchik wrote The method for determining the presence of an Internet connection these services use involves checking for a route. When OpenVPN program creates a VPN tunnel, the routing in the Microsoft operating system is changed for security associated with the VPN tunnel. The two Microsoft services above are unable to recognize the new VPN route and the existence of a way to get to the Internet, so a message comes back claiming there is no Internet access or no network connection. This is a failure on the part of Microsoft and the NLA and NCSI services.

This is what Microsoft claim the problem is caused by:

M$ wroteThe problem here is that NCSI depends on the default gateway to decide if it should “probe” the network connection to decide if it has an internet connection. The way that NCSI probes the network is it attempts to connect to www,msftncsi,com and retrieve a file called ncsi.txt. If it can retrieve that file, it marks the connection as having internet access. When the VPN adapter connection connects, and NCSI detects that a connection was made on an adapter interface. NCSI will attempt to probe the connection, but since there is no default gateway on the VPN adapter it attempts to send the probe packets out the adapter with a default gateway and that fails since the VPN connection is active.

Source:
Office 2013 reports no internet connectivity with VPN connection
https://blogs.technet.microsoft.com/the_microsoft_excel_support_team_blog/2014/03/24/office-2013-reports-no-internet-connectivity-with-vpn-connection/

Note:
Third-party VPN client stops Internet connectivity in Windows 7 SP1 or Windows Server 2008 R2 SP1
https://support.microsoft.com/en-us/help/2964643/third-party-vpn-client-stops-internet-connectivity-in-windows-7-sp1-or

Maybe they just fixed Win10 later on ..

TinCanTech

I corrected the source above.

Donchik

Hi TinCanTech,

Many thanks for the update. Can you confirm if a Windows 10 hotfix exists? I like many are still locked out of Office and MS Account when OpenVPN is up and running.

If not, do we have any OpenVPN fixes in the pipeline?

Cheers
Donchik

TinCanTech

Donchik wrote Can you confirm if a Windows 10 hotfix exists?

I cannot.

Donchik wrote do we have any OpenVPN fixes in the pipeline?

No.

You could try adding something like:

allow-pull-fqdn
route www.msftncsi.com net_gateway

to your client config .. but that is only a guess and I do not use M$O so do not have a way to test or verify the result.

Donchik

When you are connected to the VPN, all your traffic goes through the VPN default gateway. By adding this configuration, you are basically instructing the OpenVPN to add a static route for the hostname through your default gateway.

Basically, all requests done to 'www.msftncsi.com' will bypass the VPN tunnel, which can be considered as a leak.

I was hoping for OpenVPN to be looking for a resolution from Microsoft. I doubt they'd listen to me, but would hope OpenVPN as a team would have more "Clout" with them

TinCanTech

Microshaft know exactly how OpenVPN works, they have even cloned it on github

FYI: M$ own github, they paid $7BN for it

So, they have chosen to do things this way deliberately ...

jca1981

im getting same problem with openvpn 2.4.9 windows 10 and pfsense.
anyone found a sollution without setting manual gateway on all of our machines.

starless

Hi,
I'm having the same issue with OpenVPN 2.4.9 on Windows 10, and I cannot fix it even adding a default gateway manually.

Our VPN is already configured to use the local default gateway for all destinations, except for destinations in the company LAN which will use instead the VPN gateway. The "route print" command confirms this.
But the default gateway in the TAP network interface is still empty after connecting.

I tried anyway setting the default gateway to the local default gateway in the TAP network interface, but this is not enough, NLA still breaks.

Any clues?
Thanks.

GodFire62

Same issue here.
There was a fix in windows 7: https://support.microsoft.com/en-us/help/2964643/third-party-vpn-client-stops-internet-connectivity-in-windows-7-sp1-or

But it seems that Microsoft does not care about it in windows 10...

TinCanTech

For the record:

OpenVPN does not break these Microsoft services.

Technically, the problem is that Microsoft does not respect well established networking principles.

Your choices are:

Do not use Microsoft.
Complain to Microsoft.
Do not use a VPN.
Pay for expert help.
Run your own VPN server and see if you can screw Microsoft.

There is little to no chance that OpenVPN will develop code to pussy-foot around M$ garbage.

Krasnian

This fix seems to work;

HKLM\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\DisablePassivePolling
Key Type: DWORD
Value: Decimal 1 (True)

If the entry doesn't exist you must create it

Nevets

Hi,

We were having the same issue after migrating to Office 365. What seems to fix my issue was adding the default gateway on the tunnel interface (as already mentioned in this thread). As this is not an advised way and also not practical if you have multiple OpenVPN servers. So we needed another solution.

After carefully investigating the problem we found that you can detect the problem with the following PowerShell command

Get-NetConnectionProfile

Name             : some-network
InterfaceAlias   : Ethernet
InterfaceIndex   : 1
NetworkCategory  : Private
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic

Name             : my-domain
InterfaceAlias   : TAP-Interface
InterfaceIndex   : 2
NetworkCategory  : DomainAuthenticated
IPv4Connectivity : NoTraffic
IPv6Connectivity : NoTraffic

This command gives you the following values for your OpenVPN TAP-interface IPv4Connectivety status:

NoTraffic: you are having internet connectivity issues

Internet: all is well

After some more investigation I was able to solve this issue not by adding a default gateway but something similar an additional default route. This additional default route can be added client side or server side (my preferred option).

Client side you add the following line to your configuration:

route 0.0.0.0 0.0.0.0 vpn_gateway

Server side you add the following line to your configuration:

push "route 0.0.0.0 0.0.0.0"

As you my notice this route will probably never be used as OpenVPN already adds two routes for smaller network segments (0.0.0.0/1 and 128.0.0.0/1) which have a higher priority. But it seems to trick the NLA service in thinking that you are connected to the internet and allowing you to access Office 365.

Hope this helps you all.

Additional references:

http://www.gizfun.com/en/node/11

denwood

Nevets, this little tip resolved an annoyance for our organisation using OpenVPN. Despite the "No Internet Access" message with VPN connected, we had zero issues over the last year ... until installing a few Office 365 desktop apps. We don't route all traffic over VPN, particularly with all the demands of remote working right now. Outlook 365 failing to connect to Exchange and crashing while OpenVPN is in use is a show stopper :-( I was able to manually add a default gateway to the TAP interface on a client (also fixes the issue), but the prospect of doing this on 60 clients was not appealing at all.

Adding

push "route 0.0.0.0 0.0.0.0"

to our pFsense OpenVPN server configuration solved the issue very nicely for the entire organization. Thanks again for posting this solution!! :-)

Both the Push and default gateway are not very obvious solutions if searching google so I registered for the forum specifically to thank you and hopefully raise the google ranking a bit :-)

Cheers,
Dennis.

TinCanTech

denwood wrote Adding
push "route 0.0.0.0 0.0.0.0"

Is a sure fire way to screw you up.

This thread is utter nonsense.

denwood

Well, it works. Zero user complaints. We're routing seven networks via VPN IPSEC tunnels, combined with about 60 users via OpenVPN. No issues. We don't force all traffic via the VPN due to our covid/remote demands.

Add the push 0.0.0.0, and the TAP connector gets a gateway on Windows 10 for remote clients. Remove the push and no gateway is defined. I should mention that this has not been an issue until we installed office 365. Outlook will not work correctly with a VPN connection active.

TinCanTech

denwood wrote I should mention that this has not been an issue until we installed office 365. Outlook will not work correctly with a VPN connection active.

That is because Microsoft do not agree with your use of a VPN.

Rather than twisting your network and users to the point of insanity, you should ask Microsoft for assistance.

FTR; I already know why Office-365 does not co-operate with you and I don't even use M$ crapola.

itsangiep

Setting the Gateway within the adapter and adding the route to the server config fixed this issue for me.