The current VPN provider is mullVAD as I wanted fast connections with wireguard protocol. I checked with their team and they said my VPN router wasn’t setup properly.
Subsequently after this incident, I have implemented the following measures (if at all useful):
Setting custom DNS server 1 and 2 to 10.64.0.1 to prevent DNS leaks (private LAN accessible through VPN only)
Checked Internet Kill Switch. This seemed ok from the tests I did, following tutorials online.
I was advised to contact GL.Inet from MullVAD team to help me configure my router properly. Not sure what is proper here to prevent future leaks like this?
Maybe I need a more robust VPN router than this, I honestly don’t know but this was the cheaper option on Amazon at the time.
Wow. I had no idea Microsoft was doing this. It looks like a massive amount of intrusive firepower is going in to eliminating false positives. I am routinely logged into my O365 account from a server in Frankfurt, two in the US, and on a mobile device, so I must be generating a positive alert all the time. It looks like they are inspecting traffic to determine those are false positives.
But it doesn’t sound like it has anything to do with a VPN leak.
You should check for IP leaks on ipleak.com and ipleak.net to see if your real IP address is exposed.
Are you sure you are connecting WireGuard to a Mullvad server that is in the same location as your actual Home location (country, state, city, timezone)? Otherwise, Microsoft may think you are somewhere else.
I do not work for and I do not have formal association with GL.iNet
Just a hint for this situation: In my experience there are plenty differences in O365 Business and O365 Private.
For example I can use Firefox for teams with my business plan, but an friend of mine was forced to use edge or chrome to use it with a private license.
I can imagine Microsoft is doing this in the ‘VPN detection logic’ as well.
@d4devilx Do you want to tell us if you are using a business or a private plan? As far as I know, the school/education plans will be count as business.
The real IP wasn’t exposed when I connected to it, that’s the confusing part. Probably dns leaked due to leaking custom dns empty? Or was authenticating microsoft code through mobile carrier in Pakistan?
Good point … If your laptop is ‘in UK’ and your mobile is Authenticate from Pakistan, there is no error. In fact: be happy that the system is working in this way. It will prevent a lot fraud.
I don’t know if it will work, when your mobile is in the WLAN too, and mobile data temporary disabled.
If Microsoft sees IP addresses from Pakistan and UK, then that would likely trigger a ban. The mobile carrier should not be visible over VPN.
Did you enable Kill Switch on the GL-AR300M and connect WireGuard to Mullvad before opening O365 on the laptop? Even if so, browsers sometimes think it is in a different location than the VPN server, based on other factors, and there is another thread on this forum regarding that. You can also try using O365 in an Incognito or Private browser window.
I understand the theory, but I have often been logged in to my Microsoft account from a server in Frankfurt over an ssh connection, an RDP connection in the US over my own OpenVPN server, and a computer and phone in Portugal. At the same time. No commercial VPN involved at all. So there must be massive, intrusive screening for false positives.