JN0-335

Security Zones Fundamentals

Security zones are the core building block of Junos SRX firewall policy. A zone is a logical grouping of one or more interfaces that share an identical security level. All traffic traversing the SRX must have a clearly defined from-zone and to-zone, and policy evaluation is performed in the context of that zone pair.

• Security zones — user-defined zones such as trust, untrust, or dmz that contain revenue interfaces.
• Functional zones — special-purpose zones (for example, the management zone on fxp0) that are not used for transit traffic.
• Junos-host zone — the implicit zone representing the control plane / Routing Engine itself; host-bound traffic is policed by from-zone <zone> to-zone junos-host policies.
• An interface may only belong to one security zone at a time.

Configuring Zones and Interfaces

set security zones security-zone trust interfaces ge-0/0/0.0
set security zones security-zone trust host-inbound-traffic system-services ssh
set security zones security-zone trust host-inbound-traffic system-services ping
set security zones security-zone trust host-inbound-traffic system-services dhcp
set security zones security-zone trust host-inbound-traffic protocols ospf

set security zones security-zone untrust interfaces ge-0/0/1.0
set security zones security-zone untrust host-inbound-traffic system-services ike
set security zones security-zone untrust screen untrust-screen

set security zones security-zone dmz interfaces ge-0/0/2.0
set security zones security-zone dmz host-inbound-traffic system-services https

host-inbound-traffic controls which services and routing protocols the SRX itself will accept on interfaces in that zone. Omitting it results in all host-bound packets being dropped — a common troubleshooting pitfall.

Security Policy Match Criteria

A security policy is a 5-tuple rule evaluated top-down within a given from-zone / to-zone context. First match wins. Default action if no policy matches is deny.

Zone-Based Policy Example

set security address-book global address WEB-SERVER 10.1.1.50/32
set security address-book global address LAN-NET 192.168.10.0/24

set security policies from-zone trust to-zone untrust policy ALLOW-WEB match source-address LAN-NET
set security policies from-zone trust to-zone untrust policy ALLOW-WEB match destination-address any
set security policies from-zone trust to-zone untrust policy ALLOW-WEB match application [ junos-http junos-https junos-dns-udp ]
set security policies from-zone trust to-zone untrust policy ALLOW-WEB then permit
set security policies from-zone trust to-zone untrust policy ALLOW-WEB then log session-close
set security policies from-zone trust to-zone untrust policy ALLOW-WEB then count

set security policies from-zone untrust to-zone dmz policy INBOUND-WEB match source-address any
set security policies from-zone untrust to-zone dmz policy INBOUND-WEB match destination-address WEB-SERVER
set security policies from-zone untrust to-zone dmz policy INBOUND-WEB match application [ junos-http junos-https ]
set security policies from-zone untrust to-zone dmz policy INBOUND-WEB then permit

Global Policies & Unified Policies

• Global policies are evaluated after regular zone-based policies and can match any from/to zone combination — useful for catch-all or blacklists.
• Unified policies (Junos 18.2+) introduce dynamic-application as a match criterion, integrating AppID directly into the policy lookup. No separate application firewall ruleset is required.
• When a unified policy match is pending Layer-7 identification, Junos uses a default-rule policy and re-evaluates once AppID completes.

set security policies global policy BLOCK-FACEBOOK match source-address any
set security policies global policy BLOCK-FACEBOOK match destination-address any
set security policies global policy BLOCK-FACEBOOK match dynamic-application junos:FACEBOOK-ACCESS
set security policies global policy BLOCK-FACEBOOK then deny
set security policies global policy BLOCK-FACEBOOK then log session-init

Policy Schedulers

Schedulers allow a policy to be active only during specified time ranges — e.g., block social media during business hours.

set schedulers scheduler BUSINESS-HOURS daily start-time 09:00:00 stop-time 17:00:00
set schedulers scheduler BUSINESS-HOURS daily exclude sunday
set security policies from-zone trust to-zone untrust policy SOCIAL-BLOCK scheduler-name BUSINESS-HOURS

Verification Commands

show security zones
show security zones detail
show security policies
show security policies from-zone trust to-zone untrust
show security policies hit-count
show security policies detail policy-name ALLOW-WEB
show security match-policies from-zone trust to-zone untrust source-ip 192.168.10.10 destination-ip 8.8.8.8 protocol udp destination-port 53
show security flow session source-prefix 192.168.10.0/24

show security match-policies is the single most important troubleshooting command — it simulates a packet through the policy engine and tells you exactly which policy would hit.

IPsec VPN Overview

Junos SRX supports IKEv1 and IKEv2 site-to-site IPsec VPNs in two deployment models: policy-based (legacy, uses a tunnel action inside a security policy) and route-based (modern, uses a secure tunnel st0 interface as the routing next-hop). Route-based is preferred because it supports dynamic routing, multipoint VPN, and cleaner QoS/monitoring.

IKE Phase 1 — Main vs Aggressive

• Main mode — six messages, identity is encrypted, requires static peer IPs, most secure.
• Aggressive mode — three messages, identity sent in clear, used for dynamic-IP peers (road warriors, dial-up).
• IKEv2 — four messages (IKE_SA_INIT + IKE_AUTH), mandatory Dead-Peer-Detection, built-in NAT-T, EAP auth.

Route-Based IKEv2 Site-to-Site Configuration

# ----- IKE / Phase 1 -----
set security ike proposal IKE-P2 authentication-method pre-shared-keys
set security ike proposal IKE-P2 dh-group group14
set security ike proposal IKE-P2 authentication-algorithm sha-256
set security ike proposal IKE-P2 encryption-algorithm aes-256-cbc
set security ike proposal IKE-P2 lifetime-seconds 28800

set security ike policy IKE-POL mode main
set security ike policy IKE-POL proposals IKE-P2
set security ike policy IKE-POL pre-shared-key ascii-text "Str0ngS3cret!"

set security ike gateway GW-BRANCH ike-policy IKE-POL
set security ike gateway GW-BRANCH address 198.51.100.10
set security ike gateway GW-BRANCH external-interface ge-0/0/1.0
set security ike gateway GW-BRANCH version v2-only
set security ike gateway GW-BRANCH dead-peer-detection always-send interval 20 threshold 3

# ----- IPsec / Phase 2 -----
set security ipsec proposal IPSEC-P2 protocol esp
set security ipsec proposal IPSEC-P2 authentication-algorithm hmac-sha-256-128
set security ipsec proposal IPSEC-P2 encryption-algorithm aes-256-cbc
set security ipsec proposal IPSEC-P2 lifetime-seconds 3600

set security ipsec policy IPSEC-POL perfect-forward-secrecy keys group14
set security ipsec policy IPSEC-POL proposals IPSEC-P2

set security ipsec vpn VPN-BRANCH bind-interface st0.0
set security ipsec vpn VPN-BRANCH ike gateway GW-BRANCH
set security ipsec vpn VPN-BRANCH ike ipsec-policy IPSEC-POL
set security ipsec vpn VPN-BRANCH establish-tunnels immediately

# ----- st0 and Routing -----
set interfaces st0 unit 0 family inet address 10.255.0.1/30
set security zones security-zone vpn interfaces st0.0
set routing-options static route 10.20.0.0/16 next-hop st0.0

PSK vs Certificate Authentication

• PSK — simple, fast to deploy, but vulnerable to offline dictionary attacks if Aggressive mode is used; shared secret management at scale is painful.
• PKI / X.509 certs — scales better, integrates with Juniper PKI hierarchy (set security pki ca-profile), enforces identity via SubjectDN or SAN.
• Certificate workflow: generate keypair → generate CSR → load CA cert → enroll local cert → reference in IKE policy with certificate local-certificate.

AutoVPN and ADVPN

• AutoVPN — hub-and-spoke IPsec with a single configuration on the hub; spokes join dynamically using certificates. Ideal for many-branch deployments where spoke IPs are dynamic.
• ADVPN (Auto-Discovery VPN) — dynamic spoke-to-spoke shortcut tunnels built on top of AutoVPN when two spokes detect sustained traffic via the hub. Uses IKEv2 redirect messages.
• Both require OSPF or iBGP over the st0 overlay with the hub as route reflector / DR.

VPN Verification & Traceoptions

show security ike security-associations
show security ike security-associations detail
show security ipsec security-associations
show security ipsec statistics
show security ipsec inactive-tunnels
clear security ike security-associations
clear security ipsec security-associations

# Troubleshoot with traceoptions (writes to /var/log/kmd)
set security ike traceoptions file kmd-ike.log
set security ike traceoptions flag ike
set security ike traceoptions flag general
set security ipsec traceoptions flag packet-processing

NAT on Junos SRX

Junos implements three distinct, independently configured NAT types. They are evaluated at different stages of the flow pipeline:

1. Static NAT — 1:1 bidirectional, evaluated first (before route/policy lookup).
2. Destination NAT — evaluated after static NAT, before route lookup; changes the destination IP/port.
3. Source NAT — evaluated last, after policy permit; changes the source IP/port on egress.

Source NAT — Interface, Pool, and Static

# Interface-based (PAT using egress interface address)
set security nat source rule-set TRUST-TO-UNTRUST from zone trust
set security nat source rule-set TRUST-TO-UNTRUST to zone untrust
set security nat source rule-set TRUST-TO-UNTRUST rule SRC-NAT-ALL match source-address 192.168.0.0/16
set security nat source rule-set TRUST-TO-UNTRUST rule SRC-NAT-ALL then source-nat interface

# Pool-based (dedicated public IP range)
set security nat source pool PUB-POOL address 203.0.113.10/32 to 203.0.113.20/32
set security nat source pool PUB-POOL port no-translation
set security nat source rule-set TRUST-TO-UNTRUST rule POOL-NAT match source-address 10.0.0.0/8
set security nat source rule-set TRUST-TO-UNTRUST rule POOL-NAT then source-nat pool PUB-POOL

Destination NAT & Port Forwarding

set security nat destination pool WEB-SERVER-POOL address 10.1.1.50/32 port 80
set security nat destination rule-set DNAT-INBOUND from zone untrust
set security nat destination rule-set DNAT-INBOUND rule WEB-FORWARD match destination-address 203.0.113.5/32
set security nat destination rule-set DNAT-INBOUND rule WEB-FORWARD match destination-port 8080
set security nat destination rule-set DNAT-INBOUND rule WEB-FORWARD then destination-nat pool WEB-SERVER-POOL

# IMPORTANT: destination NAT runs BEFORE route lookup, so the security policy
# must match on the POST-NAT (translated) destination address.
set security policies from-zone untrust to-zone dmz policy INBOUND match destination-address WEB-SERVER
set security policies from-zone untrust to-zone dmz policy INBOUND then permit

Static NAT (Bidirectional 1:1)

set security nat static rule-set STATIC-NAT from zone untrust
set security nat static rule-set STATIC-NAT rule SERVER-MAP match destination-address 203.0.113.25/32
set security nat static rule-set STATIC-NAT rule SERVER-MAP then static-nat prefix 10.1.1.25/32

# Reverse direction automatic (10.1.1.25 -> 203.0.113.25 when initiated from DMZ outbound)

Static NAT is the only form of NAT that is stateless and bidirectional by definition — no session table entry is required for the reverse direction.

Proxy-ARP

If the translated public IP is not configured on the egress interface but is in the same subnet, the SRX must respond to ARP for it. Configure proxy-ARP manually:

set security nat proxy-arp interface ge-0/0/1.0 address 203.0.113.5/32
set security nat proxy-arp interface ge-0/0/1.0 address 203.0.113.10/32 to 203.0.113.20/32

Persistent NAT, NAT64/DNS64, Hairpinning

• Persistent NAT — required for applications like SIP/STUN where the same internal host:port must map to the same external host:port across sessions. Modes: any-remote-host, target-host, target-host-port.
• NAT64 / DNS64 — lets IPv6-only clients reach IPv4 servers. DNS64 synthesizes AAAA records from A records using the 64:ff9b::/96 well-known prefix; NAT64 translates the traffic.
• Hairpinning — internal client reaches an internal server via its public NAT address. Requires matching source-NAT rule in the same from-zone / to-zone as the destination-NAT (zone = itself).

set security nat source pool PN-POOL address 203.0.113.30/32
set security nat source pool PN-POOL port range 40000 to 50000
set security nat source rule-set TRUST-TO-UNTRUST rule SIP-PN match source-address 192.168.20.0/24
set security nat source rule-set TRUST-TO-UNTRUST rule SIP-PN then source-nat pool PN-POOL persistent-nat permit any-remote-host

NAT Verification

show security nat source summary
show security nat destination summary
show security nat static rule all
show security nat source pool PUB-POOL
show security flow session nat
show security nat source persistent-nat-table all

Screen Options Overview

Screens are first-packet stateless DoS/anomaly detection checks applied on the ingress zone before session creation. They are the SRX's front-line defense against floods, reconnaissance, and malformed-packet attacks. A screen profile (ids-option) is attached to a zone.

Because they run before session lookup, screens consume far fewer CPU cycles than policy-based filtering and are the correct place to mitigate volumetric attacks.

Common Screen Categories

Building a Screen Profile

set security screen ids-option UNTRUST-SCREEN alarm-without-drop
set security screen ids-option UNTRUST-SCREEN icmp flood threshold 1000
set security screen ids-option UNTRUST-SCREEN icmp ping-death
set security screen ids-option UNTRUST-SCREEN icmp large
set security screen ids-option UNTRUST-SCREEN icmp ip-sweep threshold 5000

set security screen ids-option UNTRUST-SCREEN ip spoofing
set security screen ids-option UNTRUST-SCREEN ip tear-drop
set security screen ids-option UNTRUST-SCREEN ip source-route-option

set security screen ids-option UNTRUST-SCREEN tcp syn-flood alarm-threshold 1024
set security screen ids-option UNTRUST-SCREEN tcp syn-flood attack-threshold 200
set security screen ids-option UNTRUST-SCREEN tcp syn-flood source-threshold 1024
set security screen ids-option UNTRUST-SCREEN tcp syn-flood destination-threshold 2048
set security screen ids-option UNTRUST-SCREEN tcp syn-flood timeout 20
set security screen ids-option UNTRUST-SCREEN tcp land
set security screen ids-option UNTRUST-SCREEN tcp winnuke
set security screen ids-option UNTRUST-SCREEN tcp port-scan threshold 5000
set security screen ids-option UNTRUST-SCREEN tcp syn-fin

set security screen ids-option UNTRUST-SCREEN udp flood threshold 1000
set security screen ids-option UNTRUST-SCREEN udp port-scan threshold 5000

# Apply to the untrust zone
set security zones security-zone untrust screen UNTRUST-SCREEN

Notable Attack Signatures

• SYN flood — half-open connections exhaust resources. Mitigation: SYN cookies triggered above attack-threshold.
• LAND attack — packet with source IP and destination IP identical; old OS bugs could lock up on self-reply.
• Ping-of-Death — oversized fragmented ICMP reassembled to >65535 bytes.
• WinNuke — OOB data sent to TCP/139 (NetBIOS) causing BSOD on legacy Windows.
• Tear-Drop — overlapping IP fragments that crash vulnerable stacks during reassembly.
• IP Spoofing — SRX reverse-path-forwarding check; packet must arrive on the interface the route table would use to reach its source.

Alarm-Only vs Drop Mode

Every screen profile can be globally placed in alarm-without-drop mode — checks still fire and counters increment, but traffic is not dropped. This is essential for baselining thresholds in production before enforcement.

set security screen ids-option UNTRUST-SCREEN alarm-without-drop

Monitoring & Troubleshooting

show security screen ids-option UNTRUST-SCREEN
show security screen statistics zone untrust
show security screen statistics interface ge-0/0/1.0
clear security screen statistics zone untrust
show log messages | match RT_SCREEN

Events appear in syslog under the RT_SCREEN_TCP, RT_SCREEN_UDP, and RT_SCREEN_IP categories — forward these to your SIEM.

Application Layer Gateways (ALGs)

ALGs are protocol helpers that inspect application-layer payloads to open dynamic pinholes (secondary sessions) and to rewrite embedded IP/port references so NAT doesn't break the protocol. On SRX most ALGs are enabled by default — disable the ones you do not need to reduce attack surface.

show security alg status
set security alg sip disable       # disable if not using VoIP
set security alg ftp ftps-extension

Anti-Virus

• Sophos AV (default) — cloud-assisted hash lookup, very low memory footprint, works on SRX300 line.
• Juniper Express AV — on-box signature scanning (legacy).
• Supported protocols: HTTP, SMTP, POP3, IMAP, FTP.

set security utm feature-profile anti-virus type sophos-engine
set security utm feature-profile anti-virus sophos-engine profile AV-PROF fallback-options default block
set security utm feature-profile anti-virus sophos-engine profile AV-PROF scan-options uri-check
set security utm utm-policy UTM-POL anti-virus http-profile AV-PROF
set security policies from-zone trust to-zone untrust policy ALLOW-WEB then permit application-services utm-policy UTM-POL

Anti-Spam & Content Filtering

• Anti-spam — SBL (Spam Block List) server lookups on SMTP traffic; action tag-header, tag-subject, or block.
• Content filtering — MIME/file-extension/protocol-command blocking, independent of AV engine; e.g., strip .exe, .bat, .js from HTTP/SMTP.

set security utm feature-profile content-filtering profile CF-PROF block-extension exe
set security utm feature-profile content-filtering profile CF-PROF block-extension bat
set security utm feature-profile content-filtering profile CF-PROF block-mime-pattern BAD-MIME
set security utm utm-policy UTM-POL content-filtering http-profile CF-PROF

Web Filtering Engines

set security utm feature-profile web-filtering type juniper-enhanced
set security utm feature-profile web-filtering juniper-enhanced profile EWF-PROF category Enhanced_Adult_Material action block
set security utm feature-profile web-filtering juniper-enhanced profile EWF-PROF category Enhanced_Gambling action block
set security utm feature-profile web-filtering juniper-enhanced profile EWF-PROF default permit
set security utm feature-profile web-filtering juniper-enhanced profile EWF-PROF site-reputation-action very-unsafe block
set security utm utm-policy UTM-POL web-filtering http-profile EWF-PROF

Juniper SecIntel (Security Intelligence)

SecIntel delivers threat feeds from Juniper ATP Cloud directly to the SRX data plane:

• C&C feed — block known botnet command-and-control endpoints.
• Infected-hosts feed — quarantine internal hosts observed uploading malware.
• GeoIP feed — block traffic from/to specific countries.
• Custom feeds — ingest any HTTPS-hosted URL of IPs/URLs.

set services security-intelligence profile CC-PROF category CC
set services security-intelligence profile CC-PROF rule RULE-1 match threat-level [ 8 9 10 ]
set services security-intelligence profile CC-PROF rule RULE-1 then action block drop
set services security-intelligence policy SI-POLICY CC CC-PROF
set security policies from-zone trust to-zone untrust policy ALLOW-WEB then permit application-services security-intelligence-policy SI-POLICY

Chassis Cluster Overview

Chassis cluster is Juniper's stateful HA feature: two identical SRX devices operate as one logical firewall, sharing session state, configuration, and — optionally — dataplane forwarding. Cluster behavior is organized around redundancy groups (RGs), each of which is active (primary) on exactly one node at a time.

Redundancy Groups

Control, Fabric, and Reth Links

• Control link — fxp1 (or predefined on branch SRX). Runs jsrpd heartbeats, configuration sync; loss = split-brain unless preempt disabled.
• Fabric link (fab0/fab1) — carries dataplane packet forwarding (RTO sync, Z-mode traffic) between nodes.
• Reth (redundant Ethernet) — pseudo interface made up of one physical from each node; the active node's child presents the MAC+IP outward.
• ICL (inter-chassis link) — on high-end SRX with dual chassis, used for SPU synchronization.

Cluster Configuration

# Operational commands on each node (reboot required)
# Node 0:
set chassis cluster cluster-id 1 node 0 reboot
# Node 1:
set chassis cluster cluster-id 1 node 1 reboot

# Configuration (sync'd after cluster forms)
set groups node0 system host-name SRX-A
set groups node1 system host-name SRX-B
set apply-groups "${node}"

set interfaces fab0 fabric-options member-interfaces ge-0/0/3
set interfaces fab1 fabric-options member-interfaces ge-7/0/3

set chassis cluster reth-count 4
set chassis cluster redundancy-group 0 node 0 priority 200
set chassis cluster redundancy-group 0 node 1 priority 100
set chassis cluster redundancy-group 1 node 0 priority 200
set chassis cluster redundancy-group 1 node 1 priority 100
set chassis cluster redundancy-group 1 preempt
set chassis cluster redundancy-group 1 interface-monitor ge-0/0/1 weight 255
set chassis cluster redundancy-group 1 interface-monitor ge-7/0/1 weight 255

set interfaces ge-0/0/1 gigether-options redundant-parent reth1
set interfaces ge-7/0/1 gigether-options redundant-parent reth1
set interfaces reth1 redundant-ether-options redundancy-group 1
set interfaces reth1 unit 0 family inet address 10.1.1.1/24

Active/Passive vs Active/Active

• Active/Passive — a single RG1 owns all reths; node0 is primary, node1 is cold-warm standby carrying sync state only.
• Active/Active — multiple RGs (RG1, RG2, …) split so node0 is primary for half the reths and node1 primary for the other half; achieves ~2× throughput but traffic may traverse the fabric link (Z-mode) if asymmetric.

Failover Triggers & jsrpd

• jsrpd (Junos SRP daemon) runs heartbeats across the control link; loss of consecutive hellos triggers failover.
• Failover occurs when RG priority drops — via interface monitoring (link flap subtracts weight), IP monitoring (pingable upstream gateway), or manual failover (request chassis cluster failover).
• Preempt — when higher-priority node returns, it reclaims primary; typically enabled on RG1+, disabled on RG0 to avoid RE flapping.
• ISSU (In-Service Software Upgrade) — upgrade one node, failover, upgrade the other; sessions preserved.

Verification & Manual Failover

show chassis cluster status
show chassis cluster status redundancy-group 1
show chassis cluster interfaces
show chassis cluster information
show chassis cluster statistics
show chassis cluster control-plane statistics
show chassis cluster data-plane statistics

# Manual failover (requires reason code; preempt must be configured or it sticks)
request chassis cluster failover redundancy-group 1 node 1
request chassis cluster failover reset redundancy-group 1

# Disable cluster
set chassis cluster disable reboot

Split-brain (both nodes primary) occurs when the control link is down but fabric is up — disable interface preempt and use dual control links on high-end SRX to avoid it.