# Juniper SRX Security Services — NAT, IPsec VPN, Screens & UTM/IDP Source: https://ai.techclick.in/blog_juniper_srx_nat_vpn_screens Markdown: https://ai.techclick.in/blog_juniper_srx_nat_vpn_screens.md Publisher: Techclick Infosec Pvt Ltd A clear, interactive guide to Juniper SRX security services (2026): source NAT (interface and pool), destination NAT and static NAT with proxy-ARP and the real processing order; route-based vs policy-based IPsec site-to-site VPN with IKE/IPsec proposals and the st0 secure tunnel interface; Screens (IDS) against floods and scans; and UTM (AV/web/content) plus IDP/IPS basics — with the Junos CLI you'll actually type. Juniper SRX Security Services — NAT, IPsec VPN, Screens & UTM/IDP student learning map A visual study map for Juniper SRX Security Services — NAT, IPsec VPN, Screens & UTM/IDP showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Juniper SRX Security Services — NAT, IPsec VPN,... Juniper · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① NAT on the SRX — source,... 4. Practice ② IPsec site-to-site VPN —... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most people lump every SRX feature into 'the firewall blocks traffic'. In an interview that costs you — security services are distinct stages, each with its own job and its own place in the packet's journey. On the SRX, NAT rewrites addresses (source, destination or static), IPsec VPN tunnels sites together (route-based via an st0 interface or policy-based inside a policy), Screens drop floods and scans before policy, and UTM/IDP inspect the allowed payload. Knowing the order — Screen, then NAT and policy, then UTM/IDP — and why route-based VPN scales better than policy-based is exactly what separates a configured box from an engineer who understands it. ## ① NAT on the SRX — source, destination, static and proxy-ARP NAT rewrites IP addresses (and often ports) as packets cross the SRX. There are three rule-set types. Source NAT changes the source address of outbound traffic: interface NAT overloads the egress interface IP with port translation (PAT) for many-to-one, while pool NAT translates to a defined address range, with or without PAT. Destination NAT rewrites the destination of inbound traffic — e.g. a public IP redirected to an internal web server. Static NAT is a fixed one-to-one map that works bidirectionally . ### Order and proxy-ARP The processing order matters: static NAT and destination NAT are evaluated before route and security-policy lookup , while source NAT is evaluated after them. So your security policy must match the translated destination but the original source. When a pool, static or destination address sits on the same subnet as an SRX interface, you also configure proxy-ARP so the SRX answers ARP for those addresses. Figure 1 — How a packet flows through SRX services Screens fire first, then NAT and policy decide reachability, then UTM/IDP inspect the allowed payload. - How a packet flows through SRX services Screen floods / scans Dest/Static NAT before route+policy Policy permit / deny Source NAT after policy UTM / IDP scan payload Screens fire first, then NAT and policy decide reachability, then UTM/IDP inspect the allowed payload. Figure 2 — The three NAT types at a glance Source NAT hides outbound hosts; destination NAT publishes inbound servers; static NAT is a fixed two-way map. The three NAT types at a glance Source NAT Rewrites the source IP outbound Interface NAT = overload egress IP Pool NAT = a defined range Evaluated AFTER route + policy Destination / Static NAT Dest NAT rewrites inbound dest IP Static NAT = fixed 1:1, Both evaluated BEFORE route + Proxy-ARP if on interface subnet Source NAT hides outbound hosts; destination NAT publishes inbound servers; static NAT is a fixed two-way map. Match policy to the translated destination Because static and destination NAT run before route and policy lookup, your security policy must reference the TRANSLATED (internal) destination address, not the original public one. Source NAT is the opposite — it runs after policy, so policy still sees the original source. Quick check · Q1 of 10 · Understand Which NAT type is a fixed one-to-one mapping that works in both directions? a) Interface source NAT b) Pool source NAT c) Static NAT d) Destination NAT Correct: c. Static NAT is a fixed 1:1 bidirectional map. Source NAT (interface/pool) rewrites outbound sources; destination NAT rewrites inbound destinations and is one-way. 👉 So far: Three NAT types: source (interface/pool, after policy), destination (inbound, before policy) and static (1:1 bidirectional, before policy). Add proxy-ARP when the NAT address is on an interface subnet. ## ② IPsec site-to-site VPN — route-based vs policy-based An IPsec site-to-site VPN is built in two phases. IKE (Phase 1) authenticates the peers and builds a secure management channel using an IKE proposal (authentication method, Diffie-Hellman group, auth and encryption algorithms, lifetime), an IKE policy and an IKE gateway (the peer address). IPsec (Phase 2) protects the real data using an IPsec proposal and policy, then a VPN object that ties it all together. ### The big interview question A route-based VPN binds the VPN to an st0 secure tunnel interface ; you push traffic into the tunnel with an ordinary route, and a security policy from the VPN zone controls it. A policy-based VPN has no st0 — instead the tunnel is referenced as an action inside a specific security policy. Route-based scales far better (many subnets, dynamic routing, simpler policy) and is the modern default; policy-based suits a few fixed flows or interop with legacy peers. Figure 3 — Building an IPsec VPN, phase by phase IKE secures the negotiation, IPsec protects the data, and the binding decides route-based vs policy-based. Building an IPsec VPN, phase by phase IKE (Phase 1) Proposal, policy, gateway (peer + auth) IPsec (Phase 2) Proposal + policy protect the real data VPN binding st0 (route-based) or inside a policy IKE secures the negotiation, IPsec protects the data, and the binding decides route-based vs policy-based. Figure 4 — One SRX, every security service All services share the same zone-and-policy core; each does one job on the packet. One SRX, every security service SRX core zones + policy Source NAT Dest / Static NAT IPsec VPN (st0) Screens (IDS) UTM filter IDP / IPS All services share the same zone-and-policy core; each does one job on the packet. Figure 5 — Route-based vs policy-based VPN Route-based binds to an st0 interface and routes traffic in; policy-based names the tunnel inside a security policy. Route-based vs policy-based VPN Route-based Binds VPN to st0.x interface Route steers traffic into tunnel Scales to many subnets + dynamic Modern default Policy-based No st0 interface Tunnel is an action in a policy Best for a few fixed flows Legacy / interop cases Route-based binds to an st0 interface and routes traffic in; policy-based names the tunnel inside a security policy. 🔁 Source NAT tap to flip Rewrites the source of outbound traffic. Interface NAT overloads the egress IP with PAT; pool NAT uses a defined range. Evaluated after route and policy lookup. 🎯 Destination NAT tap to flip Rewrites the destination of inbound traffic — publish an internal server on a public IP. Evaluated before route and policy, so policy matches the translated destination. ↔️ Static NAT tap to flip A fixed one-to-one map that works in both directions. Evaluated before route and policy; needs proxy-ARP if the address sits on an interface subnet. 🚇 st0 secure tunnel tap to flip The logical interface a route-based VPN binds to. You route traffic into st0.x and a security policy controls it — far more scalable than policy-based. 'A VPN is just a policy' under-sell Saying every VPN lives inside a security policy is the policy-based model — and it does not scale. Name the route-based model: bind the VPN to an st0 interface, route subnets into it, and run dynamic routing. That is the answer interviewers want in 2026. ### ▶ Watch a branch packet cross a route-based VPN How a packet from a branch host reaches HQ over IPsec. Press Play for the healthy path, then Break it to see the classic failure. ① Route to st0 A branch host sends to an HQ subnet; the branch SRX's route points that subnet at the st0.0 secure tunnel interface. ▼ ② IKE up IKE Phase 1 authenticates the peers and Phase 2 builds the IPsec SA, so the tunnel to HQ is established. ▼ ③ Encrypt + send The SRX encapsulates and encrypts the packet in IPsec (ESP) and sends it across the internet to the HQ peer. ▼ ④ Decrypt + deliver HQ's SRX decrypts, a security policy from the VPN zone permits it, and the packet is delivered to the HQ server. Press Play to step through the healthy tunnel path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q2 of 10 · Analyze An interviewer asks why you chose a route-based VPN over policy-based for a multi-subnet branch link. Best answer? a) Policy-based supports dynamic routing better b) Route-based binds to an st0 interface, so you route many subnets in and run dynamic routing — it scales c) Route-based needs no IKE phase d) They are identical in behaviour Correct: b. Route-based VPNs bind to an st0 secure tunnel interface; you steer any number of subnets with routes and can run dynamic routing, so they scale far better than policy-based tunnels named inside a single policy. 👉 So far: IPsec = IKE (proposal/policy/gateway) + IPsec (proposal/policy/VPN). Route-based binds to st0 and routes traffic in (scales); policy-based names the tunnel inside a security policy (legacy/few flows). ## ③ Screens (IDS) — drop floods and scans before policy Screens are the SRX's built-in IDS: a set of checks bound to a zone that drop malformed or abusive traffic. Crucially, Junos applies screen checks before security-policy processing , so junk is dropped early and uses fewer resources. Screens come in two families — statistics-based (rate thresholds) and signature-based (packet anomalies). Common protections: TCP SYN flood (clients send SYNs without completing the handshake), ICMP flood and UDP flood (rate thresholds per destination), and reconnaissance like TCP/UDP port scans and IP sweeps . You also block oddities such as land, teardrop, ping-of-death and IP spoofing. You group these into a screen profile (an ids-option set) and attach it to the untrust zone. Quick check · Q3 of 10 · Remember When does the SRX apply Screen (IDS) checks relative to the security policy? a) After UTM scanning b) Before the security policy c) Only inside the VPN d) After source NAT Correct: b. Junos applies screen checks before security-policy processing, so floods and scans are dropped early and use fewer resources than if they reached policy or UTM. 👉 So far: Screens are IDS checks applied before policy — SYN/ICMP/UDP floods, port scans, IP sweeps and packet anomalies — grouped in an ids-option set and attached to the untrust zone. ## ④ UTM and IDP/IPS — inspecting the allowed payload Once Screens and policy permit a flow, you can inspect the content . UTM (Content Security) bundles Layer-7 protections against client-side threats: antivirus scans downloads, web filtering permits or denies URLs by category or list, and content filtering blocks by MIME type, file extension or protocol command (basic data-loss control). These attach to a UTM policy that is applied within a security policy. ### UTM vs IDP/IPS UTM defends mostly client-to-server, signature-light traffic. IDP/IPS goes further: it matches deep attack signatures and protocol anomalies in both directions — including server-to-client exploits — and can drop, close or alert. The interview line: Screens stop floods, NAT and policy decide reachability, UTM filters content, and IDP/IPS catches exploits in the payload. Order of attachment and a current signature database are what make it effective in 2026. Vikram at a Pune manufacturer faces this He publishes an internal web server with destination NAT, but the inbound traffic is denied even though a permit policy exists from untrust to the DMZ. Likely cause The security policy was written to match the original public destination address, but destination NAT is evaluated before policy lookup — so policy sees the translated internal address. Diagnosis Run flow tracing — the session shows the destination already rewritten to the internal IP at policy lookup, which the policy's destination-address does not match. Junos CLI ▸ security flow traceoptions + show security flow session Fix Rewrite the security policy's destination-address to the translated internal server address (and add proxy-ARP if the public IP is on the interface subnet), then commit. Verify Re-test from outside: the session establishes, the server responds, and show security flow session shows the permitted, translated flow. Prove it with flow session, not a hunch Never close an SRX ticket on 'should work'. show security flow session reveals the real NAT translation, the matched policy, the zone pair and whether the tunnel is up. One read answers most NAT/VPN/UTM tickets without guessing. Quick check · Q4 of 10 · Apply You must block exploit attempts against an internal server, including server-to-client attacks. Which service? a) Web filtering b) Screens c) IDP/IPS with attack signatures d) Source NAT Correct: c. IDP/IPS matches deep attack signatures and protocol anomalies in both directions, including server-to-client exploits. UTM is mostly client-side Layer-7; Screens stop floods/scans; NAT only rewrites addresses. 👉 So far: UTM (antivirus, web filter, content filter) handles client-side Layer-7 content; IDP/IPS catches deep attack signatures in both directions. Order: Screen, then NAT+policy, then UTM/IDP. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What are the three NAT types on the SRX? Why does NAT processing order matter for my security policy? What is the difference between route-based and policy-based IPsec VPN? What are Screens and when do they run? How do UTM and IDP/IPS differ? What is the end-to-end order of SRX security services on a packet? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which source NAT method overloads the SRX egress interface IP using port translation? a) Pool NAT without PAT b) Interface NAT (PAT) c) Static NAT d) Destination NAT Correct: b. Interface source NAT overloads the egress interface IP for many-to-one with port translation (PAT). Pool NAT uses a defined range; static and destination NAT are different types entirely. Q6 · Understand Static and destination NAT are evaluated at what point? a) Before route and security-policy lookup b) After source NAT only c) After UTM scanning d) Only inside a VPN tunnel Correct: a. Static and destination NAT run before route and security-policy lookup, so the policy matches the translated destination. Source NAT runs after policy, so policy still sees the original source. Q7 · Apply You must publish an internal app server on a public IP that is on the SRX's interface subnet. What besides a destination NAT rule do you need? a) A policy-based VPN b) Interface source NAT c) A UTM antivirus profile d) Proxy-ARP for that address Correct: d. When the NAT address sits on the same subnet as an SRX interface, configure proxy-ARP so the SRX answers ARP for it. Without it, neighbours can't resolve the address and traffic never arrives. Q8 · Analyze Phase 1 of a route-based VPN is up but no traffic passes and no IPsec SA forms. Most likely cause? a) The st0 interface is missing an IP and that always blocks Phase 1 b) Screens are dropping the IKE packets c) Mismatched Phase 2 proxy-IDs / traffic selectors between peers d) The security policy permits the traffic Correct: c. Phase 1 up but no IPsec SA points to mismatched Phase 2 proxy-IDs/traffic selectors. Align them on both peers (or use a route-based any/any selector) and the SA forms. Q9 · Evaluate An interviewer asks why route-based VPN is preferred for a growing multi-site network. Best answer? a) It needs no IKE negotiation b) It binds to an st0 interface so you route many subnets in and run dynamic routing — it scales c) It encrypts faster than policy-based d) It does not require a security policy Correct: b. Route-based binds to st0, so any number of subnets are steered with routes and dynamic routing protocols can run over the tunnel — far more scalable than policy-based tunnels named inside individual policies. Q10 · Evaluate Why are Screens applied before the security policy rather than after? a) To drop floods and scans early, saving resources before policy and deep inspection b) So UTM runs first c) Because they only work on encrypted traffic d) To translate addresses sooner Correct: a. Junos applies screen checks ahead of policy so flood and scan traffic is discarded early with minimal resource use, before it can reach policy lookup or expensive UTM/IDP inspection. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: what is the order of SRX security services on a packet, and why does NAT order matter for policy? Then compare with the expert version. Compare with expert answer Expert version: Screens fire first and drop floods/scans before policy; then static and destination NAT rewrite the destination before route and security-policy lookup, so the policy must match the translated (internal) destination; the policy permits or denies; source NAT then rewrites the source after policy, so policy still sees the original source; and finally UTM and IDP/IPS inspect the permitted payload. NAT order matters because getting it backwards — writing a policy against the original public destination — produces the classic 'permit exists but traffic denied' bug, since by policy time the destination is already translated. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Juniper SRX at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Source NAT Rewrites the source address of outbound traffic — interface NAT overloads the egress IP (PAT); pool NAT uses a defined range. Evaluated after route and policy lookup. Destination NAT Rewrites the destination address of inbound traffic, e.g. publishing an internal server on a public IP. Evaluated before route and policy lookup. Static NAT A fixed one-to-one address map that works bidirectionally; evaluated before route and policy, and needs proxy-ARP if the address is on an interface subnet. Proxy-ARP Configuration that makes the SRX answer ARP for NAT addresses not bound to a physical interface, so neighbours can reach them. IKE / IPsec proposal IKE (Phase 1) sets auth method, DH group, auth and encryption algorithms and lifetime; IPsec (Phase 2) protects the actual data using its own proposal and policy. st0 secure tunnel interface The logical interface a route-based VPN binds to; you route traffic into st0.x and a security policy controls it. Route-based vs policy-based VPN Route-based binds the VPN to an st0 interface and routes traffic in (scales); policy-based references the tunnel as an action inside a security policy (legacy/few flows). Screen (IDS) Zone-attached checks applied before the security policy that drop floods (SYN/ICMP/UDP), scans, sweeps and packet anomalies. UTM (Content Security) Layer-7 client-side protection — antivirus, web filtering (URL category/list) and content filtering (MIME/extension/protocol command). IDP / IPS Deep inspection that matches attack signatures and protocol anomalies in both directions, including server-to-client exploits, on permitted traffic. #### 📚 Sources Juniper Networks — NAT Overview and NAT Configuration Overview (processing order, proxy-ARP) . juniper.net/documentation/us/en/software/junos/nat - Juniper Networks — Source NAT and Destination NAT (interface, pool, static; rule-sets) . juniper.net/documentation/us/en/software/junos/nat - Juniper Networks — Route-Based IPsec VPNs and Route-Based VPN with IKEv2 (st0, IKE/IPsec proposals) . juniper.net/documentation/us/en/software/junos/vpn-ipsec - Juniper Networks — Screens Options for Attack Detection and Prevention (statistics- and signature-based IDS) . juniper.net/documentation/us/en/software/junos/denial-of-service - Juniper Networks — Junos OS Content Security (UTM) User Guide, published 2025-12-07 (AV, web filtering, content filtering) . juniper.net/documentation/us/en/software/junos/utm - Juniper Networks — show security screen ids-option and Attack Detection & Prevention User Guide . juniper.net/documentation/us/en/software/junos/flow-packet-processing ### What's next? Want the foundation under all this? Revisit the first SRX lesson — Junos architecture, security zones, the security policy match, and the commit/rollback model — which everything here builds on. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt