Recently we had this problem with this problem with an Exchange 2003 server in the HQ and Outlook Clients in a particular branch office. The Branch office connects into the HQ through a site to site IPSec VPN using Juniper Netscreen SSG20 firewalls on either end of tunnels.
The Outlook clients would connect OK but suddenly loose connection to the Exchange server and never connect back. The Outlook Client status will say "Disconnected". The client PCs will however be able to ping the server and network connections look OK. This happened in random times and sometimes when sending large emails.
A deeper investigation revealed that every time the client(s) failed to make a connection there is an error event on the Exchange server with the error "MaxObjExceeded". This started pointing us in the right direction. Yes, a google did show a lot similar issues all pointing to connections over VPN.
The exchange server sends large packets with the DF bit set (Don't Fragment). This when added with the IPSec headers goes beyond the MTU of the Firewalls. The Juniper firewalls by default ignore the DF bits and fragments the packets and forwards it onto the VPN tunnel. Although, these are re-assembled at the client side, this caused problems with the Outlook Clients and they keep re-initiating connections until they run out of connection objects on the Exchange server. That's when they can no longer connect to the Exchange server and the server reports Error events with "MaxObjExceeded" message. Also, from Junipers Knowledge Base, most of the Microsoft applications which heavily rely on "NetBIOS over TCP/IP" are bound to have this problem as these send large packets with DF bit set.
So where do we go from here?? Yes, the only possible resolution was to tune and tweak the Maximum Segment Size (MSS) of all the packets that traverses through the VPN Tunnel. We were to set the MSS on all the TCP packets to 1350. This is sufficiently low enough (as well good enough not to degrade too much of performance) to ensure that the packets never exceeds the MTU of the firewall which is 1500 bytes even after the Encryption overheads.
NOTE: All the following changes should be done on VPN firewalls on both ends
To do this on Juniper Firewalls
vpn-firewall> set flow tcp-mss 1350
This simply replaces the MSS value on all TCP packets for the VPN with the value 1350
To set for all TCP packets
vpn-firewall> set flow all-tcp-mss 1350
However, the previous command for VPN overrides this (for TCP packets destined to the VPN).
Also, added the Path MTU Discovery support on the Juniper Firewalls. This when set makes the firewall to drop any packet set which is more than its MTU (1500 bytes) with DF bit and send an ICMP error messages "Destination not recheable. Packet too big" (ICMP Type3 Code 4) message back to the source along with its MTU value. The source then adjusts its assumed Path MTU so the packet size is less than the MTU and hence there is no fragmentation necessary.
To do this on a Juniper
vpn-firewall> set flow path-mtu
Another option setting that you can try would be to set the Maximum Fragment Size on the firewalls for the generated Fragment size if it is more than the MTU.
To do this on a Juniper
Screen OS 5.4
vpn-firewall> set flow max-frag-pkt-size
Previous versions of Screen OS
vpn-firewall> set flow max
Also, you can disable the TCP SYN check before the session is created for the tunneled packets.
To do this on a Juniper
vpn-firewall> unset flow tcp-syn-check-in-tunnel
To check TCP syn before creating any TCP session
vpn-firewall> unset flow tcp-syn-check
Save the configuration
This resolved the problem for us and should resolve the Outlook & Exchange connectivity issues over VPN even if it is a different VPN device like Cisco ASAs but ofcourse use appropriate commands for those device.
If you have any more thoughts on this or any comments and more pointers, please take a moment to add a comment so should help other users who face similar issue.
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
cheers for taking the time to write this up as I “had” the same problem, and couldn’t find an answer.
the only thing i did different was on the command
set flow max-frag-pkt-size
I used set flow max-frag-pkt-size 1500
I’m having this issue – using site to site vpn Cisco ASA
What to correct on the ASA. Is it the ASA for HQ or ASA atthe branch office? Thanks
Hi, I’m having this issue too. I had change the tcpmss size on Cisco ASA (branch office) and PIX (HQ) change nothing. But the disconnects occured again.
The only difference is, that i donÂ´t get the error “MaxObjExceeded”, I get “MAPI session …exceeded the maximum of 32 objects of type “session””.
For max sessions, look at the MS Exch RPC timeout setting on the Juniper
Liked your article very much .
My addition is to check on exchange if there are more than 32 connection for user you are troubleshooting.
Exchange default is to accept no more than 32 connections from single user.
To change that value see one of the solutions here
I’m having intermittent disconnects and reconnects at our branch office between client outlook 2007 and exchange 2003. The client says trying to reconnect….it takes a random period of time before it reconnects to exchange. Exchange event viewer shows MAPI session…”cn=username exceeded the maximum number of 64 objects of type “session”” i changed the value from 32 to 64 but we are still experiencing the same problem.
i’m starting to think it has to do with the VPN connection as stated above. We have a ASA 5505 at our branch office.
Thanks for this article.. we had the same problem
I have exactly same problem. The Outlook clients would connect OK but suddenly loose connection to the Exchange server and never connect back. I still can access shared folder of the outlook exchange server.
This happens to me after I have launched VPN ip sec system. Previously I used leased line and had never have any trouble.
When the outlook loose the connections I have to restart Exchange server every time to get it going. but not so long the problem occurs again and that’s nightmare.
I have read this article and it is really big hope for me but..
my system doesn’t have any firewall device. the only firewall found is on the cisco RV042 router but there is no MSS setting. there is only MTU setting.
How can I fix this issue.
we had the same issue with our branch office connected via SSG-5 to the headquarter. Changing the values above did not help, but after deactivating the “Microsoft RPC” ALG, the problem went away. Another possibility would be to increase the service timeouts for exchange.