03-01-2009 10:58 PM - edited 02-21-2020 03:19 AM
Hi,
I have a trick case with a ASA 5520 and a intranet in Internet Explorer. There is a picture, flash and document manager and the trafic get blocked when using IE, but not in Firefox. The intranet is using port 80. Anyone else seen something like this?
03-03-2009 06:29 AM
03-03-2009 09:50 PM
Please add the following command on the 5520 box:
policy-map global_policy
class inspection_default
inspect http
Also can you do the clear asp drop and show asp drop a little quicker? :). It seems a lot of other traffic also came about (I know this might not be possible on a busy production box).
Regards
Farrukh
03-03-2009 11:03 PM
Hi,
I have tried to add inspect http, but with the same result. I will try to do a clear asp drop on nighttime, with less traffic:-)
regards
03-04-2009 10:45 PM
03-07-2009 05:45 AM
Any updates on this issue? I would capture both IE/Firefox traffic using a packet sniffer and compare the two. You can also use the capture command on the ASA with the asp-drop keyword
Regards
Farrukh
03-09-2009 12:42 AM
Hi,
I have not found the time for testing, but it seems like FF is requesting on port 3840 and IE on port 3807. But lately we have had some websites turning up "white" with the status line showing "Done". Wondering if this is the same issue.
Regards
03-09-2009 12:33 AM
The port number should not make a difference
Regards
Farrukh
03-09-2009 12:55 AM
Hi again,
No, i know, but it is the only difference i see. Another possibilty is the way the browser acctually "reads" the different webpages.
03-09-2009 02:10 AM
Did you try permitting the traffic in both directions? (assuming the firewall to be a stateless pakcet filter e.g. ACL)
Regards
Farrukh
03-09-2009 02:34 AM
Hi,
Yes, i tried that, we see on another websites that turns up "white" that the ASA logs an Acess Denied with Flow Closed By Inspection message the first time, when they press F5 the webpages come up the way they should. Strange. It seems that something in this traffic from IE is not the way it should be. Also, Wireshark logs Bad Checksum on this traffic. FF is working from the same computer to the same site seconds after.
Regards
03-09-2009 03:39 AM
Double check for any MTU/speed/duplex issues. Specially on the server's interface connected to the switch.
Regards
Farrukh
03-09-2009 04:02 AM
Hi,
Found a solution, If i enable a expect rule in filter properties that say to truncate url for the spesific web server it works in both browsers. But, can you tell me the issues about truncat long urls?
Regards
03-09-2009 06:26 AM
The url-truncate feature is only applicable when you have the 'filter url' command configured as far as I know. For more information have a look at this link:
Regards
Farrukh
03-09-2009 11:36 PM
Hi,
We are using a filterign server. Serveral of my cases with IE browsing trouble was solved when i made an exception for the trouble webservers (pages).
But, what is the security issues with url-truncate?
Thank you very much for your help so far.
Regards
03-09-2009 11:47 PM
As I said earlier, I doubt the URL-truncation is causing the problem. The longurl-deny argument is the one really used to control the security (because some very long URLs can embed scripts etc.)
"The longurl-truncate option causes the security appliance to send only the host name or IP address portion of the URL for evaluation to the filtering server when the URL is longer than the maximum length permitted."
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide