Which source NAT method overloads the SRX egress interface IP using port translation?

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.

Static and destination NAT are evaluated at what point?

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.

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?

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.

Phase 1 of a route-based VPN is up but no traffic passes and no IPsec SA forms. Most likely cause?

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.

An interviewer asks why route-based VPN is preferred for a growing multi-site network. Best answer?

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.

Why are Screens applied before the security policy rather than after?

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.

Juniper SRX NAT, IPsec VPN, Screens & UTM/IDP — Hands-On Security Services (2026)

Q: Which NAT type is a fixed one-to-one mapping that works in both directions?

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.

Q: An interviewer asks why you chose a route-based VPN over policy-based for a multi-subnet branch link. Best answer?

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.

Q: When does the SRX apply Screen (IDS) checks relative to the security policy?

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.

Q: You must block exploit attempts against an internal server, including server-to-client attacks. Which service?

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.

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.

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.

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 NATb) Pool source NATc) Static NATd) 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.

Figure 4 — One SRX, every security service

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.

🔁

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 st0A branch host sends to an HQ subnet; the branch SRX's route points that subnet at the st0.0 secure tunnel interface.

▼

② IKE upIKE Phase 1 authenticates the peers and Phase 2 builds the IPsec SA, so the tunnel to HQ is established.

▼

③ Encrypt + sendThe SRX encapsulates and encrypts the packet in IPsec (ESP) and sends it across the internet to the HQ peer.

▼

④ Decrypt + deliverHQ'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.

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 betterb) Route-based binds to an st0 interface, so you route many subnets in and run dynamic routing — it scalesc) Route-based needs no IKE phased) 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 scanningb) Before the security policyc) Only inside the VPNd) 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 filteringb) Screensc) IDP/IPS with attack signaturesd) 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.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

🧠 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.

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.

📩 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 →

Juniper SRX Security Services — NAT, IPsec VPN, Screens & UTM/IDP

🎯 By the end you will be able to

Pick where you want to start

NAT on the SRX

IPsec site-to-site VPN

Screens (IDS)

UTM & IDP/IPS

① NAT on the SRX — source, destination, static and proxy-ARP

Order and proxy-ARP

② IPsec site-to-site VPN — route-based vs policy-based

The big interview question

▶ Watch a branch packet cross a route-based VPN

③ Screens (IDS) — drop floods and scans before policy

④ UTM and IDP/IPS — inspecting the allowed payload

UTM vs IDP/IPS

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?