Link to home
Start Free TrialLog in
Avatar of itsadmin1
itsadmin1

asked on

Outlook Disconnected from exchange over VPN

Hello, hopefully someone can help with this very strange issue i'm having with outlook when connected over a VPN.

Issue:
We have an exchange server setup at our main office and 3 remote sites that connect to our main office via site-to-site VPN's.  When a host computer is connected at the main office, outlook works just fine (auto-discover finds profiles, everything connects, can send/receive email).  Outlook Anywhere and Webmail are also working.  However, if a user connects their laptop at one of the branch offices that has a site-to-site VPN and opens outlook it tries to connect for a while, then says disconnected.  If you try to setup a new profile, outlook auto-discovery will find the user account like it should. Then when it goes to the next screen to configure everything - the network connection test passes, the finding account@domain.com settings passes, but then a message comes up saying "The connection to MS Exchange is unavailable, Outlook must be online or connected to complete this action" (during the logon to mail server step).

More Information:
-We are using Exchange 2013 on a  VM with Win Server 2008 R2 Enterprise.
-Host computers range from Win XP to Windows 8 (all are having this issue).
-Outlook on computers ranges from 2007 to 2013 (again, all are having the same issue).
-In the branch offices, the computers are using the DNS server in the main office for primary DNS.
-All computers can ping the exchange server over the VPN (by name and IP)
-All other network functionality over the VPN seems to be working (Network drives, Folder permissions, etc.)
-We have tried completely turning windows firewall off on the exchange server, no luck.

Thanks
Avatar of Dmitriy Ilyin
Dmitriy Ilyin
Flag of Russian Federation image

Do you use TMG or ISA for s2s VPN?
If yes, did you try to disable Strict RPC check?
Right click the VPN rule , click Configure RPC protocol, and clear the Enforce strict RPC compliance check box.
If not... what nslookup of your mailserver in branches - public or private network? (In the branch offices, the computers are using the DNS server in the main office for primary DNS. - i saw this, but need to check). Try to ipconfig /flushdns on client and clear cache on DNS server.
Avatar of itsadmin1
itsadmin1

ASKER

We don't use TGM or ISA.  Our main router is a cisco 1841, at the remote sites we have a cisco 887, and two netgear FVX538.  Two of the VPN tunnels are normal point-to-point IPsec tunnels, and one is a GRE tunnel.

If I do a nslookup of the mailserver it comes back with the private ip address (even if I flush the DNS).    The strange thing is, if I set a different DNS server outlook will connect because the DNS will change to the public IP address.  Using the local IP address over the VPN does not work.
Hi there. With exchange 2013 outlook will connect via HTTPS to your exchange server. as it will connect via https for autodiscover. So as because when coming from the Internet (and not the VPN tunnel), when you change the DNS, everything works, we need to assume that this is traffic being denied (or adulterated) on the VPN tunnel. The traffic is encrypted and therefore configuring the tunnel to bypass and not open the packets destined to exchange might be a good option. but i would start to ask you to do two things:

1- telnet the exchange server name on port 443 from a client machine
2- test the access to webmail from a client machine

both tests of course on the remote office

final question is, do you use a proxy server on the client machines? is it the same (or same rules apply) on the remote and main offices? try to disable it on the browser just for testing purposes.
Good idea.  

From the remote office (over VPN):
-Not able to telnet in over port 443
-Not able to telnet in over port 80
-Can Telnet over port 135 (RPC)

From external network (no VPN):
-Can telnet over 443
-Can telnet over 80
-Can telnet over 135

The strange thing is, I dont have any ACL's on the tunnel except one to permit traffic from 192.168.120.0 to 192.168.0.0.  I dont understand why RPC would work, but 443 and 80 are getting blocked....hum.....
(This particular VPN tunnel im testing is between a Cisco 1841 and a Netgear fvx538; the ACL is on the Cisco, the Netgear has those ports configured in its firewall).
Because you said you are using Exchange 2013 all the client connectivity will be over 443. Unlike exchange 2010 the clients will connect over outlook anywhere even when internally. No RPC over TCP is available for client connectivity on 2013.

Maybe a default ACL denying everything else? it is strange the 135 works but that wont mean that the clients will be able to connect to Exchange.. not with 2013.

try creating a rule that allows 443 (and 80 if that is the case) from the clients to the exchange on the main office.
So I checked the ACL and its pretty basic for the traffic over the VPN:
-Permit ip 192.168.1.0 0.0.0.255 192.168.0.0 0.0.0.255


The strange thing is we can telnet through the VPN on port 443 if we are going from the Cisco network to the Netgear network.  When we try to telnet on port 443 from the Netgear side to the Cisco side it fails.  

I'm confused at why some ports are working over the VPN, and some are not.  I don't think my ACL's should be blocking anything over the VPN.  I'm wondering if the issue has something to do with creating a VPN between a cisco and Netgear router.  It is difficult to troubleshoot the problem because I have no idea what the Netgear is doing, and its diagnostics/reports are highly limited.
ASKER CERTIFIED SOLUTION
Avatar of Antonio Vargas
Antonio Vargas
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Perfect I will do that.  Thanks for your help.