Our 80-user network has a full T-1 Internet connection protected by a PIX firewall running PIX ver. 5.1(2). We have about a dozen remote users connecting to the network using Cisco Secure VPN Client v 1.1. In most cases, it works acceptably well. However, I have one user connected to the Internet via a cable modem (specifically a Cisco uBR900) who is getting a very slow connection to us. His PC is running Windows 98, second edition. He is able to access the Internet very fast, it's just his encrypted connection that is slow. He always is able to connect and get authenticated on our NT domain, access our Exchange Server, telnet to UNIX hosts, etc. It's just painfully slow. I tested his connection using a ping tool (Novell's ping.nlm) that will perform many concurrent pings to multiple IP addresses and shows cumulative, real-time statistics on the pings. I started pinging his real, ISP-assigned IP address, and at the same time, the private IP address that the firewall assigns him for the encrypted connection (the address that starts with 192.168.x.x.). [Sorry, I don't know the proper terminology.] After several thousand pings, the pings to the real IP address were being answered 99 to 100% of the time. However, pings to the encrypted IP address were only 50% successful. The average round-trip time for ALL SUCCESSFUL pings, real and encrypted alike, was very good (approx. 37.0 ms). His round-trip time was actually better than the 5 or 6 other users' times that I was monitoring at the same time. The problem is the large percentage of pings that don't get answered. And the very consistant number of 50% success rate is in itself rather suspicious. By the way, our other users' ping success rates were all 100%.
Since no one else is having this problem, I can only conclude that the problem resides on the user's PC, cable modem, or ISP. Any ideas, anyone?
Since youre other users arent having a problem, I doubt upgrading the PIX will fix this but you might avoid all the other issues in that platform. The release notes for 5.1(4) show a lot of fixes so it wouldnt hurt to move to the latest code in your platform. All 5.1x, 5.2x and 5.3x platforms are still early deployment so youll certainly want to move to the first general deployment version when its out. In the meantime, keeping the code fairly current is a good idea.
That said, I would check the PIX debugs to be sure the tunnel is staying up. Some ISPs filter traffic or share IP addresses with multiple users that will keep an IPsec tunnel from being formed at all but inconsistent responses like that? I dont know. You might call the ISP and see if they have any filters or if they support this at all. If not, you might need to look for an ISP that does.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...