Netscreen SSG - Packet trace

There are many ways to troubleshoot in NetScreen Firewall when some one reports a Incident, that they are unable to access a Server / Application.

Understand the Packet flow

Packet flow tell the order in which the packet is processed by the firewall, when it reaches the firewall.

Looking @ Session

It is always a good idea to start the troubleshooting with a session, check if traffic is passing through the firewalls.

spiceup.net.in_FW-> get session src-ip 1.1.1.1 dst-ip 2.2.2.2

You should see matching session output similar to this:

id 1454/s**,vsys 0,flag 00000050/0080/20,policy 320002,time 1, dip 0

1(0001):1.1.1.1/60185->2.2.2.2/512,1,000d60765d03,3,vlan 0,tun 0,vsd 0,route 2

3(0010):1.1.1.1/60185<-2.2.2.2/512,1,000000000000,4,vlan 0,tun 0,vsd 0,route 10

The Source IP Address 1.1.1.1 has source port as 60185 and destionation ip 2.2.2.2 has destination port as 512, the Source port here is the ICMP Sequence Number, the destination port is the ICMP Identifier, is sending the ping packet (echo request) to the destination and the destination sends back the reply to the ping echo reply.

The below is the output of the partial packet capture using sniffer for the above sessions:

ECHO REQUEST:

Internet Control Message Protocol

Type: 8 (Echo (ping) request)

Code: 0

Checksum: 0x6042 (correct)

Identifier: 0x0200

Sequence number: 0xeb19

Data (32 bytes)

ECHO REPLY:

Internet Control Message Protocol

Type: 0 (Echo (ping) reply)

Code: 0

Checksum: 0x6842 (correct)

Identifier: 0x0200

Sequence number: 0xeb19

Data (32 bytes)

Debug flow basic

Shows the flow of traffic through the firewall, allowing for troubleshooting route selection, policy selection, any address translation and whether the packet is recieved or dropped by the firewall.

1) get ffilter - see if an filters have been set already, if they have you use 'unset ffilter' to remove, repeat the steps until you remove all the filters

2) set ffilter src-ip 10.1.1.5 dst-ip 1.1.70.250 - allows you to limit the traffic that you capture using src-ip, src-port, dst-ip, dst-port & etc... Recommeded as debug flow basic can be intensive on the firewall especially if it is under heavy load.

3) debug flow basic - turns on flow debuging with a level of basic logging

4) clear db - make sure there is nothing in the debug buffer from previous debugs

5) Begin the test, do a ping or try to access the resource that you are having problems with.

6) undebug all or press Esc key - turns off debug

7) get db str - reads the debug buffer and outputs.

8) unset ffilter - remove ffilters when finished

9) clear db - make sure there is nothing in the debug buffer from previous debugs

Snoop

Snoop is a powerful troubleshooting tool that gives the user the ability to view packet information from Layer 2 to Layer 4, as it comes into and out of the firewall interfaces. (Bi-directional traffic) Here is the typical procedure when using snoop:

spiceup.net.in_FW-> snoop filter ip 2.2.2.222 - set a filter to limit the traffic that you capture.

spiceup.net.in_FW-> snoop info - check whether the filter is applied properly.

spiceup.net.in_FW-> snoop - "switch on" the snoop and initiate the traffic.

spiceup.net.in_FW-> snoop off - "Turn off" the snoop

spiceup.net.in_FW-> get dbuf stream - check the output of the snoop

spiceup.net.in_FW-> clear db - clear the buffer

Buffer commands:

get dbuf info - Displays debug buffer size in bytes

set dbuf size - Allocates system memory for the debug buffer

get dbuf stream - Displays the contents of the debug buffer

clear dbuf - Clears the contents of the debug buffer