The purpose of this document is provide assistance to everyone in addressing latency issues through the firewall specifically port 80 (http) traffic.
Rule out the firewall
First and foremost place a host completely on the outside of the firewall with a public IP address and public DNS and try to load the page. If this shows the same problem then, pickup the phone and call the ISP. If this test works then, proceed reading this document.
http inspection enabled
Issue "sh run policy-map" and make sure http inspection is not enabled. This will cause latency as the inspections expects packets to arrive in order and if they arrive out of order the ASA has to hold these packets to be able to process them.
policy-map global_policy class inspection_default inspect ftp .
. inspect http -----------------------> remove this
To remove http inspection follow this:
policy-map global_policy class inspection_default no inspect http
Make sure there is no CSC module or any other content scanning device like Websense, N2H2 scanning the http traffic and dropping/resetting the connection.
This option is only posssible on the AS/PIX platform. Make sure policing is not configured to throttle the bandwidth used for http access. "sh run policy-map" should show if policing is configured or not.
Issue "sh int | i errors" a couple of times and make sure there are no errors. If there are errors and they do seem to increment, this might cause the problem. Issue "sh int" and figure out which interface is showing these error and address the issue until there are no more errors seen. "clear int" will clear the counters to zero.
speed duplex issues on the interfaces
Interface errors may be caused due to the fact the ASA's ports and the switch ports to which these are connected are not properly configured. Make sure both ends are either configured as auto auto for speed and duplex or both ends are configured with the speed and duplex specified explicitly. Verify speed and duplex config for the client PC and the switch connection as well.
translated ip address may not be allowed by the remote website
The remote websites may not allow certain IP addresses to access their website. If you have another IP address available translate the client PC to look like a new IP address and see if the same page would load. Issue "clear xlate x.x.x.x" where x.x.x.x is the client's inside IP address so, the client can go out looking like the newly translated IP address. Issure "sh xlate debug | i x.x.x.x" and make sure the client is indeed getting translated properly.
load balancing on the ISP side
ISP may have implemented load balancing based on source and destination IP address. Depending on the source IP address that the inside client is getting translated to the ISP may carry the flow via a completely different path than another IP address which might work.
Verify from syslogs (message id 419001) that the flow is not failing due to mss issues. Pls. read about it here and apply the fix for it if this is the case.
The above link only applies to PIX/ASA platform and not to the FWSM platform.
If a layer 3 device in the path has a lower MTU and the packets arrive with the DF (do not fragment) bit set then, if the packet is larger than the MTU, then the layer 3 device will drop this packet. If you suspect this being the case - which can be proved by collecting simultaneous captures on the client and on the server side. MSS can be lowered on the FWSM with the sysopt command "sysopt connection tcpmss <0-65535>" command.
PTR record for the global IP address
Some websites may verify that the IP address trying to load their page is a legitimate address by trying a reverse lookup on the IP address to make sure it has a name associated with it. Make sure the global IP address that you are trying to translate the inside client to, has a name C-NAME and PRT record created in the DNS zone file for your domain name like global.mycompany.com.
threat detection enabled
This feature is not in the FWSM. Issue "sh run threat" and make sure Threat Detection is not enabled. If it is pls. disable that by issuing "no" in front of all the lines that show up for the command "sh run threat" and then try to load the same page again.
no threat-detection basic-threat no threat-detection scanning-threat no threat-detection statistics
PAT may fail and static 1-1 may work
From the number of connections arriving from a certain IP address the remote webserver may appear to be blocking PAT while allowing static (1-1). PAT will show many connections arriving from a single IP address while static 1-1 will only show very few connections arriving from a single IP address.
Some websites are known to block access based on whether or not the IP address trying to access their website is listed in spamhause.org. Make sure the global IP address that the client PC looks like on the internet is not listed here.