Exam objective 5.3 asks you to configure security zones and the policies that control traffic between them. This chapter solves the problem of how to let the right traffic through your network while blocking everything else. For the JNCIA-JUNOS exam, understanding zones and policies is the most practical skill you will learn because it directly translates to building a real corporate firewall.
Jump to a section
A simple way to picture Junos Security Zones and Policies
An office building has a main entrance with a security desk. This desk is the firewall. Inside the building, different areas have different levels of access. The ground-floor lobby is a security zone called 'Public'. Anyone can walk in. The second floor holds the sales team; it is a zone called 'Sales_Trusted'. The third floor is the server room, a zone called 'High_Security'. The security guard controls traffic between these zones.
When an employee from Sales_Trusted wants to go to the server room (High_Security), the guard checks the employee's badge against a policy. The policy might say: 'Only people with red badges can enter the server room between 9am and 5pm.' This is an inter-zone policy. If two people in the same Sales_Trusted zone want to share a document, the guard checks a different policy for traffic inside the same zone. That is an intra-zone policy.
Every person entering the building is a packet. Their destination floor is the destination zone. Their source floor is the source zone. The security guard does not guess. The guard follows a set of written rules, just as a Junos device follows security policies. This specific office layout with defined zones and a guard at a single chokepoint is exactly how Junos Security Zones and Policies work on a router or switch. The building's floor plan is the zone configuration. The guard's rulebook is the policy list. Without these, anyone could wander anywhere, which is a security disaster.
A Juniper Networks device, like an SRX Series firewall, uses security zones to organise network interfaces. A security zone is a logical grouping of one or more interfaces that share a common security requirement. Think of a zone as a labelled container. You might put all the interfaces connected to your internal company network into a zone called 'Trust'. You might put the interface connected to the internet into a zone called 'Untrust'. The device does not know what traffic is 'good' or 'bad' by itself. It only knows what zone the traffic came from and what zone it is going to.
The magic happens with security policies. A security policy is a rule that decides what happens to traffic, based on its source zone, destination zone, source IP address, destination IP address, and the application (like HTTP for web traffic or SSH for secure shell access). Every policy has an action: either permit (let it through) or deny (block it).
There are two main types of traffic flow between zones. Inter-zone traffic is traffic moving from one zone to a different zone. For example, a user in the 'Trust' zone trying to reach a web server in the 'Untrust' zone. This is the most common type of traffic you will configure. Intra-zone traffic is traffic moving between two interfaces that belong to the same zone. For example, two computers both in the 'Trust' zone trying to talk to each other. By default, Junos devices block all inter-zone traffic and permit all intra-zone traffic. You use policies to change these defaults.
The device evaluates policies in a specific order, from top to bottom in the configuration. The first policy that matches the traffic is applied. This is called first-match logic. If no policy matches, the traffic is denied by an implicit default policy at the end. This default is called the default deny policy.
To configure this, you do three things:
Define the zone and assign interfaces to it.
Create a security policy that specifies source zone, destination zone, and the match conditions.
Set the action to permit or deny.
Why does this replace older methods? Before modern firewalls, people used Access Control Lists (ACLs) on routers, which were simple lists of allow/deny rules applied directly to an interface without any concept of zones. Zones provide more structure. They let you apply a single policy to multiple interfaces at once, and they make it easier to understand the security posture of your whole network at a glance. For the exam, you must understand that a policy always references the zone names, not the interface names. The interface is just a member of the zone.
A final critical point: screens. A screen is a Junos feature that protects against certain types of attacks, like IP spoofing or port scans. Screens are attached to a zone, not to a policy. If you enable a screen for the 'Untrust' zone, every packet entering that zone is checked against the screen rules before any policy is evaluated. Remember that screens are a zone-level protection, not a policy-level one.
Define the security zone
Create a zone using the 'set security zones security-zone <name>' command. This defines the container but does not yet assign any interfaces.
Assign interfaces to the zone
Use 'set security zones security-zone <name> interfaces <interface-name>' to add an interface. An interface can only belong to one zone. This step is crucial because traffic entering that interface is now subject to that zone's policies.
Create a security policy
Use 'set security policies from-zone <source-zone> to-zone <destination-zone> policy <policy-name>' to begin a policy definition. This creates the two-zone framework for the rule.
Define match conditions
Inside the policy, set the source address, destination address, and application. For example, 'set security policies from-zone Trust to-zone Untrust policy Allow-Web match source-address any destination-address any application junos-http'. These conditions tell the device what traffic this rule applies to.
Set the action
Use 'set security policies from-zone Trust to-zone Untrust policy Allow-Web then permit' to allow matching traffic. You can also use 'then deny' to block it. The action is the final decision the device makes for traffic that matches all conditions.
An IT professional at a small company, 'Bright Widgets Ltd', needs to set up a firewall. The company has three physical network segments: a public Wi-Fi for guests, an internal network for employees, and a server room for the company website. The IT pro configures three zones on an SRX firewall. - Zone 'Guest' has one interface, ge-0/0/0, connected to the guest Wi-Fi access point. - Zone 'Internal' has one interface, ge-0/0/1, connected to the employee network switch. - Zone 'DMZ' (a demilitarised zone) has one interface, ge-0/0/2, connected to the web server.
The IT pro now writes policies. Here is the step-by-step process:
Step 1: Create a policy called 'Allow_Employees_to_Internet'. Source zone: Internal. Destination zone: Guest (because the internet is reached through the guest zone's uplink in this simple setup). Source address: 192.168.1.0/24 (the employee subnet). Destination address: any. Application: any. Action: permit.
Step 2: Create a policy called 'Allow_Internet_to_Web'. Source zone: Guest. Destination zone: DMZ. Source address: any. Destination address: 10.0.0.5 (the web server's IP). Application: http. Action: permit.
Step 3: Create a policy called 'Deny_All_Guest_to_Internal'. Source zone: Guest. Destination zone: Internal. Action: deny. This ensures guests cannot reach the employee network.
Step 4: The final policy is the implicit default deny, which blocks anything not explicitly allowed.
The IT pro then tests by trying to browse the web from a guest laptop. The traffic matches 'Allow_Internet_to_Web' only if it is destined for the web server. For general internet access from the guest network, the IT pro realises he forgot a policy. He adds 'Allow_Guest_to_Internet' with source Guest, destination any, action permit. He also enables a screen called 'icmp-flood' on the Guest zone to prevent ping-based attacks.
This real scenario shows exactly what an IT professional does daily: identifying traffic flows, defining zones, writing policies, and testing. The exam expects you to understand this exact workflow, including the order of policies and the role of the default deny.
The JNCIA-JUNOS exam tests Security Zones and Policies heavily. You can expect around 5-8 questions on this topic. The exam loves to test your understanding of the default behaviour. A classic trap is asking: 'What is the default action for inter-zone traffic?' The wrong answer is 'permit', but the correct answer is 'deny'. Similarly, for intra-zone traffic, the default is 'permit'.
The exam also tests the structure of the policy. You will see questions like: 'Which statement is true about a security policy?' The correct answer will mention that a policy must have a source zone, a destination zone, and an action. Another common trap is asking about 'policies without zones' or 'policies that apply to all interfaces'. This is wrong; a policy always has at least one source zone and one destination zone.
Here are the key topics the exam focuses on:
The difference between inter-zone and intra-zone traffic flows.
The concept of the default deny policy.
The order of operations: screens are applied before policies.
The components of a security policy: source-zone, destination-zone, source-address, destination-address, application, action.
How to assign an interface to a zone.
The fact that a zone can contain multiple interfaces.
The idea that you must define a zone before you can reference it in a policy.
Traps to watch for:
A question says 'Traffic from zone A to zone A is intra-zone traffic.' That is true, but the exam might ask if the default action is deny. It is not; it is permit.
A question might list a policy with only a source zone and an action, leaving out the destination zone. This is an invalid configuration.
A question might claim that changing the order of policies does not matter. This is false; first-match logic means order is critical.
Definitions to memorise:
Security Zone: A logical grouping of interfaces that share a common security policy.
Security Policy: A rule that controls traffic based on source and destination zones and other criteria.
Inter-zone: Traffic between two different zones.
Intra-zone: Traffic within the same zone.
Default Deny: The implicit rule at the end of every policy list that drops unmatched traffic.
Screen: A zone-level protection against attacks, evaluated before policies.
Inter-zone traffic is denied by default; intra-zone traffic is permitted by default.
A security policy must specify source zone, destination zone, and action.
Policies are evaluated in order from top to bottom using first-match logic.
Screens protect against attacks at the zone level, before any policy is matched.
A zone can contain multiple interfaces, and a single interface can belong to only one zone.
The implicit default deny policy is always the last rule and blocks all unmatched traffic.
These come up on the exam all the time. Here's how to tell them apart.
Inter-zone Traffic
Traffic moves between two different security zones.
Default action is deny.
Requires an explicit policy to permit.
Intra-zone Traffic
Traffic stays within the same security zone.
Default action is permit.
Does not require a policy unless you want to restrict it.
Security Zone
A logical container for interfaces.
Defines the security boundary.
Does not contain rules by itself.
Security Policy
A rule that controls traffic flow.
References source and destination zones.
Includes match conditions and an action.
Screen
Configured on a zone, not on a policy.
Protects against specific attack types.
Evaluated before policy lookup.
Policy
Configured between two zones.
Controls access based on addresses and applications.
Evaluated after screen checks.
Mistake
Intra-zone traffic is blocked by default.
Correct
Intra-zone traffic is permitted by default in Junos.
This mistake is common because inter-zone traffic is blocked by default, and people assume the same rule applies to all traffic types.
Mistake
A security policy can be applied to a specific interface instead of a zone.
Correct
A security policy always references zones, not interfaces. Interfaces are members of zones.
Beginners who learn ACLs first think of rules tied to an interface. Junos zones abstract this level of detail.
Mistake
If no policy matches traffic, the traffic is permitted by default.
Correct
If no policy matches, the traffic is denied by the implicit default deny policy.
This misconception comes from a false sense of security; people assume a device is permissive unless told otherwise. The opposite is true.
Mistake
Screens are part of a security policy.
Correct
Screens are configured on a zone, not on a policy. They are evaluated before policy lookup.
The names 'screens' and 'policies' sound similar, so beginners assume they are configured together.
Mistake
You can have a policy without specifying a source zone.
Correct
Every policy must have at least a source zone and a destination zone.
Some vendors allow zone-less policies, but Junos requires explicit zone definitions.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Inter-zone traffic moves between two different security zones. Intra-zone traffic moves within the same zone. By default, inter-zone is blocked and intra-zone is allowed.
No. Each interface can belong to only one security zone at a time. If you try, the device will return a configuration error.
The traffic is denied by the implicit default deny policy. This is a built-in rule at the end of every policy list that drops any unmatched packets.
No. The default deny policy is automatically present and cannot be deleted. It is always the last rule.
A screen is a set of protection mechanisms that guard against attacks like IP spoofing or port scans. It is configured on a zone and evaluated before any policy.
Yes, you can insert or move policies using the 'insert' command. Order matters because the firewall uses first-match logic.
You've finished Junos Security Zones and Policies. Continue through the JNCIA-JUNOS study guide to build a complete picture of the exam.
Done with this chapter?