VPN - Exchange to Outlook and Shares

[rhomer]

Does anyone have a technical reason as to why I am having issues with Microsoft Outlook communicating with Microsoft Exchange and Mapped network drives on sites connected to a central site via VPN tunnels.

The 2 remote VPN (PIX 505) sites are connected to a central PIX (520),all NT 4 machines (same builds), where some remote users can use Outlook and access shares on servers on the main site and others users on the same remote LAN cannot. It is not consistent either, and this inconsistency is across both VPN remote sites, sometimes they work and sometimes they don't!?!?? I am using Cisco 2900XL series switches on all sites.

I have read in other conversations about changing the MTU size on the client machines, does anyone know whether Cisco / Microsoft have a recommendation about this ? Should this be done server site as well ?

If this is the recommended Fix, why do I see an intermittent problem with no logical reason as to the machine/s it it happening to ?

Also if the firewall's are dropping packets due to MTU size would this be a viewable entity in the error logs ?

Hope you can help, can I suggest that Cisco put a solution to this in the PIX VPN FAQ ? it must be a common problem with more and more corporates looking at utilising VPN's to reduce costs.

Thank you in advance.

[ssoberlik]

Are you using a WINS server or HOSTS files for the remote site? I know that browsing the network doesn’t work consistently over the VPN. Other than that, talk to Cisco and let me know what they have to say.

[2d-ruttino]

Usually, when I have seen similar problems, they were linked to name resolution, browsing or MTU issues. Sometimes for Exchange, RPC binding order has come into play.

[dbaron]

I see the same probelem with IPSEC vpn between a 3002 and 3005. Usually Echange traffic or large file transfers. Lowering the the MTU on the client machine aleviates the problem.

Cisco will not (can't) give me a white paper or a good technical explination into exactly why large frames sent into an IPSEC tunnel cannot be fragmented and reassembled at the remote end.

Here is the information I have gathered. Exchange will send a full size frame to the client such as 1500 bytes.

Cisco says that the exchange application is setting the "don't fragment" bit in the packet to 1.

IPSEC encapsulation at the VPN device adds another 26 bytes (I think) to the frame.

So now the frame is exceeding the 1500 byte maximum and needs to be fragmented.

I'm not sure if the packet is getting fragmented and not reassembled or whether it is being dropped altogether. All I see at the rempote site VPN device is IP reassembly failures count increasing while this is happening.

If the client machine is set to have an MTU of 1400, it all works fine.

Anyone have a good technical explanation to what exactly is happening? Are IP headers getting lost/scrambled by deframentation of IPSEC traffic???

[gprokscha]

I have a very similar problem. I am able to fully ping every device on the network that I am connected to via the VPN clinet (98 machine) but as soon as I use a different protocol (udp/tcp) nothing works. There are no ACL's in the way that could be blocking traffic. BTW, does anyone know how to change the MTU on a 98 machine?

WOuld it alos be possible to change the MTU to something larger, ie 1550, to allow for the extra encryption info?

Cheers,

[samiller]

There is a utility called setMTU.exe included with the VPN Client files. This program SetMTU.exe should be located in the same directory as the VPN program files. For example, on my computer the location is c:\program files\cisco systems\vpn client\setmtu.exe. I don't know about changing the MTU to something larger, don't know if that would work or not.

[drynkowski]

The maximum frame size is inherently limited by the fact you are using Ethernet. If the frame you are transmitting consistantly exceeds the MTU by only a few bytes, you will have a lot of overhead because the extra 50 bytes needs to be encapsulated into a whole new frame (i.e. double the frames). The best thing you can do is reduce the MTU AT THE CLIENT, so the source frame (with the VPN header) is just under the lowest MTU in the path back to your server (usually the tunnel). The latest cisco VPN client software automatically adjusts MTU on the workstation. If you're using a PIX or 3000 series to terminate your tunnel (LAN to LAN), you should adjust the MTU at the client manually (through registry entries usually)

[dbaron]

I agree, lowering the MTU on the client has resolved the problem on my remote connections but visiting several hundred machines to do this isn't cost effective. If the problem could be corrected on the VPN devices then I'd be much happier.

I'd still like to see a good technical explanation from Cisco as to why large fragmented IPSEC encrypted frames can't be fragmented & reassembled at the remote VPN device.

[sheddsj]

I have been seeing similar problems but with different cisco devices than you are using... I see users that connect both from our site-to-site tunnel and from our remote access sessions having problems with Outlook... We have accepted for now that Outlook XP does not work at all and Outlook 2000 works better.. Some can check and send email perfectly, some can check but not reply or send any email and some users can authenticate into the vpn but it takes outlook hours to recieve all of their email.... I would be very interested if someone had a cisco 3000 vs. exchange/outlook paper that I could read for some possible resolutions to these problems.