"We are unable to connect right now. Please check your network and try again later." -- your beloved vendor
Yep, we’ve all seen it and if you’re here reading it, it only means you’ve got enough of it and it is time to resolve Microsoft Windows Known Issue
OpenVPN and other VPN solutions allow to push all traffic through VPN gateway. All good so far, right? To do that default gateway is set.
Again, if you’re here it means that the problem you’ve run into with connectivity “issue” is not a real connectivity issue as you’ve certainly established that even if this message is shown, you’re able to browse internet using browser, icmp/traceroute shows traversing correct path via vpn gateway, etc.
So what the heck is going on here and why Office 365 is so stubborn with its claim?
The problem originates from the fact that Office 365 relies on Network Location Awarness (NLA) which uses Network Connection Status Indicator (NCSI) to decide if “connection” to internet works for it’s call home functions.
The inner works of NCSI is that it goes out and tries to get to following in order to verify “Internet connectivity”
http://www.msftncsi.com/ncsi.txt. Some reports show also following as probed
None of that sounds scary, all reasonable right?
To make sure that traffic is going through VPN gateway, you’ve checked already traceroute (tracert).
The setting to have all traffic pushed via gateway on OpenVPN is:
push "redirect-gateway def1"
That’s where a lot of us were stuck, myself for a year, returning to it from time to time. At one point in time, I thought that M$ needs to check “licensing” and it is some sort of smartness/dumbness there that it does this as first thing whilst starting Windows, prior you get any control and sees its proper public address. To make it worse in troubleshooting I’ve noticed a lot of SYN followed by RST/RST,ACK when connected via VPN and when going out through clear connection it was nicely setting up tcp session. This in itself made me thinking that it is some sort of multi-layer communication, where first connection pull something and prompts Microsoft servers to accept following connections from given IP and as result, after connecting to VPN, I was getting RST and not able to connect.
This was until today – got upset with that problem and spent additional time on testing, redirecting traffic, resetting status, etc. This brought me to discovery of following.
Default gateway or not…?
Looking at ipconfig output and Network and Sharing Center, I’ve discovered that:
a) Network Sharing shows VPN/OpenVPN connection as “No Internet”
b) there is no default gateway on the output of ipconfig.
Hold on… no default gateway? How the heck my whole internet access via VPN (ok outside of Office 365 works then)? No, no proxy, no hijack, no nothing. Checking routing table – all looks ok’ish – as always, VPN routes, + 127.0.0.0 route, etc. Not so good metrics but everything else works.
What the heck? – Solution
This led me to small test – how about if I’d add default gateway manually or would not rely on OpenVPN “
redirect-gateway def1” setting? Going ahead with:
push "route 0.0.0.0 0.0.0.0"
in ccd (client configuration definitions?) of OpenVPN sorted out the thing. As simple as that.
Side info, ccd file is named after host certificate as it connected to OpenVPN. Settings equally could be pushed out to all connecting clients, but that wasn’t my requirement for other reasons.
This helped to get “Internet” access under Network and Sharing Center and see default gateway on ipconfig output.
- https://www.macwheeler.com/windows-10-office-365-cannot-connect-over-openvpn-fixed/ – found it after finding solution, though it shows enforcing it from client side using Windows UI.