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 Problem
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.
Investigation
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.
Cause
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.
Resolution
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
vpn-firewall> save
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.
Leave a Reply