I belong to the CheckPoint list server and a very similar discussion is happening over there referencing Outlook over a VPN between CheckPoint firewalls.
Could this problem be related to Tunnel overhead and packet fragmentation? I think this might be a problem with Microsoft's implementation of the TCP/IP stack and large packets over 1500 MTU. Outlook might not be very happy with fragmentation. There is a registry setting for the end station that forces the MTU to 576 for any packets not destined for the local subnet. This is cut and pasted from http://support.microsoft.com/default.aspx?scid=kb;EN-US;q314053 EnablePMTUDiscovery Key: Tcpip\Parameters Value Type: REG_DWORD - Boolean Valid Range: 0,1 (False, True) Default: 1 (True) Description: Setting this parameter to 1 (True) causes TCP to attempt to discover the Maximum Transmission Unit (MTU or largest packet size) over the path to a remote host. By discovering the Path MTU and limiting TCP segments to this size, TCP can eliminate fragmentation at routers along the path that connect networks with different MTUs. Fragmentation adversely affects TCP throughput and network congestion. Setting this parameter to 0 causes an MTU of 576 bytes to be used for all connections that are not to computers on the local subnet. EnablePMTUBHDetect Key: Tcpip\Parameters Value Type: REG_DWORD - Boolean Valid Range: 0,1 (False, True) Default: 0 (False) Description: Setting this parameter to 1 (True) causes TCP to try to detect "Black Hole" routers while doing Path MTU Discovery. A "Black Hole" router does not return ICMP Destination Unreachable messages when it needs to fragment an IP datagram with the Don't Fragment bit set. TCP depends on receiving these messages to perform Path MTU Discovery. With this feature enabled, TCP will try to send segments without the Don't Fragment bit set if several retransmissions of a segment go unacknowledged. If the segment is acknowledged as a result, the MSS will be decreased and the Don't Fragment bit will be set in future packets on the connection. Enabling black hole detection increases the maximum number of retransmissions performed for a given segment. Anyone willing to modify their end station to force an MTU of 576 and discovery of "blackholes" and report the results. It would be most insightful to see the pre and post registry network sniffer traces of Outlook traffic. I don't have time now, but I think this could be the issue. I think it may be an end station problem. -----Original Message----- From: Larry Letterman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 7:58 PM To: [EMAIL PROTECTED] Subject: Re: Confused about MTU size [7:54689] I had the same issue with outlook, its real slow when accessing Imap mail. I set the MTU, adjusted other things, etc..nothing seems to fix this issue for me. I set up Netscape 6.2x messenger/mail. Installed the mail client for Imap mail, and it works fine...sometimes it hangs for a second or two, but not anything like outlook.... Larry Creighton Bill-BCREIGH1 wrote: >I may be way out of line, but there aren't any access lists which may be >prohibiting the IMAP ports used by exchange, are there. I ran into a config >mess with DMZ's and access lists for a beta product test once. And that was >what we saw - all worked (http, proxy, etc.) but Exchange was gone. Turned >out to be some Checkpoint and access-list tweaking. > > >-----Original Message----- >From: JohnZ [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, October 02, 2002 5:43 PM >To: [EMAIL PROTECTED] >Subject: Re: Confused about MTU size [7:54689] > >Thanks Priscilla, I definitely don't mind even if it was criticisim >especially coming from some one of your caliber. Thank you for the pointers >and I will do some more deligant troubleshooting. And yes Mike it is outlook >that refuses to work properly. There is no problem browsing, home user is >able to copy files of all sizes with out any problems. We can ping the email >server from the user's workstation heck I am even pc-anwhered into his >machine. But as soon we start outlook it just hangs. I will further >investigate the router's config although it's using a template that's >working elsewhere under different service provider without a hitch. >""Priscilla Oppenheimer"" wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >>I agree that it doesn't sound like an MTU problem. There are often >> >problems > >>with MTU when DSL, VPNs, tunnels, etc. are used, so people might jump to >>that conclusion. But e-mail messages are often very short and would easily >>fit into most MTUs even after overhead. To test whether it's an MTU >> >problem, > >>try some oversized pings. >> >>The MTU issue occurs when a full-sized packet arrives at an interface that >>needs to squeeze it into an MTU along with the overhead. The interface >> >could > >>fragment, but maybe the application or transport layer set the Don't >>Fragment bit. Quite a few applications do that as part of their MTU >>discovery process. The problem is made worse if there's an access list >> >that > >>is blocking the ICMP "Fragmentation required but DF bit set" message. >> >>Here's a Cisco article on MTU: >> >>http://www.cisco.com/warp/public/105/56.html >> >>This isn't a criticism of the original poster, who was already doubting >> >the > >>people who told him it was an MTU problem, but it does give me a chance to >>get on my soapbox about troubleshooting methods. A lot of people >>troubleshoot using the technique we learned in grade school to match items >>from Column A with items from Column B. ;-) Column A has network types and >>Column B has most common problem for network type. It's important to know >>about common problems, but it's just as important to gather data, research >>symptoms, and use logic and reasoning. >> >>Cisco's troubleshooting method really does work: >> >>1. Define the problem. >>2. Gather facts. >>3. Consider possibilities. >>4. Create an action plan. >>5. Implement the action plan. >>6. Observe the results. >>7. Do problem symptoms stop? >> >>If no, go back to 4 or possibly to 2. >>If yes, problem resolved, document the results. >> >>OK, off my soapbox now! :-) >> >>_______________________________ >> >>Priscilla Oppenheimer >>www.troubleshootingnetworks.com >>www.priscilla.com >> >>[EMAIL PROTECTED] wrote: >> >>>I found email to be a touchy thing... Especially when dealing >>>with M$ >>>0utlook. Are you sure it's the MTU size that's the problem >>>with email. >>> >>>I know in our situation, I had to add the mail server name & IP >>>to the host >>>file of the remote pc. Some times we experience some latency, >>>but for the >>>most part it's only been about half a minute. >>> >>>Cheers, >>>mkj >>> >>>-----Original Message----- >>>From: JohnZ [mailto:[EMAIL PROTECTED]] >>>Sent: Tuesday, October 01, 2002 8:55 PM >>>To: [EMAIL PROTECTED] >>>Subject: Confused about MTU size [7:54689] >>> >>> >>>Can some one explain clearly how does MTU size affect windows >>>applications >>>where these applications won't work over a network link. I have >>>a certain >>>home user that can establish a vpn tunnel through a DSL to >>>corporate network >>>and all applications will work except for email. The only >>>difference is a >>>cisco router in between the homeuser and corporate network. >>>Without this >>>cisco router (with homeuser directly attached to DSL modem) >>>there are no >>>problems. Some one mentioned MTU could be the problem, but if >>>the frames are >>>larger then MTU don't they get fragmented and re-assembled at >>>the other end. >>>How could MTU size fail single application while everything >>>else works fine. >>>Thanks for any help. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54789&t=54689 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]