Srx autovpn full tunnel

SRX AutoVPN Full-Tunnel Backhaul

Overview

AutoVPN lets one hub gateway accept IPsec connections from any number of spokes with no per-spoke hub configuration. Full-tunnel backhaul is the design choice to send everything a spoke does not own locally up the tunnel to the hub, instead of the conventional split tunnel (only hub-LAN traffic in the tunnel, internet broken out locally, no spoke-to-spoke).

Core principle: if traffic is not local to a spoke, it goes to the hub. The hub then source-NATs internet-bound traffic out its WAN and hairpins spoke-to-spoke traffic back out the tunnel un-NAT'd. The motivation is centralized egress — all internet traffic can be inspected, filtered, and logged at one point (UTM/IDP on the hub).

The full-tunnel changes are confined to four things: the traffic selector scope, spoke routing, hub egress routing/NAT, and two added hub security policies. Everything else — IKE/IPsec parameters and the AutoVPN dynamic-gateway mechanics — is standard AutoVPN.

Attribution. The reference topology, full-tunnel backhaul approach, and the validated set-format configuration this skill summarizes come from Jason Anderson's lab srx-autovpn-backhaul-public (https://github.com/anderson-jason573/srx-autovpn-backhaul-public), built and validated on four vSRX (Junos OS 23.2R2.21) plus a Cisco IOS-XE WAN transit router. See references/source-design-summary.md.

Runtime intake

Before starting the workflow, inspect the request, supplied artifacts, and available approved read-only evidence. If unresolved facts could materially change safety, scope, correctness, confidence, or the requested output, read references/runtime-intake.md.

For each unresolved material fact whose catalog condition is true, invoke Claude AskUserQuestion or Codex request_user_input before continuing or issuing an open-ended request. Ask at most three single-select catalog questions per round. After each response, ask another round whenever any unresolved material catalog condition remains true; continue only when none remain. Do not repeat answered questions or show the full catalog. Without a native tool, present each selected catalog question with its 2-3 labeled choices and a free-text Other path in concise plain text; do not substitute a generic checklist.

Never request secrets or unredacted customer data. Treat intake answers as task context, not approval for a live change; obtain separate explicit approval before configuration, commit, upgrade, reboot, delete, or failover actions.

Scope and routing

Use this design when all spoke internet and inter-spoke traffic must traverse a centralized hub. Use srx-ipsec-hub-spoke for a small explicit estate, srx-advpn when direct spoke shortcuts are required, and another design when spokes need local breakout.

Topology Model

                CSR1 / upstream router  (loopback = "the internet")
        WAN /30   WAN /30    WAN /30    WAN /30
           │         │          │          │
        srx01      srx02      srx03      srx04
         HUB       spoke      spoke      spoke
     192.168.1/24  .2/24      .3/24      .4/24   (LANs)

   AutoVPN: all spokes terminate on the hub's single st0.0.

Element	Role
Hub WAN (untrust)	IKE/IPsec endpoint + internet egress; PAT target
Hub LAN (trust)	Local hub subnet
Hub st0.0 (VPN)	One bound tunnel interface for all spokes
Spoke WAN (untrust)	IKE/IPsec endpoint to the hub WAN IP
Spoke st0.0 (VPN)	Single tunnel to the hub
Underlay	Any IP transport that lets each spoke WAN reach the hub WAN

st0 units are unnumbered, point-to-point (no multipoint keyword) — required for traffic selectors. Management (fxp0) is out-of-band and never carries tunnel traffic.

AutoVPN Mechanics

• IKEv2 / IPsec. Phase 1: PSK, DH group 14, SHA-256, AES-256-CBC, v2-only. Phase 2: ESP, AES-256-GCM, PFS group 14, 3600 s. Clamp tcp-mss ipsec-vpn 1350 to absorb ESP overhead.
• Dynamic hub gateway. dynamic hostname <domain> + dynamic ike-user-type group-ike-id makes the hub accept any spoke presenting an IKE ID under *.<domain>. Each spoke sets local-identity hostname srxNN.<domain> and pins the hub with remote-identity hostname srx01.<domain>.
• Single bound tunnel. Every spoke terminates on the hub's one st0.0; there is no per-spoke st0 unit on the hub.
• Auto Route Insertion (ARI). When a spoke SA comes up, the hub automatically installs a route to that spoke's LAN /24 via st0.0 (protocol ARI-TS). The hub needs no static routes to spoke LANs.
• Traffic selectors define which source/destination prefixes each end carries — the lever full tunnel pulls.

Version constraint (field-verified): ike-user-type + IKEv2 + PSK does not commit on current Junos. On vSRX3 24.4R1.9 and 25.4R1.12, pairing dynamic ike-user-type (group-ike-id or shared-ike-id) with authentication-method pre-shared-keys fails commit with: When dynamic ike-user-type is configured, IKEv2 with authentication-method pre-shared-key is not allowed. A zero-touch PSK AutoVPN hub cannot be built on these images. Pick the path before writing config:

• PSK → drop ike-user-type entirely and configure per-spoke IKEv2 gateways on the hub, each pinned by a unique remote-identity hostname <spokeN>.<domain>. Functionally the same full-tunnel hub-and-spoke (field-verified with 6 spokes), but zero-touch is lost: adding a spoke means adding a hub gateway/VPN/st0 unit.
• Zero-touch group-ike-id → use certificate (PKI) authentication. See the srx-advpn skill's PKI-enrollment section for the workflow.

The original reference lab (Junos 23.2R2) committed group-ike-id + PSK; treat that combination as legacy-image-only.

Auth: lab PSK vs. production PKI. A single shared PSK keeps the focus on mechanics but is not production practice. In production prefer certificate-based (PKI) auth with per-device identity, or at minimum strong, unique PSKs in a secrets manager with rotation.

Traffic Selectors — the core

Full tunnel is fundamentally a traffic-selector change: the spoke must request the whole internet, and the hub must accept any destination.

Selector	Split tunnel	Full-tunnel backhaul
Spoke local-ip	192.168.x.0/24 (its LAN)	same
Spoke remote-ip	192.168.1.0/24 (hub LAN only)	the full IPv4 space — as two /1 halves, see below
Hub local-ip	192.168.1.0/24 (hub LAN)	0.0.0.0/0
Hub remote-ip	192.168.0.0/16 (spoke summary)	same

Commit blocker (field-verified on 24.4R1.9 / 25.4R1.12): the literal spoke remote-ip 0.0.0.0/0 is rejected when the gateway is pinned by a static address — the normal spoke case: Remote-ip 0.0.0.0/0 in traffic-selector is not supported when address is configured under ike gateway. Split the default into two halves that avoid the literal 0.0.0.0/0 but cover the same space:

set security ipsec vpn SPOKE-VPN traffic-selector TS-LO local-ip 192.168.x.0/24 remote-ip 0.0.0.0/1
set security ipsec vpn SPOKE-VPN traffic-selector TS-HI local-ip 192.168.x.0/24 remote-ip 128.0.0.0/1

Both halves commit cleanly and bring up two child SAs per spoke.

Two facts that surprise people:

1. Hub local-ip 0.0.0.0/0 does NOT create a default route via st0.0. The per-spoke /24 the hub installs comes from the other selector axis: hub remote-ip 192.168.0.0/16 narrowed by the spoke's local-ip 192.168.x.0/24 = the spoke's specific /24, and ARI keys off that narrowed remote selector, so the hub installs clean per-spoke /24 routes. The broad axis (hub local-ip 0.0.0.0/0 ∩ spoke remote-ip wildcard) never becomes a hub route.
2. Spoke-to-spoke needs no extra selector config. With hub local-ip 0.0.0.0/0, the inbound SA from spoke A already accepts spoke B's subnet as a destination, and the outbound SA to spoke B already accepts spoke A as source.

Hub remote-ip: specific supernet vs. 0.0.0.0/0 wildcard

This is a different axis from the 0.0.0.0/0 used on the spoke remote-ip / hub local-ip above — do not conflate them. The hub remote-ip controls which spoke prefixes the hub will accept (and, via ARI, which routes appear).

	Supernet (192.168.0.0/16)	Wildcard (0.0.0.0/0)
Use when	Spoke LANs summarize cleanly	Spoke LANs discontiguous / unsummarizable
Hub-side guardrail	Yes — IKE rejects prefixes outside the summary	None — hub trusts every spoke
Zero-touch hub	Mostly (new out-of-summary LAN forces a widen)	Fully
Blast radius if a spoke is rogue	Contained	Large — a spoke could advertise the hub LAN or another site's prefix; ARI would install it (route hijack). (ARI never installs a 0.0.0.0/0 selector, so a rogue default is not the risk — rogue specifics are.)

Default to the supernet whenever addressing permits; it keeps the guardrail. Use the wildcard only when there is genuinely no summarizable scheme, and push the guardrail to per-spoke security policy/filtering instead.

Two caveats regardless of choice:

• Spokes must propose their specific /24, not 0.0.0.0/0 — else the negotiated selector stays 0.0.0.0/0 and ARI has no specific prefix to install.
• Overlapping spoke subnets are not solved by selectors — that is a NAT problem (static/twice-NAT at the colliding spoke), not a VPN problem.

Routing Changes

Spoke

	Split tunnel	Full-tunnel backhaul
Tunnel route	192.168.1.0/24 → st0.0	0.0.0.0/0 → st0.0 (default into tunnel)
Hub WAN host route	HUB_WAN/32 → <underlay nh>	same — and now CRITICAL
WAN /30 routes	via underlay	same

Anti-recursion is the #1 gotcha of full tunnel. The spoke default now points into st0.0, but the ESP packets that carry the tunnel are destined to the hub's WAN IP. If that traffic also followed the default into the tunnel you get infinite recursion and an instant black-hole. Keep the host route HUB_WAN/32 → <underlay next-hop> (and the connected WAN /30) more-specific than the new default.

Hub

	Split tunnel	Full-tunnel backhaul
WAN /30 routes	via underlay	same
Spoke LAN routes	ARI 192.168.x.0/24 → st0.0	same (ARI)
Default route	none	add 0.0.0.0/0 → <WAN next-hop> (egress for de-encapsulated internet traffic)

Caveat — competing management default (ECMP trap). Many vSRX images carry a management default 0.0.0.0/0 → <mgmt-gw> via fxp0 in inet.0. Adding a second 0.0.0.0/0 does not override it — Junos installs both next-hops as ECMP, so half the traffic wrongly egresses fxp0 and NAT / the untrust policy never applies. Removing the management default risks cutting OOB access.

• Production fix: put fxp0 in a dedicated management routing-instance so inet.0's default can legitimately point into the WAN/tunnel.
• Lab shortcut: route the specific internet destination instead (<sim-internet>/32 → st0.0 on spoke, <sim-internet>/32 → <WAN nh> on hub), plus 192.168.0.0/16 → st0.0 on each spoke for hub-LAN and spoke-to-spoke. Being more-specific than the management default, these exercise the full data path without disturbing management.

Hub NAT and Security Policies

Source NAT (internet egress only)

PAT spoke private sources to the hub's WAN egress IP so the upstream has an address to return to. Scope the rule-set from zone VPN to zone untrust so it matches only internet egress — spoke-to-spoke (VPN → VPN) and spoke-to-hub-LAN (VPN → trust) never match and stay un-NAT'd, preserving real private IPs between sites.

set security nat source rule-set VPN-BACKHAUL from zone VPN
set security nat source rule-set VPN-BACKHAUL to zone untrust
set security nat source rule-set VPN-BACKHAUL rule SNAT-INTERNET match source-address 192.168.0.0/16
set security nat source rule-set VPN-BACKHAUL rule SNAT-INTERNET match destination-address 0.0.0.0/0
set security nat source rule-set VPN-BACKHAUL rule SNAT-INTERNET then source-nat interface

Hub-LAN hosts to the internet are trust → untrust and are not covered. Add a parallel trust → untrust source-NAT rule if the hub should also be the NAT egress for its own LAN.

Security policies

Policy	Split tunnel	Full-tunnel backhaul
trust → untrust	permit	same
trust → VPN	permit	same
VPN → trust	permit	same
VPN → untrust	—	add permit (spoke internet egress)
VPN → VPN	—	add permit (spoke-to-spoke hairpin)

Return traffic for both NAT'd internet and inter-spoke flows is handled by the stateful session table — no reverse policy needed. On the spoke, all LAN egress now exits via zone VPN (st0.0), so the spoke's trust → VPN policy must permit the full backhaul scope (destination-address any or the intended backhauled prefixes) — a split-tunnel policy scoped to the hub LAN would silently drop internet-bound traffic at the spoke. The spoke's trust → untrust policy becomes dead (no local breakout) but is harmless to leave.

Config Skeleton (hub, set format)

PSK is a placeholder substituted at deploy time from a git-ignored secrets file — never commit it.

# --- Tunnel interface (P2P, unnumbered) ---
set interfaces st0 unit 0 family inet

# --- IKE Phase 1 ---
set security ike proposal AUTOVPN-IKE-PROP authentication-method pre-shared-keys
set security ike proposal AUTOVPN-IKE-PROP dh-group group14
set security ike proposal AUTOVPN-IKE-PROP authentication-algorithm sha-256
set security ike proposal AUTOVPN-IKE-PROP encryption-algorithm aes-256-cbc
set security ike proposal AUTOVPN-IKE-PROP lifetime-seconds 86400
set security ike policy AUTOVPN-IKE-POL proposals AUTOVPN-IKE-PROP
set security ike policy AUTOVPN-IKE-POL pre-shared-key ascii-text "$AUTOVPN_PSK"
# Dynamic gateway — accepts any spoke whose IKE ID is *.homelab.local
# NOTE: on Junos 24.4R1+/25.4R1 the 'dynamic ike-user-type' line below + PSK
# will NOT commit — see the version-constraint callout (per-spoke gateways for
# PSK, or certificate auth for zero-touch group-ike-id).
set security ike gateway AUTOVPN-HUB-GW ike-policy AUTOVPN-IKE-POL
set security ike gateway AUTOVPN-HUB-GW dynamic hostname homelab.local
set security ike gateway AUTOVPN-HUB-GW dynamic ike-user-type group-ike-id
set security ike gateway AUTOVPN-HUB-GW dynamic reject-duplicate-connection
set security ike gateway AUTOVPN-HUB-GW local-identity hostname srx01.homelab.local
set security ike gateway AUTOVPN-HUB-GW external-interface ge-0/0/0.0
set security ike gateway AUTOVPN-HUB-GW version v2-only

# --- IPsec Phase 2 ---
set security ipsec proposal AUTOVPN-IPSEC-PROP protocol esp
set security ipsec proposal AUTOVPN-IPSEC-PROP encryption-algorithm aes-256-gcm
set security ipsec proposal AUTOVPN-IPSEC-PROP lifetime-seconds 3600
set security ipsec policy AUTOVPN-IPSEC-POL perfect-forward-secrecy keys group14
set security ipsec policy AUTOVPN-IPSEC-POL proposals AUTOVPN-IPSEC-PROP
set security ipsec vpn AUTOVPN-HUB bind-interface st0.0
set security ipsec vpn AUTOVPN-HUB ike gateway AUTOVPN-HUB-GW
set security ipsec vpn AUTOVPN-HUB ike ipsec-policy AUTOVPN-IPSEC-POL
# Full-tunnel selector: hub local-ip 0.0.0.0/0 accepts ANY destination from spokes
set security ipsec vpn AUTOVPN-HUB traffic-selector TS-ALL local-ip 0.0.0.0/0
set security ipsec vpn AUTOVPN-HUB traffic-selector TS-ALL remote-ip 192.168.0.0/16
set security flow tcp-mss ipsec-vpn mss 1350

# --- Zones (st0.0 in its own VPN zone) ---
set security zones security-zone untrust host-inbound-traffic system-services ike
set security zones security-zone untrust interfaces ge-0/0/0.0
set security zones security-zone trust interfaces ge-0/0/1.0
set security zones security-zone VPN host-inbound-traffic system-services ping
set security zones security-zone VPN interfaces st0.0

# --- Routing: ARI handles spoke LANs; add the egress default (see ECMP caveat) ---
set routing-options static route 0.0.0.0/0 next-hop 10.0.0.1

Spoke differs only in: local-identity hostname srxNN.homelab.local, remote-identity hostname srx01.homelab.local, gateway address <HUB_WAN>, the two-half selector local-ip 192.168.x.0/24 + remote-ip 0.0.0.0/1 / 128.0.0.0/1 (the literal 0.0.0.0/0 fails commit with a static gateway address — see Traffic Selectors), a default route 0.0.0.0/0 → st0.0, and the anti-recursion host route HUB_WAN/32 → <underlay next-hop>.

Two spoke prerequisites that are easy to miss (both field-verified):

• The spoke's untrust zone needs host-inbound-traffic system-services ike even though the spoke initiates — without it the NAT-T UDP-4500 return is dropped at host-inbound: IKE_SA_INIT (500) round-trips, then IKE_AUTH retransmits forever while the reply dies at the spoke's WAN zone.
• The spoke's trust → VPN policy must permit destination-address any (see Security policies above).

See references/source-design-summary.md for full per-device detail.

Verification

show security ike security-associations            # one Phase 1 SA per spoke, UP
show security ipsec security-associations           # one Phase 2 SA per spoke, bound st0.0
show route 192.168.0.0/16                            # clean per-spoke /24s, protocol ARI-TS via st0.0
show security nat source rule all                    # SNAT-INTERNET hit count incrementing
show security flow session                           # spoke-src -> internet, xlated to hub WAN IP
show security nat source summary
show system core-dumps                               # must stay zero (data-plane stability)

Internet backhaul: from a spoke, ping <sim-internet> source <spoke-LAN-gw> — hub session shows the source translated to the hub WAN IP. Spoke-to-spoke: ping <other-spoke-LAN> source <spoke-LAN-gw> — hub session shows spokeA → spokeB entering and leaving on st0.0, zone VPN → VPN, no NAT.

Troubleshooting Matrix

Stage	Symptom	Common causes
Commit	ike-user-type ... pre-shared-key is not allowed / Remote-ip 0.0.0.0/0 ... not supported	24.4R1+ constraints — per-spoke gateways (PSK) or certs (group-ike-id); split the spoke selector into 0.0.0.0/1 + 128.0.0.0/1
Underlay	Peers can't reach each other	Transport routing/filtering; verify ping between WAN IPs
Phase 1 (IKE)	No IKE SA / stuck	PSK mismatch, proposal/DH mismatch, wrong IKE identity (group-ike-id domain), IKEv1-vs-v2 mismatch
NAT-T (4500)	Hub shows tunnel UP, spoke retransmits IKE_AUTH forever	Double NAT (carrier PAT + hub-behind-static-NAT) drops the fragmented 4500 AUTH return — collapse to a single NAT hop (when the hub sits behind a 1:1 static NAT, don't also PAT the spokes' underlay)
NAT-T (4500)	Same symptom, single NAT hop; packets reach the spoke WAN but never iked	Spoke untrust zone missing host-inbound-traffic system-services ike — the 4500 return dies at host-inbound
Phase 2 (IPsec)	IKE up, no IPsec SA	IPsec proposal/PFS mismatch, traffic-selector mismatch
ARI routes	No per-spoke /24 on hub	Spoke proposed 0.0.0.0/0 instead of its /24; hub remote-ip excludes the spoke LAN
Data plane	Tunnel up, no traffic	Missing spoke default into st0, st0 in wrong zone, VPN→untrust/VPN→VPN policy missing
Internet egress	Spoke can't reach internet, NAT zero hits	Management-default ECMP stealing traffic out fxp0; NAT rule-set not VPN→untrust
Recursion	Tunnel flaps / black-hole	Missing anti-recursion host route HUB_WAN/32
Fragmentation	Large flows fail, small ones work	Tunnel MTU/MSS — keep/lower tcp-mss ipsec-vpn

IKE tracing when an SA won't establish:

set security ike traceoptions file ike-trace
set security ike traceoptions flag ike
set security ike traceoptions level 15

Read with show log ike-trace; force renegotiation with clear security ike security-associations / clear security ipsec security-associations. (iked-based platforms take a numeric trace level; word levels like level detail fail commit on Junos 24.4R1 — live-verified.) Live daemon log is show log iked on modern (iked) platforms, show log kmd on older (kmd).

Caveats and Tradeoffs

1. Anti-recursion route — the single most common break (see Routing Changes).
2. No local breakout — all spoke internet traffic concentrates on the hub's WAN, CPU (encrypt/decrypt), and NAT table. This is the central capacity-planning decision; the upside is centralized inspection/logging.
3. MTU / MSS — backhauling large flows over ESP plus NAT makes fragmentation likely; keep the MSS clamp, lower it if PMTU issues appear.
4. Scale — per platform, AutoVPN with traffic selectors scales to thousands of tunnels; approaching limits, go dual-hub to remove the single point of failure and distribute load.
5. 0.0.0.0/0 selector — use with a caveat. Full tunnel needs a wildcard to pull all destinations up the tunnel (there is no supernet for "the entire internet"). Juniper's traffic-selector docs caution that a remote-ip of 0.0.0.0/0 for site-to-site selectors is not formally supported, and on 24.4R1+/25.4R1 the literal wildcard is a hard commit error when the gateway has a static address — use the 0.0.0.0/1 + 128.0.0.0/1 split (see Traffic Selectors). Also, ARI does not install a route for a 0.0.0.0/0 selector. This design does not rely on ARI for that direction: the spoke reaches everything via a static 0.0.0.0/0 → st0.0 default route, and ARI installs only the hub-side per-spoke /24 routes (keyed on the spoke's specific local-ip, not the wildcard). Validate on your target release/platform and confirm with JTAC for production.

Choose This vs. Static Hub-Spoke

	AutoVPN full-tunnel (this skill)	Static P2P hub-spoke (srx-ipsec-hub-spoke)
Hub gateways	One dynamic group-ike-id gateway	One static gateway per spoke (by IP)
Hub tunnel interfaces	Single shared st0.0	One st0 unit per spoke
Hub → spoke-LAN routes	Auto Route Insertion (ARI-TS)	Static, one per spoke
Add a new spoke	Zero hub change	Hub change: +gateway +VPN +st0 +route
Best for	Many or churning sites	A few small, stable, explicit sites

Backhaul behavior, NAT, anti-recursion, and the management-default caveat are identical between the two. Pick AutoVPN when spoke count grows or churns; pick static when you want every tunnel spelled out in config.

If the problem is spoke-to-spoke hairpin latency rather than hub config churn, compare srx-advpn (see its three-way ADVPN vs AutoVPN vs Static table).

Verification Checklist

• st0 units are point-to-point (no multipoint) — required for selectors
• Auth path matches the image: certs for group-ike-id, or per-spoke gateways for PSK (24.4R1+ rejects ike-user-type + IKEv2 + PSK)
• Hub local-ip 0.0.0.0/0; spoke remote-ip as 0.0.0.0/1 + 128.0.0.0/1; hub remote-ip is the spoke summary (or wildcard with policy guardrails)
• Hub shows one IKE SA per spoke (and two child SAs per spoke with the split selector) plus clean per-spoke ARI-TS /24 routes
• Spoke has 0.0.0.0/0 → st0.0 AND the anti-recursion HUB_WAN/32 host route
• Spoke untrust zone permits system-services ike; spoke trust → VPN policy permits destination any
• Hub egress default does not ECMP with a management default (management in its own routing-instance, or use specific routes)
• Source-NAT rule-set is VPN → untrust only; VPN→untrust and VPN→VPN policies permit
• show system core-dumps is zero

Source Notes

This original playbook was inspired by Jason Anderson's attributed srx-autovpn-backhaul-public lab and checked against Juniper Junos IPsec/AutoVPN documentation. The upstream lab has no explicit license and is not included or relicensed here. See references/source-index.md and the independently written references/source-design-summary.md.