Hi, I was using your VPN router to mask current location however my O365 account got suspended (auto-blocked) due to “IMPOSSIBLE_TRAVEL” alert. https://techcommunity.microsoft.com/t5/microsoft-365-defender-blog/detecting-and-remediating-impossible-travel/ba-p/3366017
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.
Thanks, advice appreciated.
Does Microsoft give you a more official explanation?
I use Office 365 and I test vairous VPN everyday (I verify vairous leaks) and I never got this problem.
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.
Do you think authenticating through mobile from Pakistan and using VPN server, in UK, for Laptop will cause this false positive?
This is O365 business. Forced to use chrome or edge.
I suspect its due to authentication being send to my roaming data mobile of Pakistan?
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?
Basically two IP addresses appeared from Pak and UK resulting in this account ban. If it isn’t the VPN router then it must be something else.
For starters, I performed DNS and IP leak checks plenty of times.
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.
I configuerd VPN policies and found that Splunk detected foreign login. So it is likely a historical data anamoly they detected.