ScreenOS Firewalls (NOT SRX)
ScreenOS Firewalls (NOT SRX)

ISG 2000 issue (strange behaviour)

04.14.12   |  
‎04-14-2012 03:45 AM

Dear Experts,


Below is the production setup we have


(host)<---------(NS5400)---------------> (ISG 2000) <------------------------> (ISG 1000)<------>(Server)


Host IP = (the host is initaiting traffic towards the server)

Server IP =

Correct routing is in place

policy is created on all three firewalls and required ports are permitted.

no natting is invlolved at all


Blow is the traffic log from the NS 5400 (which is first firewall or first hop from the host)


NS5400: NetScreen device_id=NS5400 [Root]system-notification-00257(traffic): start_time="today" duration=66 policy_id=3902 service=icmp proto=1 src zone=xxxxxxx dst zone=yyyyyyy action=Permit sent=82 rcvd=0 src= dst= icmp type=8 src-xlated ip= dst-xlated ip= session_id=916791 reason=Close - AGE OUT


ISG2000: NetScreen device_id=ISG2000  [Root]system-notification-00257(traffic): start_time="today" duration=65 policy_id=202 service=icmp proto=1 src zone=xxxxxxx dst zone=yyyyyy action=Permit
sent=0 rcvd=0 src= dst= icmp type=8 src-xlated ip= dst-xlated ip= session_id=995513 reason=Close - AGE OUT
I dont have access to ISG1000 (which is the third firewall in the setup ). This firewall is own by project team and their network admin is on vacation : ).
My question is why ISG2000 is not sending any packet as shown in the above log. Even if I assume that the problem is at the ISG1000 (which is where server is connected ) but still ISG2000 have sent around 80 packets. Everything was working fine and no changes has been made at the firewall site and it is not working any more.
Due to the log of ISG2000 log i am thinking that issue is from on ISG2000 site, I am happy with the log of NS5400
I would appreciate any help and also any suggestion.
Thanks in advance.


ScreenOS Firewalls (NOT SRX)

Re: ISG 2000 issue (strange behaviour)

04.16.12   |  
‎04-16-2012 05:37 PM

I would say that these both appear normal so far. 


The ISG 2000 is not going to reply to the traffic because the traffic is not destined for this device but the remote server behind yet another firewall.  The ISG 2000 is doing all it is suppose to do.  This checks to see that the traffic is permitted by a poicy and sets up a session for the traffic then forwards it along.  Since this ages out, the issue is upstream.


Either the next firewall, ISG 1000, is dropping the traffic as not permitted.  Or has some other configuration that is not compatible with returning the response.


Or the server is not responding for some other reason.


I think you have to get in touch with that remote team and arrange for a flow test and some captures on their side.

Steve Puluka BSEET
Juniper Ambassador
Senior IP Engineer - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
ScreenOS Firewalls (NOT SRX)

Re: ISG 2000 issue (strange behaviour)

04.16.12   |  
‎04-16-2012 07:04 PM

Steve, I think the question is, and I am wondering this myself, not so much about the lack of response, but rather about the "Sent=0" at the ISG2000 as opposed to "Sent=82" at the NS5400.


So, by the time the session aged out at the NS5400, it had sent 82 bytes, and received nothing back.


At the ISG2000, however, when the session timed out, the sent counter is still at 0 bytes, thus giving the impression that the ISG2000 never sent any traffic out in the first place.


I have a feeling that something about that counter is a bit off being that the ISG2000 is ASIC-based, but I think so is the NS-5400, so I'm not sure why the difference there.

ScreenOS Firewalls (NOT SRX)

Re: ISG 2000 issue (strange behaviour)

04.17.12   |  
‎04-17-2012 03:31 AM

What output do you get from a debug flow? Maybe the output of  "snoop" is helpful too (don't forget to set "no-hw-sess" on the policy).