ZTNA Connector — Tunnel remains Inactive despite active Control Plane (NFR tenant)

M.Salah734756 — Tue, 18 Aug 2026 10:20:10 GMT

Hello Evryone,

I'm tring to deploy a ztna connector on my home lab to prepare different use case for customer demo and i still have the same issue.

Environment:

Tenant type: NFR
ZTNA Connector deployed on-prem via KVM (Proxmox VE), two-arm deployment
Connector image: 200v-6.2.9-ztna-connector-b3-kvm.qcow2 (and try with 6.2.5 same issue)
Port 1 (WAN/PublicWAN): static IP, valid gateway, DNS reachable
Port 2 (LAN): static IP on isolated segment, reaching target app successfully via local NAT/firewall (NGFW in front)

Steps already taken:

Onboarded ZTNA Connector via Strata Cloud Manager (Onboard Connectivity to Private Apps → ZTNA Connector)
Created Connector Group, Connector, and FQDN Target (private app) successfully
Deployed connector VM on Proxmox/KVM — required --cpu kvm64 (not host) and a serial console (serial0) to boot successfully; confirmed via LIVEcommunity forum post referencing this exact Proxmox setup
Redeployed the connector fully from scratch (new Key/Secret, new Connector object in SCM) to rule out stale state — same result
Verified via ion toolkit: dump interface config 1 shows correct static IP/gateway/DNS
nslookup locator.cgnx.net from the connector times out — no DNS response, despite DNS servers being reachable and correctly configured
Verified no firewall blocking on local network path (NGFW + edge firewall logs show no drops for this traffic after rule adjustments)
Home ISP router configured in DMZ mode pointing to firewall WAN IP to rule out double-NAT interference

Observed status in Strata Cloud Manager:

Control Plane: Active
Tunnel: consistently Inactive
Config Status: "Tunnel Config Done"
Diagnostic tools in SCM (Dump Overview, Packet Captures under Connector → Actions → Diagnostics) spin indefinitely and never load, across multiple connector redeployments

Question: Is there a known limitation for ZTNA Connector tunnel establishment or SCM diagnostic tooling on NFR tenants? Or is there a specific requirement (e.g., licensing scope, region availability) we may be missing for tunnel establishment to complete?

Thank's for your help

Re: ZTNA Connector — Tunnel remains Inactive despite active Control Plane (NFR tenant)

M.Salah734756 — Wed, 19 Aug 2026 13:09:07 GMT

Update: simplified the architecture as much as possible to isolate the variable.

Removed the NGFW that was previously inline - turned out it was entirely outside the connector's actual network path (connector and target app were direct L2 neighbors on the isolated segment), so it was never a relevant variable in the first place.

Current setup is now minimal:

Client -> Edge firewall (OPNsense) -> ZTNA Connector (two-arm: Port1 WAN on the app VLAN, Port2 LAN on an isolated segment with the test app) -> Prisma Access

Since the connector's config UI requires a gateway/DNS on Port2 (can't leave them blank even in a fully isolated design), the hypervisor (Proxmox/KVM host) now acts as the gateway for that isolated segment: static route + IP forwarding + source NAT toward the connector's WAN-side network, made persistent (iptables-persistent). Confirmed via NAT counters that this is actively translating traffic (counter climbing steadily, currently in the hundreds of packets).

Also fixed, one layer at a time, each independently confirmed via the firewall's state table:
- DNS resolution on both connector ports - was silently failing due to NAT reflection being disabled on the edge firewall (destination-NAT reflection was needed since the DNS redirect target is the firewall's own loopback). Enabled reflection for destination NAT + 1:1 + automatic outbound NAT for reflection - fixed.
- A leftover port-forward rule I'd created earlier (meant to allow ESP passthrough) was actually intercepting the connector's outbound UDP 4500 traffic on the LAN-facing interface and redirecting it to a stale/dead IP - removed entirely.

Current status:
- DNS, NAT, and routing for the isolated segment: all confirmed working via state table entries showing successful translated sessions
- Control Plane (HTTPS/443): connects and authenticates, but drops intermittently with zero local action on my end (no config changes, no reboots at the time it happens) - increasingly looks like a backend/session issue rather than network
- Tunnel (IKE/NAT-T, UDP 500/4500): still zero negotiation attempts ever observed in the firewall state table, across dozens of checks with precise source-IP filtering (ruled out false positives from matching substrings like ":500" against ephemeral ports), despite every other layer confirmed healthy
- One remaining anomaly I can't fully explain: a handful of TCP/443 sessions from the connector's LAN-side IP occasionally show up un-NAT'd on the management VLAN interface instead of going out via the isolated segment's gateway as expected - low volume, doesn't affect the overall conclusion, but noting it in case it's a symptom of something relevant on the connector side (e.g. multiple simultaneous egress attempts).

This is a Lab/NFR tenant. Has anyone seen this specific pattern (Control Plane authenticated but unstable, zero tunnel negotiation attempts ever) on an NFR/lab tenant? Trying to determine whether this is a known limitation, a licensing/tenant-type constraint, or something worth escalating differently.

Happy to share full state-table outputs or connector config if useful.

topic Re: ZTNA Connector — Tunnel remains Inactive despite active Control Plane (NFR tenant) in Prisma Access Discussions

ZTNA Connector — Tunnel remains Inactive despite active Control Plane (NFR tenant)

Re: ZTNA Connector — Tunnel remains Inactive despite active Control Plane (NFR tenant)