Screen OS

last person joined: 8 months ago 

This is a legacy community with limited Juniper monitoring.

  • 1.  Policies are hanging

    Posted 08-10-2015 04:43

    Dear All ,

     

    One of my customer reported policies hanging issue .

     

    Past 2 weeks we have been facing issue on Netscreen policies which is getting hanged frequently, so we use to disable/enable the policy everytime manually  intend to make it work or allow the traffic for the policy.Please helo me to resolve this issue . I have checked cpu,memory and session counts also but in vain .

     

    Traffic log for policy :

     

    ID

    Source

    Destination

    Service

    Action

    679

    V1-Untrust/202.138.123.75/32

    V1-Trust/192.168.150.129/32

    TCP_12000

    Permit


     

    Date/Time

    Source Address/Port

    Destination Address/Port

    Service

    Duration

    Bytes Sent

    Bytes Received

    Close Reason

    No entry available

    		 


    1.       After disable/enable Policy and started receive traffic on particular policy.

    2015-08-04 11:46:27

    notif

    Policy (679, V1-Untrust->V1-Trust, 202.138.123.75/32->192.168.150.129/32,TCP_12000, Permit) was enabled by netscreen via web from host 172.16.19.90 to 172.16.19.11:443.

    2015-08-04 11:46:27

    notif

    Policy (679, V1-Untrust->V1-Trust, 202.138.123.75/32->192.168.150.129/32,TCP_12000, Permit) was modified by netscreen via web from host 172.16.19.90 to 172.16.19.11:443.

     

     

    Date/Time

    Source Address/Port

    Destination Address/Port

    Service

    Duration

    Bytes Sent

    Bytes Received

    Close Reason

    2015-08-04 11:47:04

    202.138.123.75:45420

    192.168.150.129:12000

    TCP PORT 12000

    3 sec.

    233

    239

    Close - TCP RST

    2015-08-04 11:47:01

    202.138.123.75:45420

    192.168.150.129:12000

    TCP PORT 12000

    0 sec.

    0

    0

    Creation

     

    Date/Time

    Source Address/Port

    Destination Address/Port

    Service

    Duration

    Bytes Sent

    Bytes Received

    Close Reason

    2015-08-04 11:49:20

    202.138.123.75:34768

    192.168.150.129:12000

    TCP PORT 12000

    65 sec.

    361

    288

    Close - TCP FIN

    2015-08-04 11:49:16

    202.138.123.75:38842

    192.168.150.129:12000

    TCP PORT 12000

    0 sec.

    0

    0

    Creation



  • 2.  RE: Policies are hanging
    Best Answer

    Posted 08-10-2015 08:55

    Can you please provide a debug flow basic for when it is not working along with one when it is working?  This way we can compare the non-working to working to see what is different.



  • 3.  RE: Policies are hanging

    Posted 08-11-2015 01:05

    thanks for solution .Could you please provide me procedure to capture debug flow basic .I will ask customer collect and share .



  • 4.  RE: Policies are hanging

    Posted 08-11-2015 03:24

    This is the procedure. You do this on the command line of the device.

     

    Spoiler

    DEBUG FLOW BASIC :

    ==================

     

    Prepare the tool

    1. undebug all - we are assuring that the debug utility is not already running.

    2. get ffilter - we would expect to get no response. This tells us we have not set up any flow filters as of yet. If you should see filters listed you can delete them with unset ffilter.

     

    Setup the capture

    3. set ffilter src-ip x.x.x.x(computer A) dst-ip x.x.x.x(computer B)

      set ffilter src-ip x.x.x.x(Computer B) dst-ip x.x.x.x(computer A) by doing this we can observe the packets flowing in each direction and where any possible problems may be. Basically we want to define the end points of communication.

     

    Capture the traffic

    5. clear db - this will clear the debugging cache.

    6. debug flow basic - this turns the debugging utility on.

    7. initiate the traffic you are interested in capturing.

     

    Pull the data

    8. undebug all - turns the utility back off. 

    9. get db stream - this is the actual packet capture output that we want.

     

    Remove the setup

    10.unset ffilter 0 - this will need to be done twice, once for each filter that we set up earlier.

    11.clear db - this will clear the cache.

      



  • 5.  RE: Policies are hanging

    Posted 08-14-2015 03:26
      |   view attached

    Dear Steve ,

     

    We have completed the testing and attaching debug commands output .Please find the same and share your observations .Thanks in advance .

    Attachment(s)

    txt
    NS_Debug.log.txt   64 KB 1 version


  • 6.  RE: Policies are hanging

    Posted 08-14-2015 03:37

    I'm a ittle confused.  Your policy notes in the original post show the traffic going in the opposite direction of this debug capture.

     

    Flow filter based on:
id:0 src ip 192.168.150.237 dst ip 202.138.123.75

    This traffic is denied because there is no policy.

     

      flow_first_sanity_check: in <v1-trust>, out <v1-untrust>
  policy search from zone 12-> zone 11
 policy_flow_search  policy search nat_crt from zone 12-> zone 11
  RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 202.138.123.75, port 2033, proto 6)
  No SW RPC rule match, search HW rule
  log this session (pid=18)
  packet dropped, denied by policy

    Which ip address is the initiator of the production traffic?

     



  • 7.  RE: Policies are hanging

    Posted 08-18-2015 23:57

    I am not sure, But I was requested user to initiate traffic from 192.168.150.237 during incident, Then how do the policy start passes the traffic through firewall once we did deny/permit on policy every time. Otherwise it won’t passes traffic on particular policy until to do this.

     

    192.168.150.237  is the source according the flow



  • 8.  RE: Policies are hanging

    Posted 08-19-2015 16:21

    The security policy needs to be created from the persepective of tcp initiation on the connection.  Whatever device starts the tcp conversation, this is the source zone of your policy.  Whatever address is the destination ip for this first communication, this is the destination zone for the policy.

     

    If you tcp initiation is as you have in this test then you need to remove the original policy and create a new one in the correct zone direction.