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

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.

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

You called us lads. Are you in England?

Chris Weber
Layer9corp.com

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

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.

Steve//

Chris Weber
Layer9corp.com

P.S