Screen OS

Regarding out-of-sequence tcp packet drops:  I have read the KB articles surrounding this, and the following two were somewhat useful in verifying what's happening:

http://kb.juniper.net/index?page=content&id=KB5814

http://kb.juniper.net/index?page=content&id=KB6116&cat=TECHNOLOGY&actp=LIST

Flow counters for the relevant interface:

tcp out of seq     90976 | mac relearn            0 | no frag sess           0
 

That said, I'd like to log these drops somehow.  I have several high-volume proxies and a load balancer behind this particular firewall, and I need to profile ONLY the traffic getting dropped by "unset flow no-tcp-seq-check" (i.e., sequence number checking) before I blindly disable it.  Note that capturing all traffic through this firewall is simply not possible with the hardwae on-hand.

Likewise, I'd like to log these same-interface drops:

auth fail              0 | loopback drop      15067 | big bkstr              0

Can that be done with a typical last-line-deny-log policy?  There IS a same-interface policy in place there, so I suspect this is a protocol that doesn't match the existing list.

I.e., "from <same.zone> to <same.zone> any any any deny log count" at the end of that section?

Thanks!

Hi,

Unfortunately it is not possible to log/profile packets that are dropped due to TCP out of sequence. 

Regarding "loopback drop":

you can log this traffic as you have described. 

This counter shows packets that are dropped due to "intra-zone blocking". Intra-zone blocking is checked last if no policy is found. 

Thanks,

Nemanja

Hi again,

One more thing to add ...

It is not really true that there is no way to see which packets are dropped due to TCP sequence checking. 

You can use "debug tag info" and search for dumux type 26. These packets are dropped due to sequence checking.

Here is an example.

****************** 01470.0: tag (03a58280) ******************
pak length: 40  vlan  qidx:18  slot:2  port:2  buffer:0x9040711c
protcol:6  demux:26  l2idx:535e  ipid:4ec7 
flags:0x2000004f  session pointer:0x08000500
src:5.5.5.2  dst:5.5.5.1  sport:8029  dport:759f
********************** end tag info *************************

WARNING:

it is not possible to filter the debug to show only these out of sequence drops.

"debug tag info" will show all other kinds of packets like first packets, ALG packets ...

It can be very CPU intensive. 

Also due to buffer limit of 4MB the buffer could be rewritten before you can see this kind of drops. 

You can filter "debug tag info" using flow filters "set ff ..." 

Hope this helps.

Thanks,

Nemanja

Excellent info; thanks!

However, it appears that I'm missing a command to actually activate this type of debug:

cluster1:fw-jp01(M)-> undebug all
cluster1:fw-jp01(M)-> get ffilter
cluster1:fw-jp01(M)-> set console dbuf
cluster1:fw-jp01(M)-> debug tag info
cluster1:fw-jp01(M)-> get dbuf stream
cluster1:fw-jp01(M)-> get debug
tag: info
cluster1:fw-jp01(M)-> get dbuf stream
cluster1:fw-jp01(M)-> 

As you can see, there are no conflicting debugs or filtering assigned yet.  But I am clearly missing an additional command in order to actually start the logging of tag info.

(Separately, I verified that "debug flow basic" for a ffilter IP still works normally)

Thoughts?

I would suggest that while you are running "debug tag info" you monitor the counter stats at the same time, just to be sure that the seq check is dropping packets at that time.

eg

debug tag info

get count stat | i seq (run this multiple times)

If you see the counts increment, then it should be safe to stop the debugs and try to view them. Could be just a coincidence that when you were running the debugs that there were no drops. Oh and debug tag info has usually worked well for us as well.

Hi,

Sorry, I forgot to mention that "debug tag info" can only be used with ASIC based sytems (ISG,NS-5000).

"debug tag info" is used instead if "debug flow basic" on ASIC based platforms since sequence checking is done in ASIC  and "debug flow basic" shows only packets that go to CPU. 

If you are not using one of the platforms mentioned above please use only "debug flow basic". 

Thanks,

Nemanja

Ah, thanks for the clarification.  The affected system is indeed an ISG2000 (HA pair), but I was attempting to test the debug statements on an SSG320 (i.e., CPU-based system) in our lab first.

I'll run these commands during our next maintenance window, and post some results afterwards for others' benefit.

Thanks!

Update on loopback drops topic (above): 

As I had expected, these drops were 100% usual/typical public attack traffic to static NAT addresses bound on our Untrust interfaces.  Nothing to worry about under normal circumstances...