[SOLVED] VPN interfering with hosted Exchange connection

[HCHTech]

I have a customer with 3 remote workers connecting to his Synology NAS over a VPN. He has a Sonicwall and they are using the Net Extender SSL VPN client, NOT the Synology VPN. They have hosted Exchange through a Go Daddy O365 account, and apparently whenever they are connected to the VPN, they get random disconnects from the Exchange server. Not all the time, but frequently. Each of the remote workers has a different ISP, and are using different computers. All computers are newer laptops with Win10-Pro 64 (native, not upgraded), and everyone is using Outlook 2016.

I haven't seen this exact problem before, and don't have many clients with this combination, but NetExtender is usually pretty bulletproof (IMO anyway). Since I brought the Synology/Sonicwall solution to the table, I really hope it's GoDaddy's problem! I'll be remoting in later to get a look at the windows logs, so I don't have that information yet.

I smell long and unsatisfying support calls with GoDaddy and Dell in my future. Before I go down that path, has anyone run into similar problems?

 

[TurricanII]

Ask the clients to got to myipaddress.com with the vpn connected. Is their web traffic being routed across the VPN through the IP of the HQ office? If so or in any event they may need to change VPN settings to split tunnel or similar rather than full tunnel, so that only the specified minimum traffic is routed via the VPN.

 

[PodnutzPro]

Agreed. The traffic going to the hosted Office 365 account should not be going through the VPN connection, but it most likely is set so that all traffic is being routed through the VPN.

 

[HCHTech]

I thought that was controlled by the "Tunnel All Mode" setting in the client routes section of the Sonicwall's VPN settings. Enabled = all traffic through the VPN. I have this set to disabled, so either that isn't it, or this box doesn't do what I think it does. Maybe I need to set a specific exception to the exchange host. This does give me a direction, though - so thanks.

 

[YeOldeStonecat]

Look in the Sonicwalls VPN policy for a checkbox option "Use this VPN as the default route for all internet traffic"....or something like that. Might be an option in the VPN client adapter....I'm not overly familiar with that Net Extender you mention. It's usually an option...to "force tunneling" or not.

Whoops..just noticed you replied as I was typing this....so you checked the Sonicwall side, look on that VPN client settings too.

 

[YeOldeStonecat]

Just saw your screenshot...there's a second group I put in that Client Routes box....I'll remote into my last client running a Sonicwall and look. It's something like "all remote access IP".

 

[HCHTech]

Ok, digging around a bit, I found that the Sonicwall's VPN client settings had pulled the DNS setting from the computer I was using to setup the thing (in this case, Verizon's DNS). Clearly, these should be blank unless you are trying to override the DNS for VPN connections. We'll see how it goes tomorrow with this change.

Edit: YOSC, I think that setting you're thinking of is "WAN Remote Access Networks", but I think that is necessary only if you want to restrict ALL traffic to going through the VPN, in other words, you would combine it with enabling the Tunnel All Mode. At least I think anyway - one of these days I'll get comfortable with Sonicwalls, but that day is not yet upon us.

 

[HCHTech]

I think the DNS entry was the problem. All 3 remote users have been connected to the VPN since early this morning with no Exchange disconnects. I'm sure the VPN setup wizard was just trying to help me by pre-populating the DNS entries, but typical of Sonicwall, no explanation or help link about the effect of that. Now I know.

 

[YeOldeStonecat]

So the clients were getting the ISPs DNS servers? Instead of the internal domain controllers IP?
While clients should get the DC's IP for internal active directory functionality, since they failed connect to Office 365 public cloud servers, the ISPs DNS servers should have been able to resolve public servers.

 

[HCHTech]

the ISPs DNS servers should have been able to resolve public servers.

There is no domain in this setup - it's a NAS in a home office.

I would have agreed with you that they should have been able to resolve the exchange just fine, it might be that they weren't just getting ISP DNS, they were getting MY ISP DNS, not THEIR ISP DNS. I think one is on comcast, one on a smaller cable company we have around here, and one on a DSL. They were getting Verizon FIOS DNS in my original setup. Just like email, they may "disincentivize" non-customers use of their infrastructure...