Outlook client can’t access MS-Exchange Server over IPSec

0 pts.
Tags:
Application security
Database
Desktops
Encryption
Exchange security
Firewalls
Forensics
Incident response
Instant Messaging
Intrusion management
Linux
Management
Microsoft Exchange
Microsoft Office
Microsoft Windows
Network security
Networking
OS
Routers
Secure Coding
Security
Servers
SQL Server
VPN
Wireless
Hi There, I have a strange problem in a customer. He connects their laptops over IPSec into the corporate LAN and the firewall/VPN server assigns IP addresses from the IPSec Address Pool (different from LAN subnet). There are some Packet Filter rules on the firewall that allow traffic from this IPSec Pool into the LAN, and especifically into their Exchange box for mail and NetBIOS. That's working fine so far, and he can browse the LAN, can ping servers (incl the Exchange box) and can access everything via IP and name. However, when he tries to retrieve mail from the Exchange mailbox using Outlook over the VPN, it times out... I must point out that OWA works fine. I tail the firewall & VPN logs while he's trying to connect and **absolutely nothing** (relevant to this problem, of course) shows being blocked. Before you ask, we have also tried disabling the XP personal firewall as well as the IPSec client's own firewall without success (or obviously I wouldn't be asking here :-) Some details: Exchange 2003 on Windows 2003 Server Outlook 2003 on XP Pro SP2 Firewall/VPN is a Linux-based appliance (Astaro Security Linux) The IPSec client is NCP's Secure Entry Client (www.ncp.de) I am totally puzzled by this problem, and as I'm due to visit them next Thursday if you could throw in some pointers before then, I would be grateful. Regards, Hedgehog.
ASKED: September 26, 2005  11:44 AM
UPDATED: October 10, 2005  3:40 PM

Answer Wiki

Thanks. We'll let you know when a new response is added.

Hedgehog,
The fact that you can browse the subnet once you are VPN’d in makes this an harder to pin down. Usually these issues are relating to name resolution and browsing. I assume you are pushing WINS across the VPN, so that clients can browse. Perhaps also you are pushing AD, and the VPN clients are pulling the address of the AD DNS server.
I would ask you to confirm from a VPN client that they can resolve the Exchange server, but from your email it looks like the VPN clients are in fact connecting to the Exchange server. If I am reading you correctly the timeouts occur when they are downloading email.
Also judging by your message I probably don’t have to tell you that large mailstores will take a long time to download through a VPN tunnel so I am guessing that is not the issue either.
Without seeing a packet capture in front of the Exchange server to show me what communications are transpiring when the session is dropped I can only make guesses, but I would start with a sniffer in front of the Exchange Server.
I would look for resets or TCP repeated connection attempts. These may indicate a protocol issue with some protocol being used that is not permitted through a hop, (I would look at UDP here). Also you can look for TCP Zero Windows that could indicate a buffer filling up on the server.
Another thing you could try is ensuring there is no timeout or bandwidth limits set on the IPSEC clients or Tunnel config.
One other thing to try would be switching between cached and non cached mode in Outlook and see if that impacts the timeouts. Sometimes this can have an impact.

This isn’t much but I hope it helps.

Chris Weber
Layer9corp.com

Discuss This Question: 10  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Ve3ofa
    Is this ALL vpn users or just one?
    80 pointsBadges:
    report
  • Layer9
    Hedgehog, The fact that you can browse the subnet once you are VPN'd in makes this an harder to pin down. Usually these issues are relating to name resolution and browsing. I assume you are pushing WINS across the VPN, so that clients can browse. Perhaps also you are pushing AD, and the VPN clients are pulling the address of the AD DNS server. I would ask you to confirm from a VPN client that they can resolve the Exchange server, but from your email it looks like the VPN clients are in fact connecting to the Exchange server. If I am reading you correctly the timeouts occur when they are downloading email. Also judging by your message I probably don't have to tell you that large mailstores will take a long time to download through a VPN tunnel so I am guessing that is not the issue either. Without seeing a packet capture in front of the Exchange server to show me what communications are transpiring when the session is dropped I can only make guesses, but I would start with a sniffer in front of the Exchange Server. I would look for resets or TCP repeated connection attempts. These may indicate a protocol issue with some protocol being used that is not permitted through a hop, (I would look at UDP here). Also you can look for TCP Zero Windows that could indicate a buffer filling up on the server. Another thing you could try is ensuring there is no timeout or bandwidth limits set on the IPSEC clients or Tunnel config. One other thing to try would be switching between cached and non cached mode in Outlook and see if that impacts the timeouts. Sometimes this can have an impact. Hope this helps. Chris Weber Layer9corp.com P.S
    0 pointsBadges:
    report
  • Stevesz
    Add the exchange server to the hosts file, then try to connect again. Steve//
    2,015 pointsBadges:
    report
  • Poomba1
    You know, if * above 1024 for ports are not open, that'll hoop it. But why not make it easy on yourself and just go https over RPC proxy? If it's Ex2K3 + XPSP2 + OL2K3, hey, https really simplifies things. Cheap out and create you own cert, import it to a client and test. Also, for corporte laptops on the road it works well, we even allow 443 from the internet to really keep it simple. VPN' are no more secure, a holed laptop in a VPN tunnel is more dangerous than a holed laptop going https to Exchange in Outlook. Also, it may not apply but there was a post SP2 fix reletive to VPNs if they were getting fancy with the 127. subnet, but I believe a recent security fix for TCPIP.sys over rides it anyways.
    0 pointsBadges:
    report
  • Hedgehog
    Thanks for all your answers. I was there on Friday and experienced 1st hand the same problems. To answer some of your Q?s, it?s happening on all VPN clients we tried; we already use OWA over https, which works fine, but customer wants to keep using their Outlook clients. And adding Exchange to the hosts file made no difference (if you read my post, stevesz, it doesn?t appear to be a name resolution problem, as I can resolve LAN addresses fine). In particular, to answer Chris in Layer9, I did a tcpdump right on the exit point of the tunnel (the firewall/VPN appliance). I can see ALL traffic passing thru the tunnel in the cases when we pinged anything on LAN from client (pinging both IP & name), when we accessed network shares (on FS and on Exchange), when I telnetted the Exchange on POP and SMTP, etc. HOWEVER, when we run Outlook, NOTHING (!!) shows up on the other side of tunnel. Traffic therefore does NOT even reach the Exchange server. That would, IMHO, rule out any timeout issues because of large mailstores (which incidentally aren?t that big), TCP resets, or full buffers in the Exchange box. I verified the packet filter rules and they allow ANY traffic from the VPN client IPsec pool into the LAN. So I think that somehow Outlook uses a different way of routing traffic other than what?s on the routing table (??!!), sending its requests somewhere else (maybe the default gateway in the wireless LAN of the Internet Cafe we were connecting from). As it was late and had to leave, all that was left to try was to sniff in the laptop where that traffic is going. So I asked the customer to run Ethereal on his laptop while attempting to connect again. I will update the post whenever I hear back from them. If in the meantime you lads have any other ideas, please feel free to post them here. Regards, hedgehog.
    0 pointsBadges:
    report
  • Layer9
    Well this is a good one Hedgehog. You have covered all the usual suspects it would seem. Running Ethereal on the clients side now is a good move, and exactly what I would do. The fact that NO packets are being captured from the Outlook session on the Server side tells us a lot. A question. Is this a SPLIT-TUNNEL? Meaning that the client is still permitted to surf the web from the local gateway instead of using the tunnel. In SPLIT-TUNNELS only traffic to and from the tunnel endpoint will be encrypted. If you experience the problem only from one location then packet captures from the client end will be more useful of course. If this occurs no matter where you attempt to connect from, then it will be harder to pin down. I would look for: 1. Traffic coming from the client side will show up in the sniffer as ESP, so look for Outlook traffic not being encrypted 2. Is the client ARP'ing for anything. Look for ARP requests on the client side. Are they being answered? If the client is ARP'ing for what it thinks is the Exchange Server, then the client is likely misconfigured. 3. Look for ICMP redirects on the client side. Once again this would indicate for some reason the client is not using the Tunnel Gateway and for some reason is sending traffic for Outlook unencrypted. I would not worry about ports being opened on the server side, unless of course there is a packet filtering device between the Tunnel Endpoint and the Exchange server. If the Tunnel Endpoint dumps off onto the same subnet as the Exchange server this would not be an issue. On the flip side of course make sure there is not a packet filter in front of the Exchange Server. This really is a good one. I would like to see packet captures from both ends of the Tunnel (if you want send them to cw@layer9corp.com). Outlook will use the default bound active adapter like any other program. There is nothing special there so I would not suspect Outlook. It is more likely that the Outlook packets are NOT being encrypted on the client end, and are bouncing around the local subnet on the client end. This is a good one hedgehog. Chris Weber Layer9corp.com
    0 pointsBadges:
    report
  • Layer9
    BTW Hedgehog You called us lads. Are you in England? Chris Weber Layer9corp.com
    0 pointsBadges:
    report
  • Pdpjp64
    I've run into the same problem before, modify tghe clients RPC binding order as described in this article: http://support.microsoft.com/default.aspx?scid=kb;en-us;163576 If they still cannot connect, then follow with this Kerberos timeout buffer modification: http://support.microsoft.com/default.aspx?scid=kb;en-us;277741
    0 pointsBadges:
    report
  • Hedgehog
    Hi All, Thanks for all your suggestions. The article pdpjp64 sent applies only to older Windows. We use Exchange 2003 & Outlook 2003 on WinXP Pro. I couldn't find any similar articles on those OS versions. I have suggested RPC over HTTPS to the customer; we'll see how that works. Thanks poomba1. Do you know if I need to allow the Exchange box go through HTTP proxy or just simply allow it to HTTPS out inthe firewall? Do you know what needs to be configured on the Exchange box? Any security implications of RPC over HTTPS that you know of? Chris, I am actually in Ireland, where we also use the term "lads". Where are you based? I couldn't find location in your website (you can send PM if you prefer). To answer your question, yes, it is a split-tunnel VPN. In a sense, there is a packet filtering device between the Tunnel Endpoint and the Exchange server, as the VPN server is in same appliance as firewall, which has strict routing and filtering for ANY interface (incl the VPN "virtual" interfaces). However, we have set rules to specifically allow ANY traffic to/from IPSec pool and Exchange box. This works as we can ping, telnet and access shares on the Exchange box from the IPSec client through the tunnel. It's just Outlook that doesn't work. There is not a packet filter in front of the Exchange Server. I haven't got any captures yet from customer, as he is investigating RPC over HTTPS. I will send them to you offline, thanks for the offer.
    0 pointsBadges:
    report
  • Layer9
    Ireland ye say? Well top o the mornin to ya. I am in Maryland, just outside of DC here in the US. It's nice to talk to one of my peer counterparts across the sea. At this point hedge, it looks like you covered all the bases. Normally problems with outlook connecting to exchange as you are obviously aware, are associated with name resolution. Since you have concluded name resolution to the VPN clients is functioning correctly, and you can ping the exchange server from within a VPN session, we may want to look for the obvious. How large is this clients mailstore? If it is timing out then perhaps the mailstore is still downloading over his link and causing a timeout. BTW, did you ever try changing the Outlook client from CACHED to NON-CACHED mode? Sometimes this helps. If I think of anything else I will let you know. Keep in touch. I would like to visit Ireland one day. Who knows, maybe we will open a Layer 9 branch in Dublin, lol. Chris Weber Layer9corp.com
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following