A J Series or SRX Series device secures a network by inspecting, and then allowing or denying, all connection attempts that require passage from one security zone to another.
By default, a device denies all traffic in all directions. Through the creation of policies, you can control the traffic flow from zone to zone by defining the kinds of traffic permitted to pass from specified sources to specified destinations at scheduled times. At the broadest level, you can allow all kinds of traffic from any source in one zone to any destination in all other zones without any scheduling restrictions. At the narrowest level, you can create a policy that allows only one kind of traffic between a specified host in one zone and another specified host in another zone during a scheduled interval of time. See Figure 12.
Figure 12: Default Policy

Every time a packet attempts to pass from one zone to another or between two interfaces bound to the same zone, the device checks for a policy that permits such traffic (see Policy Application Sets Overview). To allow traffic to pass from one security zone to another—for example, from zone A to zone B—you must configure a policy that permits zone A to send traffic to zone B. To allow traffic to flow the other way, you must configure another policy permitting traffic from zone B to zone A.
To allow data traffic to pass between zones, you must configure firewall policies.
This topic covers:
The security policy applies the security rules to the transit traffic within a context (from-zone to to-zone). Each policy is uniquely identified by its name. The traffic is classified by matching its source and destination zones, the source and destination addresses, and the application that the traffic carries in its protocol headers with the policy database in the data plane.
Before You Begin |
|---|
For background information, read Security Policies Overview. |
Each policy is associated with the following characteristics:
These characteristics are called the match criteria. Each policy also has actions associated with it: permit, deny, and reject. You have to specify the match condition arguments when you configure a policy, source address, destination address, and application name. If you do not want to specify a specific application, enter any as the default application, indicating all possible applications. For example, if you do not supply an application name, then the policy is installed with the application as a wildcard (default). Therefore, any data traffic that matches the rest of the parameters in a given policy would match the policy regardless of the application type of the data traffic.
When you are creating a policy, the following policy rules apply:
Any policy configured with the to-zone as a global zone must have a single destination address to indicate that either static NAT or incoming NAT has been configured in the policy.
A policy permits, denies, or tunnels specified types of traffic unidirectionally between two points.
To define a policy, you need:
Each policy consists of:
The following example shows a policy configuration that allows traffic from the green zone (from-zone) to the red zone (to-zone).
user@host# set security policies from-zone green to-zone red policy abctopublic match source-address abc
user@host# set security policies from-zone red to-zone green policy abctopublic match destination-address public
user@host# set security policies from-zone red to-zone green policy abctopublic match application ssh
user@host# set security policies from-zone red to-zone green policy abctopublic then permit
For more information on the policy configuration syntax and options, see the JUNOS Software CLI Reference.
You must complete the following tasks to create a security policy: