Exchange traffic through ipsec VPN (Pix to 1720) is inconsistent

gguhin · ‎06-17-2003

I was able to ping the mail server in Fairbanks and log into Outlook and view messages from a users machine. Another user was having problems. I had the user ping the mail server from his machine and then open Outlook. He was then able to connect to the mail server, but the machine I had worked on just before that now displayed "Operation Failed". Outlook was still running but for no reason this error showed up. Their PIX 501 had been upgraded to a 1700 series router with VPN capability in Anchorage. In Fairbanks they still have the 501 in place. It was mentioned that the 501 has a VPN client connection max of 3 and they have 6 or 8 people in the office. I'm am not sure if the 1700 series router to the pix is considered one connection regardless of how many clients pass through the router, or if each client passing through the router has it's own connection.

mostiguy · ‎06-17-2003

A site to site tunnel is one tunnel for a pix. 501 pixen now support 10 tunnels with the latest pix os. The number of users of a tunnel is a non factor, licensing wise.

Are you monitoring bandwidth utilization at both ends? Could that be a problem?

gguhin · ‎06-17-2003

I haven't been monitoring the bandwidth usage, but these are small offices connected to cable modems on each end.

The Fairbanks location has 5 workstations and a MS SBS 2000. The Anchorage office has 5 workstations connecting through the VPN to the SBS.

I have been searching through the forums and the internet and from what I have read, the problem is more than likely a MTU/Fragmantation issue or an access-list issue. That access lists applied allow all ip traffic from source to destination networks and there are no access-lists applied to the inside interfaces.

Most of what I have read, describes Client to Pix connections and access to the Exchange server.

MS KB has an article describing static port mappings for exchange, but I do not think this is the issue since all traffic is being allowed and there is no NAT taking place.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;270836

mostiguy · ‎06-18-2003

If you think it could be fragmentation, then the problem would need to be that windows boxes are sending packets with the dont fragment (DF) bit set. If you do a network capture on the inside interface of the pix, you probably should be able to look for it. PIX OS 6.3 supports a packet sniffing "Capture" feature. I think it was introduced in 6.2.

windows ping can be used to diagnose this too - -f set the DF bit, and -l configured the size, so a ping -f -l 1500 will definitely fail because the path MTU is less than 1500 due to ipsec overhead.

you could also just set the mtu to 1300 on one client machine, and see if that user still has problems.