Citrix over VPN

[WAYNE COOK]

I have two sites in my network that have a DSL link to the Internet which they use to connect via VPN to Head Office. They both have a PIX 501 and use Citrix. They both have an ISDN link for back-up. Over the VPN, both sites are experiencing periodic "drops". They lose their Citrix sessions. over the ISDN back-up link, they never have the problem. We have had both DSL circuits checked and they always come back clean. These are the only two sites in a 50 site network using VPN and the only two sites having problems.

Are there some parameters I should be changing to compensate for Citrix over VPN?

[Richard Burts]

Wayne

I am not sure that it is the issue here, but a frequent problem with running over VPN is the additional header length introduced by IPSec. If the application is sending max size frames (or near max size) the additional header of IPSec may mean that the frame may require fragmentation. If the application sends the frame with the dont frament bit set (and many TCP applications do this) it may mean that the packets will be dropped since they need fragmentation but can not be fragmented.

You might try decreasing the segment size of the end stations (or look for some parameter within Citrix) and see if it improves things.

HTH

Rick

[WAYNE COOK]

I did some ping tests and found that at 1272 bytes, the packet did not get fragmented but at 1273, it did. I have changed the tcpmss value on the PIX from 1380 to 1200. I'll let you know if that fixes the problem.

Wayne

[r.vdoever]

You did this probably from a workstation equipped with the Cisco VPN Client? This client sets the MTU to 1300 bytes, 1272+8 bytes ICMP + 8 bytes IP adds up to 1300 bytes.

The default sysopt setting should be fine, look in the PIX-log for messages like:

602101: PMTU-D packet 1500 bytes greater than effective mtu 1428, dest_addr=192.168.11.3, src_addr=192.168.10.5, prot=tcp

In this case the sysopt setting was set to 0 instead of the default 1380.

Because traffic is following a completely different path, have you checked for any errors, such as excessive packet-loss, Ethernet frame/CRC errors or duplex mismatches on the PIX-interfaces?

[WAYNE COOK]

We believe we have found the problem. The host site connects to one carrier, the remote site connects to a second carrier but between the first and second carrier, there is a third carrier. the problem is an intermittent latency problem in the third carrier's network causing delays to jump to 800 ms periodically.