ScreenOS Firewalls (NOT SRX)
Reply
Visitor
AWAL
Posts: 6
Registered: ‎06-05-2011
0

ISG 2000 issue (strange behaviour)

Dear Experts,

 

Below is the production setup we have

 

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

 

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

Server IP = 10.8.66.129

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=10.0.228.26 dst=10.8.66.129 icmp type=8 src-xlated ip=10.0.228.26 dst-xlated ip=10.8.66.149 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=10.0.228.26 dst=10.8.66.129 icmp type=8 src-xlated ip=10.0.228.26 dst-xlated ip=10.8.66.129 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.




 

Distinguished Expert
spuluka
Posts: 2,561
Registered: ‎03-30-2009
0

Re: ISG 2000 issue (strange behaviour)

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 Network Engineer - UPMC Pittsburgh, PA
JNCIA-ER JNCIA-EX JNCIS-SEC JNCIP-SEC
JNCIS-FWV JNCIS-SSL
MCP - Managing Server 2003 MCP - Windows XP Professional
MCTS Windows 7
http://puluka.com/home
Super Contributor
nikolay.semov
Posts: 170
Registered: ‎03-15-2012
0

Re: ISG 2000 issue (strange behaviour)

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.

Contributor
magrub
Posts: 12
Registered: ‎06-03-2009
0

Re: ISG 2000 issue (strange behaviour)

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).

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.