If you need to troubleshoot problems with traffic flowing through a NetScreen firewall, or not flowing through, as the case may be, you can use the snoop command to provide packet sniffer capabilities for a Juniper NetScreen firewall, but, if you need to see how policies are being applied or exactly how the firewall is handling problematic traffic, then you need to use the built-in debugging capability.
When you have debugging turned on, information is stored in
the debug buffer. The command clear db clears any existing data
from the buffer, which you may want to do each time you start a new
debugging session. To view any existing debug filters, you can use the command
get ffilter. You can set a filter with set ffilter.
The command debug flow basic starts debugging, while the command
undebug all turns off debugging. You can view the debug buffer
with get dbuf stream or the shortened form get db str.
ns5gt-> clear db ns5gt-> get ffilter ns5gt-> set ffilter dst-port 27900 filter added ns5gt-> get ffilter Flow filter based on: id:0 dst port 27900 ns5gt-> debug flow basic ns5gt-> undebug all ns5gt-> get db str ****** 306813.0: <Trust/trust> packet received [33]****** ipid = 24666(605a), @03cc7fb0 packet passed sanity check. trust:192.168.2.3/53434->207.38.11.34/27900,17<Root> existing session found. sess token 2 flow got session. flow session id 1539 post addr xlation: 72.45.13.244->207.38.11.34. <text snipped> ****** 306885.0: <Untrust/untrust> packet received [35]****** ipid = 35709(8b7d), @03c31c30 packet passed sanity check. untrust:72.81.210.154/3049->10.45.13.244/27900,17<Root> self check, not for us chose interface untrust as incoming nat if. packet dropped: for self but not interested
I can see from the above output that a
UDP datagram
was receivd from 72.81.210.154 port 3049 at
10.45.13.244/27900,17, i.e. port
27900 on the untrust side of the firewall. The 17 specifies the
IP protocol
number; 17 indicates it is a UDP datagram.
I can see that the firewall just dropped the packet, so apparently "thinks"
it doesn't have any policies defined to deal with such packets.
In the example above, I filtered only on the destination port. You can
specify multiple filtering options. The first command below filters on
a source IP address, 173.20.5.255 and specify that
only UDP data should be examined, i.e. IP protocol number 17.
The next command, debug flow basic actually starts the capture
of data to the debug buffer.
ns5gt-> set ffilter src-ip 173.20.5.255 ip-proto 17 filter added ns5gt-> debug flow basic
The options for setting filters are as follows:
ns5gt-> set ffilter ? <return> dst-ip flow filter dst ip dst-port flow filter dst port ip-proto flow filter ip proto src-ip flow filter src ip src-port flow filter src port
If you set multiple filters it is as if there is an "or" between them. That is, if ANY packet matches ANY of of the flow filters then that packet will be
matched. You can remove filters with unset ff.
ns5gt-> unset ff filter 0 removed ns5gt-> get ff ns5gt->
For viewing the data in the buffer, you can use the get dbuf
mem or get dbuf stream commands. The options for
the get dbuf stream command are as follows:
ns5gt-> get dbuf stream ? > redirect output | match output <return> all from all slots <number> percentage offset of debug buffer(0-99)
The command get dbuf stream produces output in the following
format:
ns5gt-> get db stream
45
vhl=45, tos=00, id=60051, frag=0000, ttl=63
udp:ports 49693->58540, len=25
312908.0: 1(o):0010db7d2861->001d70cce905/0800
10.45.13.244->173.22.35.38/17, tlen=45
vhl=45, tos=00, id=60051, frag=0000, ttl=62
udp:ports 2109->58540, len=25
312909.0: 2(i):00173f449751->0010db7d2862/0800
192.168.2.3->173.22.35.38/17, tlen=45
vhl=45, tos=00, id=60060, frag=0000, ttl=63
udp:ports 49693->58540, len=25
312909.0: 1(o):0010db7d2861->001d70cce905/0800
10.45.13.244->173.22.35.38/17, tlen=45
vhl=45, tos=00, id=60060, frag=0000, ttl=62
udp:ports 2109->58540, len=25You can also filter the display of information stored in the
debug buffer using | incl searchpattern. E.g., suppose
I wanted to dispaly just those lines for UDP data (protocol number
17) that show the source and destinations involved. I know
those lines have ,17 in them, so I can use the following
command:
ns5gt-> get dbuf stream | incl ",17" trust:192.168.2.3/61405->173.20.5.255/33554,17<Root> untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root> trust:192.168.2.3/61405->173.20.5.255/33554,17<Root> untrust:173.20.5.255/33278->72.45.13.244/2738,17<Root> trust:192.168.2.3/61405->173.20.5.255/33554,17<Root>
You can even use some
regular
expression syntax. For instance I could use
get dbuf stream | incl "untrust:.*,17" to limit the output
to use those lines that contain "untrust:" followed by any character,
which is represented by the "." occuring zero or more times, which is
the meaning attached to the "*", then followed by ",17". I.e., I'm
looking for lines that contain "untrust" followed by ",17" somewhere
later on the line.
ns5gt-> get dbuf stream | incl "untrust:.*,17" untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root> untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root> untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root> untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root> untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root> untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root> untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root> untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root> untrust:173.20.5.255/33278->10.45.13.244/2738,17<Root>
You can also use the get dbuf mem command to view the
data stored in the debug buffer, which will show the data in hex format
as well as ASCII.
ns5gt-> get dbuf mem ====32768 32 37 38 36 28 30 61 65 32 29 2c 20 40 30 33 63 2786(0ae2),.@03c 31 33 63 33 30 0d 0a 20 20 70 61 63 6b 65 74 20 13c30....packet. 70 61 73 73 65 64 20 73 61 6e 69 74 79 20 63 68 passed.sanity.ch 65 63 6b 2e 0d 0a 20 20 75 6e 74 72 75 73 74 3a eck.....untrust: 31 37 33 2e 32 30 2e 35 2e 32 35 35 2f 33 33 35 173.20.5.255/335 31 35 2d 3e 31 30 2e 34 35 2e 31 33 2e 32 34 34 15->10.45.13.244 2f 31 39 36 38 2c 31 37 3c 52 6f 6f 74 3e 0d 0a /1968,17<Root>.. 20 20 73 65 6c 66 20 63 68 65 63 6b 2c 20 6e 6f ..self.check,.no 74 20 66 6f 72 20 75 73 0d 0a 20 20 63 68 6f 73 t.for.us....chos 65 20 69 6e 74 65 72 66 61 63 65 20 75 6e 74 72 e.interface.untr 75 73 74 20 61 73 20 69 6e 63 6f 6d 69 6e 67 20 ust.as.incoming. 6e 61 74 20 69 66 2e 0d 0a 20 20 70 61 63 6b 65 nat.if.....packe 74 20 64 72 6f 70 70 65 64 3a 20 66 6f 72 20 73 t.dropped:.for.s 65 6c 66 20 62 75 74 20 6e 6f 74 20 69 6e 74 65 elf.but.not.inte 72 65 73 74 65 64 0d 0a 2a 2a 2a 2a 2a 2a 20 33 rested..******.3 32 30 35 33 30 2e 30 3a 20 3c 54 72 75 73 74 2f 20530.0:.<Trust/ 74 72 75 73 74 3e 20 70 61 63 6b 65 74 20 72 65 trust>.packet.re 63 65 69 76 65 64 20 5b 34 38 5d 2a 2a 2a 2a 2a ceived.[48]***** 2a 0d 0a 20 20 69 70 69 64 20 3d 20 35 30 32 34 *....ipid.=.5024 36 28 63 34 34 36 29 2c 20 40 30 33 63 62 32 66 6(c446),.@03cb2f 62 30 0d 0a 20 20 70 61 63 6b 65 74 20 70 61 73 b0....packet.pas --- more ---
You can hit the spacebar or other keys to page through the data or
hit q to quit.
If you want to clear out any captured data, unset all filters, and turn debugging off when you are finished with your debugging activity, you could enter the following sequence of commands:
ns5gt-> clear dbuf ns5gt-> get ffilter Flow filter based on: id:0 src ip 173.20.5.255 ns5gt-> undebug all ns5gt-> unset ff filter 0 removed
References:
