I’ve worked with Netscreens for a few years now, starting with ScreenOS version 5.x, and when troubleshooting I had always been pointed towards
debug flow as the way to see what was going on. I suspect many of you have also been taught:
debug flow basic
- (wait for packets you wanted to capture)
get db stream(to view output)
This is definitely helpful for rule debugging but for simple packet capture is a bit over the top, which is where the
snoop command comes in.
To be clear,
snoop won’t tell you anything about what decisions the firewall made about the packets, but it’s a simple way to see the actual traffic. Here’s an example of the output produced by snoop:
19944926.0: ethernet2/1(o) len=206:0010dbff2070->00005e000101/8100/0800, tag 1872 220.127.116.11 -> 18.104.22.168/17 vhl=45, tos=00, id=13096, frag=0000, ttl=64 tlen=188 udp:ports 500->500, len=168 00 00 5e 00 00 01 00 10 db a1 27 a1 81 00 07 50 ..^........p.... 08 00 45 00 00 bc 33 28 00 00 40 11 b6 18 01 04 ..E...3([email protected] 3f 52 01 0e 12 1b 01 f4 01 f4 00 a8 95 79 a8 d3 @4P..........y.. a6 4a f3 28 34 82 00 00 00 00 00 00 00 00 02 18 [email protected] 09 00 00 00 00 00 00 00 00 c2 0a 00 00 ea 00 00 ....a..'........ 00 08 00 00 00 16 00 00 00 b8 02 31 aa 90 00 00 ...P....y.......
Pretty straightforward stuff – you get to see the source and destination IP and protocol (17 is UDP), some header and port information, and the length, followed by a hex dump of some of the packet. That’s enough to see what’s going on in many cases. So how do you use it?
First step, make sure nothing else is filling the debug buffer:
Now double check the current status of snoop to make sure it’s not running:
netscreen-> snoop info Snoop: OFF Filters Defined: 0, Active Filters 0 Detail: ON, Detail Display length: 96 Snoop tunnel traffic: ON netscreen->
In this case there are no filters already defined, so we can create one. As a simple example, let’s filter on a specific IP:
snoop filter ip 22.214.171.124
There are actually a number of options you can add to this command, including IPs, ports, IP protocols and direction (the default is to capture both inbound and outbound). You can also add more than up to eight filters; just issue the
snoop filter ip command again and the filter will be added. If we check the status of the snoop again, the new filter shows up and it has an id:
netscreen-> snoop info Snoop: OFF Filters Defined: 1, Active Filters 1 Detail: ON, Detail Display length: 96 Snoop tunnel traffic: ON Snoop filter based on: id 1(on): IP ip 126.96.36.199 dir(B)
The filter id can be used to individual enable, disable, or delete a filter:
netscreen-> snoop filter id 1 ? delete delete snoop filter off turn off snoop filter on turn on snoop filter
Now the filter is in place, let’s clear the old debug buffer before we start adding content:
And finally, we’ll start our snoop:
You’ll be prompted to type
y to continue with the snoop. At any point, you can view the current buffered output by issuing:
get dbuf stream
If you’re on console, if memory serves, the db stream is mirrored there automatically, but I believe on a VTY you don’t get to see it unless you issue the
get db stream command.
When you’re done, stop the snooping:
If you want to delete the filters you added (all of them):
snoop filter delete
…or you can delete individual filters by
My 10 Bits
I failed to discover this command’s existence for the longest time, and I have no idea how as it’s incredibly useful; just remember to turn it off afterwards. It feels – subjectively – safer somehow than a
debug flow basic, but I welcome your opinions on that statement!
Leave a Reply