Description

 

This article details how to troubleshoot a security policy that is not passing data.

 

Symptoms

 

Traffic is not matching the expected security policy or traffic is getting denied.

 

Solution

 

Use the following steps to troubleshoot a security policy that is not passing data:

  1. Is the security policy order correct?  

The ordering of security policies is important as the policy lookup process is performed from top to bottom until a match is found. Validate the order of the security policies with the command show security match policies . Refer to Understanding Security Policy Ordering for more information.

  1. Is the expected security policy configured correctly to match the traffic that is not passing?

Run the following command:

show security policies from-zone <zone> to-zone <zone> policy-name <policy> detail

(The detail parameter reports the address-book names and the corresponding IP address/subnet based on the configuration. This option is not available in J-Web.)

Example: 

root@SiteA> show security policies from-zone trust to-zone untrust policy-name internal-net detail
Policy: internal-net, action-type: permit, State: enabled, Index: 4, Scope Policy: 0
  Policy Type: Configured
  Sequence number: 1
  From zone: trust, To zone: untrust
  Source addresses:
    internal-net: 10.20.20.0/24  
    local-net: 192.168.10.0/24   <------
  Destination addresses:
    remote-net: 192.168.20.0/24  <------
  Application: any               <------
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]
  Per policy TCP Options: SYN check: No, SEQ check: No

  1. Verify that the "Source addresses" and "Destination addresses," including the subnet, are inclusive of the expected traffic source and destination IP addresses .

In our example, the source IP addresses in the subnet 192.168.10.0/24 will match the address-book entry local-net, and the destination IP addresses in the subnet 192.168.20.0/24 will match the address-book entry remote-net.

  1. Verify that the "Application" includes the expected applications.  

  2. Verify the "action-type."

  1. If NAT is configured, are the source and/or destination address translations correct? 

For assistance, consult:  KB21719 - How to check and interpret the Flow Sessions installed in the SRX when troubleshooting NAT [juniper.net] .

  • Yes  - Continue to Step 4.

  • No   - Correct the addresses and try passing traffic again.

  1. Is traffic from the client reaching the SRX device? For assistance, set up traceoptions by using the instructions in KB16233 - Setting up security flow traceoptions [juniper.net] and check whether the packets are being dropped by the SRX device.

  • Yes - If you are not able to determine the drop point, continue to Step 5.

  • No - Correct the network issue and try passing traffic again.

  1. Collect the logs specified in KB21781 - [SRX] Data Collection Checklist - Logs/data to collect for troubleshooting [juniper.net] and open a case with your technical support representative.

 

Modification History

 

2020-12-28: Minor changes made to the symptoms section; article checked for accuracy and found valid

 

Related Information