cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5012
Views
0
Helpful
5
Replies

IOS Firewall (ZFW) dropping Tcp sessions?

cluovpemb
Level 1
Level 1

Hello all.  It was just last weekend that I put in my first zone firewalled router into a live environment. 

Now, with ip inspect log drop_pktset, I see many many entries of dropped packets.  Often these are not due to explicit rules I've set but instead, due to I imagine just integrated firewall drop criteria.  For example:

177497: *Nov  9 2012 08:56:16.916 PCTime: %FW-6-DROP_PKT: Dropping tcp session <my public IP>:49399 <someone else's public IP>:443  due to  RST inside current window with ip ident 0

I get about 4 or 5 different types of conditions.  Always with "ip ident 0" whatever that is.  There's this RST one, then there's dropping packets due to Out of Order Segment (this is from an email filtering service that then sends the clean emails to our mail server).  Also there is often dropping tcp session due to Stray Seegment, usually this one comes from internal systems going outbound.  Again, these are not drops due to rules I've set, these are apparently just built-in drop actions esigned into the firewall itself. 

Though I would much appreciate any direct explanation from fellow forum members about any specific condition above, I would be happy also with any kind of reference document that explains all of the ones found in an IOS zone firewall so I could referenc them. 

I googled some of these and get some partial answers but generally it's a lot of opinion and less facts.  Perhaps what is fact is Out of Order:  you can set up a parameter map to create an out of order buffer so your firewall will allow more OOO packets before inspcting them, thus you won't have the out of Order rops occuring.  I don't know what would be considdred tolerable OOO windowing since TCP by design allows for this to occur but maybe the FW is less tolerant? 

Thanks for any insight. 

1 Accepted Solution

Accepted Solutions

Maykol Rojas
Cisco Employee
Cisco Employee

Normally 256 is consider a decent value. (I guess thats the larger you can go for thou).

So far there is no reasonable explanation for that Log, as you suggested, it is very generic and that is why there is an enhacement request on it.

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

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

Unfortunately, if there no present and consisten issue, there no reasonable way to determine what it is causing it.

Mike

Mike

View solution in original post

5 Replies 5

Maykol Rojas
Cisco Employee
Cisco Employee

Normally 256 is consider a decent value. (I guess thats the larger you can go for thou).

So far there is no reasonable explanation for that Log, as you suggested, it is very generic and that is why there is an enhacement request on it.

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

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

Unfortunately, if there no present and consisten issue, there no reasonable way to determine what it is causing it.

Mike

Mike

For me, both of those links resulted in a "bug not found" kind of message.  But either way, as long as there is visibility into a need to enhance the reporting of those log entries that's great.  I'm sure a nice look at some RFC about TCP sessions might give the answers but I don't really have time these days Anyway, thanks for the answer and I"ll try out that OOO value of 256, once I learn how to make a parameter map for this 

Ok so it appears this OOO parameter map thing is very specific and ha sonly one way to be modified. 

#conf t

#parameter-map type ooo global (global is the only option, cannot make an OOO customized parameter map)

(config-profile#tcp reassembly queue length <0-1024>

I set it to 128 just for fun for now.  The default is 16.  I will try 256 as suggested, it's just that I'm curious if varying values will have varying effects on this OOO problem. 

Results of sh parameter-map type OOO global:

parameter-map type ooo global

   tcp reassembly timeout 5

   tcp reassembly queue length 128

   tcp reassembly memory limit 1024

   tcp reassembly alarm off

Just FYI to anybody reading this post in the future.  I'll post whether the OOO's stopped completely, and what queue length value was the one that worked in this particular scenarioi. 

Thanks again. 

Hello Colin,

Funny, if you copy the whole link it works, if you click on it, it wouldnt.

Let us know if the OOO queue works.

Mike

Mike

So far I think it's working.  Porobme is sometimes I get weired issues with the firewall logging - I mean, as I write this, after running sh logging | i FW, there are no entrires of any kind.  Odd, since I haven't cleared the buffer in days. 

Anyway, if I start seeing FW entries but don't see the OOO ones, I'll report back here.  Meanwhile I wanted to share what I found about the firewall messages desciprtions, located in the following command reference (in Table 1 of the ip inspect log drop_pkt command)

http://www.cisco.com/en/US/docs/ios-xml/ios/security/d1/sec-cr-i2.html#GUID-EC0B929B-E1E0-4E30-A854-CB4E92B30025

They aren't extremely descriptive but do give more than I've found elsewhere. 

Review Cisco Networking for a $25 gift card