International Connections

The first thing I would do is verify that you aren't exceeding the MTU of the link: if you were, then you would get a lot of small fragments being generated and taking a lot of time. Ensure that ICMP Time-Exceeded is allowed through to all hosts; do that explicitly, as the PIX 501 software versions are not particularily good at tracking ICMP.

Second thing is to switch to AES-128 instead of 3DES or even DES, provided the export regulations these days allow you to go beyond DES for the Shanghai location (which might depend on exactly who owns the remote device.)

Third thing I would check is the actual upload and download speeds for the DSL side: "DSL" tends to imply "ADSL", which might be restricted to as little as 128 Kbps upload. The PIX 501 should be able to handle

1.5 megabits/s in theory; I've seen over 1 megabit/s on a lab bench. I've also seen latency really drag down the connection.

Fourth thing... or maybe just after the first... would be to check with netperf or similar exactly what raw throughput you can get, in order to rule out issues such as window sizing problems.

The other issue is the round-trip time (RTT) between your two locations. I'll bet it is close to 400ms or more. You can trim this number down a bit with bigger pipes on both ends (this will decrease the serialization delay on both ends), but going half-way around the world is not the same league as going from New York to California. RTT is not an issue on long lived connections (such as a file transfer) but on web-based applications it can cause a significant problems because TCP setup requires 2 round-trips before the connection is established. If your RTT is 400ms, each TCP connection would require 800ms to establish plus another 200ms on the other end before any data is received. That's a full second.

A ping from my pc in Houston to the server in shanghai gives me a pretty consistent time of 236ms. I'll have to look into Walters suggestions.

I did some pings from houston server to shanghai server using ping x.x.x.x -f -l 1472, etc. With 1472 I received 4 responses of packet needs to be fragmented but df set. I tested this all the way down to

1416, which is when I received a normal response. The MTU on the PIX 501 inside and outside are both set to 1500. Based on this should I change this to 1444? And would that have an effect on the vpn connection. Please excuse my noobness, I'm still learning and have much to go.

Do you have significant amounts of traffic that is not TCP and uses large packets (e.g., uses large UDP packets)?

If not, if the bulk of your large traffic is TCP, then try changing the tcp mss adjustment:

since the default is 1380 as it is, possibly fragmentation over the link is not a significant problem.

If you send out a packet larger than the VPN can carry after all encapsulation and security measures are accounted for, then the packet is going to get fragmented at the IPSec level; I don't recall whether it will get reassembled at the IPSec level or simply sent on as IP fragments. I couldn't tell you the details of why, but the net effect is that your link would get much slower than if fragmentation did not happen.

You can use the 'capture' command on the PIX to produce some tcpdump compatible logs of the initial handshake for a TCP connection; that would allow you to determine the negotiated MSS values.