Internet Explorer - ASA 5520

Unanswered Question
Mar 1st, 2009


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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Farrukh Haroon Sun, 03/01/2009 - 23:20

Most probably the issue is not with the firewall (ASA) and the real issue lies in the browser settings.



Arild Amundsen Sun, 03/01/2009 - 23:29


Thanks for your quick replay.

I tought so to but the intranet is funktion quite well outside the network ex. from my home net. And i get an Access Denied in the ASA logg on traffic to the intranet when i use IE inside my net, but strangely not in Firefox.

Farrukh Haroon Sun, 03/01/2009 - 23:46

Please give more details about the topology, configuration/inspections enabled on the ASA.



Arild Amundsen Mon, 03/02/2009 - 00:04

Http inspection has default settings.

Her are the message i get in tha ASA logg when using IE.

Deny TCP (no connection) from x.x.x.x/2997 to x.x.x.x/80 flags ACK on interface Innside

Deny TCP (no connection) from x.x.x.x/2997 to x.x.x.x/80 flags FIN ACK on interface Innside

Teardown TCP connection 197682186 for Internett:x.x.x.x/80 to Innside:x.x.x.x/2997 duration 0:00:28 bytes 304213 Flow closed by inspection

Access denied URL SRC x.x.x.x DEST x.x.x.x on interface Innside

This is regular http traffic and it is working in Firefox from the same pc and settings.

Arild Amundsen Mon, 03/02/2009 - 00:35

This message comes from the webserver hosting the intranet.

Teardown TCP connection 197682186 for Internett:x.x.x.x/80 to Innside:x.x.x.x/2997 duration 0:00:28 bytes 304213 Flow closed by inspection

I can't understand why inspection is closing the connection when IE is used, but works in FF. Maybe it is something in the way browser handlling the site and is there anything we can set in ASA to prevent/allow this?

Farrukh Haroon Mon, 03/02/2009 - 01:07

I'm still not clear with your topology.

On which zone is your web server? "Internett" zone? From where are you testing ? LAN = "Innside"?

Which version of ASA are you running?

What do you have under IE:

IE >> Tools >> Advanced >> HTTP 1.1 Settings



Arild Amundsen Mon, 03/02/2009 - 01:27

The webserver are not in "my net". We are delivering applications via Citrix to our users. I am testing this from my inside, with the same setting the users have.

So the traffic are like this:

Terminal Server -> ASA -> Internet -> Webserver

ASA version: ASA 5520 with image asa721-k8

And we are using http 1.1 settings

Farrukh Haroon Mon, 03/02/2009 - 01:52

Can you try permitting this 'return' traffic or disabling the HTTP inspection to test this out?

Arild Amundsen Mon, 03/02/2009 - 04:38

Hi again,

I am not very experienced with ASA, so how would turning of http inspection affect the rest of the traffic?

Arild Amundsen Tue, 03/03/2009 - 05:24


Have tried the suggested solutions, but still same errors in the asa log. I have tried with a new asa 5505 with default settings and there it is working, the only differens is that it is a newer image on the 5505 (7.2(2))

Best Regards

Farrukh Haroon Tue, 03/03/2009 - 05:31

Can you post the output of the following command from both boxes:

show run all policy-map

show run service-policy

Then on the troublesome box,

clear asp drop

immediately test the problematic server connection via IE, then paste output of

show asp drop



Farrukh Haroon Tue, 03/03/2009 - 21:50

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).



Arild Amundsen Tue, 03/03/2009 - 23:03


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:-)


Farrukh Haroon Sat, 03/07/2009 - 05:45

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



Arild Amundsen Mon, 03/09/2009 - 00:42


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.


Arild Amundsen Mon, 03/09/2009 - 00:55

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.

Farrukh Haroon Mon, 03/09/2009 - 02:10

Did you try permitting the traffic in both directions? (assuming the firewall to be a stateless pakcet filter e.g. ACL)



Arild Amundsen Mon, 03/09/2009 - 02:34


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.


Farrukh Haroon Mon, 03/09/2009 - 03:39

Double check for any MTU/speed/duplex issues. Specially on the server's interface connected to the switch.



Arild Amundsen Mon, 03/09/2009 - 04:02


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?


Arild Amundsen Mon, 03/09/2009 - 23:36


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.


Farrukh Haroon Mon, 03/09/2009 - 23:47

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."

Farrukh Haroon Tue, 03/10/2009 - 00:04

It could be due to the filtering software not being able to understand the long URL and therefore not makring the right policy decision.

The standby difference does not matter, and your problem should be exactly the same.




This Discussion