ā07-26-2012 04:37 PM - edited ā03-11-2019 04:35 PM
Hello,
I got a strange behavior. I want to stop IM for some specific IP, when I enable Inspection for IM (policy-map inspection im to drop the traffic) MSN is actually blocked how ever this users cannot send emails.
Any idea or bug?
ACL to allow some users and the rest shouldn't have msn
access-list MSN extended deny ip object-group VIP any
access-list MSN extended permit ip any any
class-map MSN
match access-list MSN
class-map type inspect im match-all MESSENGER
match protocol msn-im
policy-map type inspect im MESSENGER
parameters
class MESSENGER
reset log
policy-map INSIDE
class MSN
inspect im MESSENGER
service-policy INSIDE interface inside
ASA-XXXX(config-pmap)# sh service-policy | inc im
Inspect: im MESSENGER, packet 64896, drop 0, reset-drop 9
ESMTP inspection is enabled and everything works perfect when I disable the IM Inspection
Inspect: esmtp _default_esmtp_map, packet 2916, drop 0, reset-drop 0
something weird that I noticed is the following log when I enable IM Inspection and emails stop working
Jul 26 2012 17:11:05: %ASA-4-733100: [ Scanning] drop rate-1 exceeded. Current burst rate is 527 per second, max configured rate is 10; Current average rate is 466 per second, max configured rate is 5; Cumulative total count is 279915
Jul 26 2012 17:11:05: %ASA-4-733100: [ Scanning] drop rate-2 exceeded. Current burst rate is 87 per second, max configured rate is 8; Current average rate is 151 per second, max configured rate is 4; Cumulative total count is 545514
Jul 26 2012 17:11:05: %ASA-4-733100: [ SYN attack] drop rate-1 exceeded. Current burst rate is 527 per second, max configured rate is 200; Current average rate is 466 per second, max configured rate is 100; Cumulative total count is 279610
Jul 26 2012 17:11:05: %ASA-4-733100: [ SYN attack] drop rate-2 exceeded. Current burst rate is 87 per second, max configured rate is 160; Current average rate is 150 per second, max configured rate is 80; Cumulative total count is 543537
thanks
Solved! Go to Solution.
ā07-27-2012 01:38 PM
Diego:
TCP Proxy functionality drops last ACK in TCP 3-way-handshake |
Symptom: The ASA Firewall may drop the third packet (ACK) in the standard TCP 3-way-handshake if the traffic is proxied by an inspection process. Conditions: This is seen starting in version 8.2.3.5. Prior versions do not seem to be affected. Workaround: Ensure that the traffic does not match an inspection process on the firewall to prevent the TCP proxy engine from attempting to track/re-assemble the data-stream. Additional Information: Even while hitting this bug, some traffic may NOT be impacted. If the connection/protocol being used requires that the SERVER send the first data on the connection, the connection will fail. If the CLIENT sends the first data on the connection, the connection will succeed just fine. This is because the dropped ACK from the CLIENT is processed by the ASA but the server never sees it. If the CLIENT then immediately sends data (ex. HTTP GET) then that PSH-ACK is passed and since it has the same ACK as the dropped ACK, the SERVER accepts as an ACK to its SYNACK and continues just fine. When the server must send the first bit of DATA (like SMTP banner) the connection will fail since the server never see's the ACK to its SYN-ACK it cannot advance to the point of sending a banner/etc. This is why some protocols are affected and some aren't. |
Mike
ā07-27-2012 12:28 AM
No, Eso no sirrveeee...
How is everything Diego? What version of Messenger are you trying to block? The fact that the connection for the mails go down as well is really weird. In order to see why the e-mails are being dropped, I may need you to filter the logs from the mail server going to the internet to see the reason of the drop. If the log is as vague as "terminated by inspection engine" we may need to run some debugs.
There are a coulpe of bugs with the IM inspection thou, what version are you running on the ASA? We may need also Identify if the SMTP inspection is being corrupted when the IM is turned on.
Mike R.
ā07-27-2012 07:44 AM
Que me dice perrito.
I am actually getting the following log
%ASA-4-507003:
tcp flow from inside:172.16.1.128/2506 to outside:201.191.202.42/80 terminated by inspection engine, reason - inspector reset unconditionally.
I am trying to block the latest version of MSN and it is beeing blocked but this is blocking emails as well. I have not had time to run debugs or captures yet, I was looking for a bug, if there is a bug since this is not a normal behavior. The version I am running is 8.2(4)
As soon as I disable L7 IM Inspection, emails work again.
Please let me know what additional info do you need for futher investigation.
Viva la liga
ā07-27-2012 10:07 AM
Just saw an identical case on.... you know......However there was no bug attached. The upgrade was from 8.0.5 to 8.2.4 and the inspection engine broke.
Let me dig a little bit more...I'll update the post soon.
"SeƱores yo soy manudo desde la cuna"
Mike
ā07-27-2012 01:38 PM
Diego:
TCP Proxy functionality drops last ACK in TCP 3-way-handshake |
Symptom: The ASA Firewall may drop the third packet (ACK) in the standard TCP 3-way-handshake if the traffic is proxied by an inspection process. Conditions: This is seen starting in version 8.2.3.5. Prior versions do not seem to be affected. Workaround: Ensure that the traffic does not match an inspection process on the firewall to prevent the TCP proxy engine from attempting to track/re-assemble the data-stream. Additional Information: Even while hitting this bug, some traffic may NOT be impacted. If the connection/protocol being used requires that the SERVER send the first data on the connection, the connection will fail. If the CLIENT sends the first data on the connection, the connection will succeed just fine. This is because the dropped ACK from the CLIENT is processed by the ASA but the server never sees it. If the CLIENT then immediately sends data (ex. HTTP GET) then that PSH-ACK is passed and since it has the same ACK as the dropped ACK, the SERVER accepts as an ACK to its SYNACK and continues just fine. When the server must send the first bit of DATA (like SMTP banner) the connection will fail since the server never see's the ACK to its SYN-ACK it cannot advance to the point of sending a banner/etc. This is why some protocols are affected and some aren't. |
Mike
ā08-21-2012 07:29 AM
Thanks Mike!!!
ā07-28-2012 11:29 AM
Hi Bro
Perhaps, you've done your ACL wrong. Try this and let me know :-)
access-list MSN extended permit ip host 10.10.10.54 any
access-list MSN extended deny ip any any
//This tells the Cisco equipment to perform inspection on the workstation with the IP Address 10.10.10.54 only. Object-groups is fine, if you've a list of specific IP Addresses.
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