Outlook/Office 365 is not working when turning VPN on.

Solved
LoxPontus
Here to help

Outlook/Office 365 is not working when turning VPN on.

Hi,

 

I have encountered this problem with my costumer where they connect through VPN from Denmark (another domain), to their HQ in Sweden, and when they do their Outlook stop working. And when they disconnect from the VPN it starts working again.

 

Therefor I wonder if it is some kind of firewall problem? Do I need to allow their domain maybe?

 

Do you have any ideas what to do?

1 Accepted Solution

It looks like I fixed it. I looked around for port openings for O365 and found som other stuff. Then i tried this: I opened port 80 in the FW with the VPN-Network as source towards the server.
And the customer got back to me and told me it looked OK now. But they are doing som testing today.

View solution in original post

16 Replies 16
Nash
Kind of a big deal

What kind of VPN are they using? It is a full-tunnel VPN? Also, is this a third party tunnel or a client VPN?

 

Are they able to ping, tracert the necessary Exchange server when they're on the VPN connection?

 

Can you run a pcap to see what the traffic does when they're on the VPN and trying to use Outlook/O365?

A full tunnel VPN. It's a L2TP VPN through Windows.
I will look into doing some pcap.

Nash
Kind of a big deal

One more thought:

 

When connected to the VPN, can end users nslookup/dig the mail server's name? The autodiscover record's name?

 

Outlook will throw a fit if you're blocking 443 to the autodiscover server.

 

Assuming full tunnel and MX-based content filtering, check if webmail is being blocked on the content filter. Check the event log for potential hits if so. If that's blocking it, you'll need to allow your mail serv.

Uberseehandel
Kind of a big deal

Is Exchange in the MS Cloud, or is it at a local server?

 

Having put everything to do with Office/Exchange/OneDrive at a Cloud location, we have discovered that life has become simpler all round.

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
cmr
Kind of a big deal
Kind of a big deal

I'm guessing you have full tunnel VPN at the customer and the IP address ranges given out for the VPN clients in Denmark don't have a rule on the internet firewall in Sweden that allows them out to Office 365.  Either that or the subnet given to the VPN clients in Denmark has no route on the firewall in Sweden.

 

Otherwise please follow the troubleshooting steps above.

One question on this.
The VPN is set up so they of course get their own subnet while on the VPN. So it is the same for the ones in Sweden and for the ones in Denmark. Do I really need to allow traffic from their local network range?
cmr
Kind of a big deal
Kind of a big deal

As it is on site Exchange then please ignore the internet firewall comment, it shouldn't be the issue.  With the VPN disconnected how do they access the Exchange server in Sweden from Denmark?

Exchange is on-prem but is supposed to move to the cloud in the near future.

Yeah I am with you on that!
Nash
Kind of a big deal

Ah, so subnet overlap is bad. Makes traffic flow go weird.

 

So I would:

 

1. Change them to a unique subnet for the client VPN.

2. If still problem, set them up as split-tunnel if they're on Win10. I have scripts in my signature that you're welcome to grab and butcher.

3. Verify again that nslookup/dig is resolving to the correct IP for their mailserv.

 

Split-tunnel will allow their local traffic (internet, LAN) to split off and go where it normally goes. Saves you overhead on your link.

So having VPN network for example 192.168.3.0/24 and LAN network 192.168.2.0/24 is not good?

As far as I am concerned

 

192.168.2.0/24 (192.168.2.0 - 192.168.2.255)

and

192.168.3.0/24 (192.168.3.0 - 192.168.3.255) is OK

 

but

 

either 192.168.2.0/24 or 192.168.3.0/24 

and 192.168.2.0/23 (192.168.2.0 - 192.168.3.255) is not OK

 

This only become a problems for me when I deliberately want to treat two separate subnets (eg 192.168.2.0/24 and 192.168.3.0/24) as a single supernet (eg 192.168.2.0/23). very often, I wish to deal with /24 networks at the micro level and /23 networks at the macro level, but very few switches and routers allow this.

 

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Nash
Kind of a big deal


@LoxPontus wrote:
So having VPN network for example 192.168.3.0/24 and LAN network 192.168.2.0/24 is not good?

I'm a little confused. Is your VPN "three" and their LAN "two"?

 

If so, no subnet overlap. But your end user's traffic is all going over your tunnel because you've got them on a full tunnel client VPN. You said mail serv is on-prem for your remote users? Full tunnel = they need to use the mail serv's public IP.

 

If your VPN is "two" and their LAN is "two", or three/three, then that's overlap and that's bad.

I will ask them to do that and see the outcome.

LoxPontus
Here to help

A lot of help here, and I appreciate it! A lot of questions from you and I dont know if I have answered all of them. It´s been an intensive couple of days.

But the thing is, we have kind of concluded that it is not a DNS problem. But perhaps a firewall problem. 

 

Do I need to open some ports for Office365 over VPN? Because the only rule that is set up today for the VPN network is: "Allow - Any Protocol - Source: [VPN Network] - Src port: Any - Dest: [LAN Network] - Dest port: Any"

 

And then there is two other rules including soruce "Any" on port 25,443 towards local server.

cmr
Kind of a big deal
Kind of a big deal

How do the client IP addresses compare to the exchange server's IP address.

 

If the clients and exchange server are both in Denmark and you are doing a client VPN full tunnel to Sweden then it locks you out of anything not on the same subnet and can lock you out of anything local at all.  Can they access any local resources when the VPN is connected, printers, other servers etc.?

It looks like I fixed it. I looked around for port openings for O365 and found som other stuff. Then i tried this: I opened port 80 in the FW with the VPN-Network as source towards the server.
And the customer got back to me and told me it looked OK now. But they are doing som testing today.
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels