VPN Client 4.0 and QuickTime - strange problem

[konigl]

I am encountering a strange VPN issue, wondering if anyone can help me.

Here’s the problem:

When a remote VPN Client tries to download movie trailers from www.apple.com using QuickTime, it never works through the VPN to the ISA Server; but it always work when the computer is connected to the same LAN as the ISA Server, and the computer accesses the ISA Server directly. So it appears to be some sort of issue with the VPN Concentrator and/or Client software. (The “movie trailer” test is commonly used here to demonstrate the speed of the Internet connection.)

Here’s some background:

I have a VPN Concentrator 3005, running the version 4.0.1 software. Remote access Windows computers (98 through XP) are running the latest VPN Client software, also version 4.0.1.

The VPN Concentrator is currently positioned behind a PIX Firewall which runs version 6.2(2) software. A real-world IP address is statically mapped inside the PIX to the private IP address of the VPN Concentrator’s public interface. Access-lists on the PIX permit anything out from the VPN Concentrator’s interface; and anything into it provided the traffic is IPSec, or UDP traffic to port 10000, or TCP traffic to port 10000.

The remote VPN Clients seem to connect to the VPN Concentrator via the Internet without a problem whether using just IPSec, or using transparent tunneling with either IPSec over UDP (NAT / PAT) or IPSec over TCP.

Initial timeouts of the IPSec-only sessions were resolved by forcing keepalives on and changing the Peer Response Timeout from the default of 90 seconds to the maximum of 480 seconds (ForceKeepAlives=1 and PeerTimeout=480, respectively, in the *.pcf files).

The Windows computers access a web proxy (Microsoft ISA Server) running content filtering software to browse the Internet. The ISA Server’s “south” or inside interface is on the same VLAN as the VPN concentrator’s private interface. The ISA Server seems to work fine for the VPN Clients with general web page access. At first, downloads of rather large files (software updates, etc.) would not work; but this was resolved by adjusting the VPN Clients’ MTU size down from the default of 1300 bytes to 1200 bytes.

The “movie trailer” problem happens whether the VPN Concentrator is behind the PIX Firewall, or out in front of it; so I don’t think the PIX is a factor. I don’t think it’s the MTU size, either: I have tuned it all the way down to 576 bytes, on several different computers and versions of Windows, but still have the problem when coming in through the VPN Concentrator.

Anyone have an idea what could be causing this, or how to fix it?

[jsivulka]

At times third party applications are a source of problem. We were facing video traffic problems and this was due to an application being run by one of the users on our net (without the admin's knowledge). Considering that all your non-video traffic is getting across just fine, you should probably try and see if the source of your problem is the same as ours. Another thing might be the bandwidth between your client sys and the concentrator. Although the traffic is being tunneled across, there are no bandwidth guarantees and sufficient video traffic might not be getting across fast enough.

[konigl]

Thank you for your reply, that gives me something to look into further.

So far, I've seen the problem from VPN Clients on DSL connections, cable modem connections, and even LAN connections behind the firewall and in front of the VPN Concentrator. Haven't tried it yet from 56K modem dial-up yet, which is how the majority of users will be connecting. But if it's a bandwidth issue, I would expect things to be worse via dial-up.

Maybe because it's a 3005, and does all its IPSec encryption in software, the overhead in encrypting each packet is not leaving enough bandwidth to move all the packets through the Concentrator in a timely fashion. Specs say the 3005 can provide up to 4 Mbps throughput though. I cranked back the level of encryption from 168-bit 3DES to 56-bit DES early on, to cut down on the workload in theory; and I've been selecting the lowest resolution trailers and slowest download speeds when I have the chance; but I still have the problem.

Maybe I can convince the local Cisco office to loan me a 3030 for testing purposes. They're only about 15 minutes away by car...