Screen OS

Are there many differences when running snoop on a ScreenOS firewall when not logged in with a root user? (I know that for instance, you cannot turn on snoop detail if you’re not a root user).

The reason I ask is that I'm trying to troubleshoot a connectivity issue between two hosts at opposite ends of a VPN.

On the 'spoke', where I'm logged in as a root user, all I do is turn on snoop, enable snoop detail (i think that was atually on by default) and set an IP filter for the remote IP I'm looking for. The output is beautiful... I basically capture two packets for every packet the firewall sees (one hitting the src interface and one hitting the outbound interface).

The problem though is on the hub side, where I'm logged in as an read-write user. I set snoop up exactly the same way, but I literally get no data at all.

I'm really needing packet level captures from the hub side.

Thanks in advance,

Chris

I did some testing - it doesn't look like there is any difference in what gets captured or reported based on a r/w user vs a root user, but that sort of makes my problem a bit different....

I have a snoop filter setup on both the spoke and hub.

Snoop filter is an IP filter for an IP at the hub side.

Communication is heading from a host at the spoke to the hub.

I see packets (UDP packets to be specific) reach the spoke's lan interface and get sent along the tunnel interface.

On the hub side capture i do NOT see the packets, yet I know that they must be making it for 2 reasons:

1. I have partial connectivity between systems

2. I see reply packets on the spoke side

If i do something like ping the hubside destination from the spoke, my snoop DOES capture that.

Any ideas what can be causing this?

Thanks in advance,

-Chris

Hello.

Couple things come to mind.

1) If the device is ISG or ns5000 platform, then you will not see data traffic in snoop (since snoop only shows packets sent to cpu for processing)

2) what version is the firewall in the hub running?  prior to 6.1??? (I forget the exact version), there was no option to snoop tunnel traffic.

since all ICMP packets are sent to cpu for processing, you will see this in snoop.

Regards,

Sam

Sam,

Thank you for the info!

The firewall is an NS4500 running ScreenOS 6.3

Would it be safe to say that TCP packets do through the CPU as well and that UDP packets don't?

I've been doing some more testing htis morning - if i source a TCP connection I can see it on the hub, but not the UDP connection. What's odd though is that i see the inbound packet from the tunnel, but I don't see the packet getting redirected to one of the LAN interfaces. I also don't see the session opening getting logged on the inbound access rule on the hub (service is ANY) .

I suppose this behavior is different then an SSG model?

Is there a way to capture the packets in question?

Thanks again,

Chris

Hi Chris,

For UDP, you would only see the 1st packet during session creation.

For TCP, you would see the 1st packet during session creation.  The SYN-ACK and ACK of the 3-way handshake, you may or may not see depending on the "set flow ..." options.  i.e. if the firewall was re-writing TCP-MSS options, then you will see the 3-way handshake. 

Also, it's expected that on the 5400's, to only see the incoming packet in snoop/debug, and out the outgoing packet.  Once the packet is send to hardware (asic) for processing, then the packet no longer appears in snoop/debug.

One thing that you can try (but with caution), is to create a specific policy with the "no-hw-sess" option. This will force all the packets matching the policy to be sent to CPU.  But please be careful not to overwhelm the firewall with too many pps.

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

http://kb.juniper.net/InfoCenter/index?page=content&id=KB23844&actp=search&viewlocale=en_US&searchid=1355931028470#basicdebug

The SSG series are all CPU-based, so all packets are handled by the CPU.

Regards,

Sam

Sam,

Thank you for the additional input!

That was exactly what I was looking for.

Thanks again,

Chris