cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
1646
Views
2
Helpful
6
Replies

IM and ESMTP Inspection

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

1 Accepted Solution

Accepted Solutions

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.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtj88604

Mike

Mike

View solution in original post

6 Replies 6

Maykol Rojas
Cisco Employee
Cisco Employee

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.

Mike

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

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

Mike

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.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtj88604

Mike

Mike

Thanks Mike!!!

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.

Warm regards,
Ramraj Sivagnanam Sivajanam
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: