Most engineers think…
Most people treat IPsec VPN as 'configure the pre-shared key and it works'. That mental model breaks down fast in an interview and in production the moment you need to scale beyond two sites.
Juniper SRX IPsec is a two-mode system: route-based tunnels use an st0 secure-tunnel interface and the routing table to steer traffic, while policy-based tunnels use a tunnel action in a security policy and no st0. Understanding that split — and then layering on IKEv2, PKI, AutoVPN and ADVPN — is what separates a working engineer from one who copies config and hopes.
① Route-based vs policy-based — the most important choice
Juniper SRX supports two IPsec VPN modes that are not interchangeable. In a route-based VPN, a logical st0 interface is created, bound to the VPN, and traffic is routed into it just like any other interface. Security policies allow or deny traffic between the trust and VPN zones — but the st0 binding, not the policy, selects what goes through the tunnel.
In a policy-based VPN, there is no st0 interface. Instead, a security policy is written that matches the interesting traffic, and the action is set to tunnel with a named VPN. The tunnel is brought up on demand when a policy match happens. Policy-based VPN is simpler for a single site-to-site tunnel, but it does not support dynamic routing protocols (OSPF/BGP over the tunnel), AutoVPN, or ADVPN — all of which require route-based mode.
The interview rule: if you need dynamic routing, HA, AutoVPN, or ADVPN — use route-based. If you have a single static tunnel with a known subnet on each side and simplicity matters most, policy-based is acceptable. In practice, most enterprise deployments on Junos use route-based for flexibility.
Unless the question explicitly says 'simple static tunnel with no dynamic routing', always propose route-based VPN. It is more scalable, supports OSPF/BGP over st0, and is the only mode that works with AutoVPN and ADVPN. Mentioning this trade-off shows you understand Junos VPN architecture.
Which IPsec VPN mode on Juniper SRX supports running OSPF or BGP over the tunnel?
② IKE Phase 1 & Phase 2 — IKEv1 vs IKEv2
IPsec on SRX always follows the same two-phase model. Phase 1 (IKE SA) authenticates the two peers and establishes a secure, encrypted channel. Phase 2 (IPsec SA / Child SA) negotiates the actual encryption and integrity algorithms for the data tunnel and generates the keys. A failed Phase 1 means Phase 2 never starts — so always check Phase 1 first when debugging.
IKEv1 vs IKEv2
IKEv1 uses nine messages minimum (six for Main Mode + three for Quick Mode) split into two phases. IKEv2, defined in RFC 7296, collapses this into four messages in a single exchange: IKE_SA_INIT (2 msgs) + IKE_AUTH (2 msgs). IKEv2 gains built-in EAP support for user auth, dead peer detection built into the protocol, and stronger DOS resistance. On Junos, set version v2-only at the gateway hierarchy to lock to IKEv2. AutoVPN and ADVPN require IKEv2. Both peers must match: authentication method (pre-shared key or certificates), DH group, encryption algorithm and lifetime.
A logical interface on Junos bound to an IPsec VPN. Traffic routed to st0.X is encrypted and forwarded through the tunnel. Required for route-based VPNs, AutoVPN and ADVPN.
IKEv2 uses four messages (IKE_SA_INIT x2 + IKE_AUTH x2) vs IKEv1's nine. IKEv2 adds built-in EAP, dead-peer detection and better DOS resistance. Required for AutoVPN and ADVPN on Junos.
Hub SRX defines one tunnel; spokes authenticate by X.509 certificate DN. Any new spoke joins without touching hub config. The hub st0 runs in point-to-multipoint mode; routing runs over st0.
Extends AutoVPN: when two spokes communicate, the hub signals them to build a direct IKEv2 shortcut tunnel, cutting latency. Hub is the ADVPN suggester; spokes are ADVPN partners.
Both peers must agree on the same IKE proposal (DH group, encryption cipher, authentication method, lifetime) and both must use the same IKE version. A common mistake is leaving one side on IKEv1 and the other on IKEv2. Also check that the pre-shared key or certificate matches exactly — a one-character PSK typo is the most common Phase 1 failure.
What is the minimum number of messages IKEv2 uses to establish an IKE SA and the first Child SA?
③ AutoVPN, ADVPN & PKI — scaling beyond two sites
AutoVPN lets a hub SRX accept connections from any number of spoke SRXs using a single tunnel definition on the hub. The hub's IKE gateway uses an IKE ID type of distinguished-name (DN) matching the subject field of the spoke's X.509 certificate, rather than a fixed peer IP. This means you enrol each spoke with a CA certificate (using request security pki local-certificate enroll), and the hub authenticates any spoke whose DN matches — no changes to hub config for new spokes.
ADVPN (Auto-Discovery VPN) extends AutoVPN by adding IKEv2-based shortcut signalling. When Spoke A needs to reach Spoke B, all traffic initially flows hub-to-spoke (hairpin). The hub signals Spoke A and Spoke B to build a direct shortcut tunnel between themselves on demand. Latency drops dramatically once the shortcut forms. ADVPN requires IKEv2 and is configured by adding advpn suggester (hub) and advpn partner (spokes) configuration.
The st0 interface on a hub in AutoVPN/ADVPN mode is configured as point-to-multipoint (add multipoint under the st0 unit). On spokes it remains point-to-point. Dynamic routing (typically OSPF or BGP) runs over the st0 interfaces, and the hub redistributes spoke routes.
After spokes come up, run 'show security ike security-associations' on the hub — you should see one SA per connected spoke, all authenticated by certificate. Run 'show route table inet.0' to confirm spoke prefixes are being learned via dynamic routing over st0. An ADVPN shortcut can be confirmed with 'show security ipsec security-associations' — look for SA entries between spoke IPs that do not go through the hub.
▶ Watch an IKEv2 route-based tunnel come up end-to-end
Follow a branch SRX initiating an IKEv2 route-based IPsec tunnel to HQ. Press Play for the healthy path, then Break it to see the classic Phase 1 failure.
You are configuring an AutoVPN hub to accept 50 spoke SRXs. How does the hub authenticate each spoke without 50 separate gateway definitions?
④ Remote access & operational tips — Juniper Secure Connect & debug
Juniper Secure Connect is the Junos SRX remote-access IPsec VPN solution. It uses IKEv2 with EAP for user authentication (username/password or certificate), and the SRX acts as the IKEv2 gateway. A local address pool or external RADIUS assigns a virtual IP to each client. The client software (Juniper Secure Connect app) runs on Windows/macOS/iOS/Android. On the SRX, configure an access profile with the address pool, reference it in the IKE gateway with remote-access juniper-secure-connect, and the VPN policy routes client traffic.
Operational tips
For route-based VPNs, the three debug commands you must know are: show security ike security-associations (Phase 1 state), show security ipsec security-associations (Phase 2 SAs, bytes in/out), and show route table inet.0 (verify the tunnel route is present). A tunnel that is up but passes no traffic is almost always a routing or zone/policy miss. Check that the st0 interface is in the right security zone and that a policy permits traffic between trust and the VPN zone through st0.
Arjun at a Mumbai fintech company faces this
A new branch office IPsec VPN to HQ comes up (Phase 1 and Phase 2 both show active) but branch users cannot reach any HQ servers. Ping from the SRX itself fails too.
The st0.0 interface was left in the default zone (trust) instead of being placed in the dedicated VPN zone, and no policy exists permitting traffic from trust to trust via the tunnel.
Run 'show security ike security-associations' — both up. Run 'show security ipsec security-associations' — SA shows 0 bytes encrypted. Check 'show interfaces st0.0' — zone shows 'trust', not 'vpn'.
CLI ▸ show interfaces st0 ▸ show security zones ▸ show security policiesMove st0.0 to the VPN zone: 'set security zones security-zone vpn interfaces st0.0'. Add a policy from trust to vpn permitting the relevant subnets. Check 'show route 10.x.x.x' to confirm the static route via st0.0 is present.
Re-run 'show security ipsec security-associations' — bytes-encrypted counter now increments. Branch users reach HQ servers.
A route-based IPsec tunnel shows Phase 1 and Phase 2 up, but traffic is not passing. What is the most likely cause?
🤖 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.
📝 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.
🧠 In your own words
Type one line: what is the single most important reason to choose route-based over policy-based VPN on Juniper SRX? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- st0 (Secure Tunnel)
- A Junos logical interface type bound to an IPsec VPN. Traffic routed to st0.X is encrypted and forwarded through the tunnel — required for route-based VPN, AutoVPN and ADVPN.
- IKE SA
- The Phase 1 security association — the encrypted, authenticated channel between two peers used to negotiate IPsec (Child) SAs. IKEv2 establishes this in IKE_SA_INIT.
- Child SA (IPsec SA)
- The Phase 2 security association that protects actual data traffic. IKEv2 creates the first Child SA inside the IKE_AUTH exchange.
- AutoVPN
- A Junos feature that lets a hub SRX accept any number of spoke SRXs using a single tunnel definition and certificate (PKI) authentication, with the hub st0 in point-to-multipoint mode.
- ADVPN
- Auto-Discovery VPN — extends AutoVPN by having the hub signal spokes to build direct IKEv2 shortcut tunnels between themselves, eliminating hub hairpin for spoke-to-spoke traffic.
- IKEv2
- Internet Key Exchange version 2 (RFC 7296) — four-message exchange that establishes the IKE SA and first Child SA. Adds built-in EAP, cookie-based DOS protection and mandatory DPD. Required for AutoVPN and ADVPN.
- PKI / X.509
- Public Key Infrastructure — uses CA-signed X.509 certificates to authenticate VPN peers. On Junos, enrol with 'request security pki local-certificate enroll'. Required for AutoVPN.
- Juniper Secure Connect
- Juniper's remote-access IPsec VPN solution using IKEv2 with EAP for per-user authentication. The SRX acts as the gateway and assigns client IPs from a local address pool.
- EAP (Extensible Authentication Protocol)
- A flexible authentication framework carried inside IKEv2 that allows username/password or challenge-response authentication — used for per-user identity in remote-access VPN.
- Dead Peer Detection (DPD)
- A keepalive mechanism (built into IKEv2, an extension in IKEv1) that detects when a VPN peer has gone silent and cleans up stale SAs.
📚 Sources
- Juniper Networks — IPsec VPN User Guide (Junos OS) — Route-Based and Policy-Based VPN overview. juniper.net/documentation/us/en/software/junos/vpn-ipsec
- Juniper Networks — Route-Based VPN with IKEv2 — configuration and IKE_SA_INIT / IKE_AUTH exchange detail. juniper.net/documentation/en_US/junos/topics/topic-map/security-vpns-for-ikev2.html
- Juniper Networks — AutoVPN on Hub-And-Spoke Devices — single hub tunnel definition with PKI cert DN matching. juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-autovpn-on-hub-and-spoke-devices.html
- Juniper Networks — Auto Discovery VPNs (ADVPN) — IKEv2 shortcut signalling between spokes. juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-auto-discovery-vpns.html
- Juniper Networks — Create a Remote Access VPN — Juniper Secure Connect (J-Web SRX 23.4). juniper.net/documentation/us/en/software/jweb-srx23.4/jweb-srx/topics/task/j-web-security-ipsec-remote-access-vpn-juniper-secure-connect-creating.html
- Juniper Networks — IPsec VPN Configuration Overview — IKE proposals, policies, gateways and the IPsec VPN hierarchy. juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-ipsec-vpn-configuration-overview.html
What's next?
Got VPN down? Next, go deep on Juniper SRX NAT — understand how source NAT, destination NAT, and static NAT interact with VPN traffic, including nat-traversal across PAT devices.