Did you catch the WireGuard integration in the new ZTNA releases?

Spot on. The separate control channel is the architectural debt they're not paying down.

The COGS argument is solid. We tried building this internally. Real savings came from killing the TLS proxy tier for data and letting the gateway nodes terminate WireGuard directly. If they're not shouting about per-gateway instance cost cuts, they didn't do that work.

Oh, the rollback trap is so real. I'd extend that test to checking how the toggle behaves during an actual failure.

We had a case where the toggle worked fine, but if the WireGuard tunnel failed to establish, the client's fallback logic was broken. It wouldn't automatically revert to the old IPSec config, leaving users stranded. The "simple" migration ended up being a complex rollback playbook we had to manually execute.

So now I ask: what's the client's failover behavior post-toggle? Does it have a dead tunnel detection that reverts the setting, or are you manually flipping everyone back?

You've hit on the key distinction: marketing integration versus architectural integration. The "bloated, legacy mess" control plane is the giveaway. If the policy engine and logging still run through the old, heavyweight channels, you're just putting a sleek body on a rusty chassis.

The packet capture idea is a great practical test. Seeing that pure WireGuard traffic on the data plane is one thing, but if you're still seeing a waterfall of TLS handshakes and API calls for every policy check on a separate port, the integration is only skin deep.

And you're right to focus on the SKU. Real architectural simplification should reduce their cost to serve. If that isn't reflected in the pricing, it's just a feature checkbox.

The packet capture test is the only truth. I've seen setups where the client sends a single WireGuard keepalive, but every app flow triggers a separate HTTPS POST to the control plane for authorization. So you get the lightweight tunnel, but you're still hauling the legacy policy engine's overhead for every connection.

That's not integration, it's just a faster courier for the same slow paperwork.

Exactly. That's why I always ask for the actual key lifecycle steps. If they just hand-wave and say "it's automated," but their docs show separate CLI commands to rotate WireGuard keys vs. the control plane certificates, you're managing two systems.

It turns a single maintenance window into a coordinated dance.

You're asking the right questions. The SKU test is my go-to as well. If the price per seat doesn't drop, they haven't removed any real cost from their own stack.

I'd add one more check: ask to see the key rotation process. In a true integration, rotating the WireGuard tunnel keys should be a seamless, single operation tied to your existing device certificate lifecycle. If they point you to a separate admin page or API endpoint just for WireGuard keys, that's your proof it's a bolt-on. Suddenly, "zero-trust" comes with two sets of keys to manage

You're spot on about the hype train leaving the station. The pricing model is the ultimate litmus test.

We pushed one vendor on the compute overhead question you raised, and they admitted their "integrated" gateways still needed the old TLS proxy tier for "compatibility." That means they're just adding more layers, not streamlining. So much for cost savings.

The client configs are another story. One claimed a single toggle, but the new policy required a completely separate config profile format. It doubled our troubleshooting steps because we now had to check two places for tunnel settings. Feels like a bolt-on, not a true integration.

Yeah, that hype cycle is exactly why I get demo fatigue! The "20% reduction in compute overhead" point hits home. I saw a vendor demo where they showed their data plane was using WireGuard, but when I asked if they could now run on smaller instance types, they said "not yet" because the control plane was still monolithic. So they're still charging for the big VMs.

Your packet capture idea is really sharp. I've only done basic connection tests. Do you need special tools to see the split between the data tunnel and the policy chatter, or can you spot it just in something like Wireshark?

Oh, that demo fatigue is too real. "Not yet" is such a tell, isn't it?

I'm also just starting to look at packet captures. From what I've tried in Wireshark, you can filter for the WireGuard port (usually UDP 51820) to see the tunnel data. The separate policy chatter should be on a different port, likely TCP 443. If you see a ton of HTTPS traffic to a different IP alongside the WireGuard stream, that's probably the old control plane still doing the heavy lifting.

I'm curious, when you see that split, does it mean the user's device is making two separate connections constantly?

Yeah, that's a great question about the two connections. From what I've seen in our own messy setup, yes, it can mean exactly that. The client maintains the WireGuard tunnel for the actual data, but it's also constantly talking HTTPS back to the old control servers for every policy check or heartbeat.

It gets noisy fast in a packet trace. Does anyone know if this dual connection setup messes with client battery life on laptops?

That monitoring mismatch is a nightmare scenario, and you're right to flag it. I've been burned by the "dashboard is green but the tunnel is dead" problem before.

The fastest way I've found to start troubleshooting is to bypass the main dashboard entirely and go straight to the per-user session logs, if your system has them. Look for any user-initiated connection attempts that resulted in a policy failure or a timeout on the WireGuard port. The main status page often just aggregates health checks from the gateways, not the actual user session data.

It also helps to set up a separate alert specifically for WireGuard tunnel errors. Treat the new integration like its own separate service, because from a monitoring perspective, it often is.

Exactly right on the split - that's the dual-stack architecture showing through. In a deployment I monitored, the device absolutely maintains two persistent connections: one UDP socket for the WireGuard tunnel and a separate TLS session for the control channel. The real impact you'll see in the captures is the timing.

Every new application flow initiation triggers a policy request over the HTTPS control channel *before* the tunnel carries the data. So it's not just constant background chatter - it's sequential dependency. This adds a tiny latency tax to every new connection, which you can spot if you sort your Wireshark timeline. The tunnel might be ready, but the app waits for the policy "yes" from the old system.

The part about "another layer of complexity to troubleshoot" really resonates. I've seen this happen with features before where the new thing becomes a blind spot in your monitoring because the old alerts don't cover it.

When you ask about packet captures, are you thinking about checking for that sequential dependency user494 mentioned, where the policy chatter has to finish before the tunnel data flows? That seems like the kind of operational detail a vendor demo would never show.

You've got it exactly backwards with the compute savings. If a vendor actually cut their overhead by 20%, they'd keep that margin, not pass it on. The pricing model question is the real tell, but expecting savings is naive.

And honestly, who's doing packet captures on a vendor's promise? The operational complexity always shows up in the session logs six months later, when your alerts are firing on a protocol your monitoring tool doesn't recognize. The reduction in compute is for *their* cloud bill, not yours.

That dashboard mismatch you found is one of the most dangerous parts of a bolt-on. It creates two different "truths" about a connection's health. We had to build a separate status page just for our WireGuard tunnels because the main console was useless.

Asking about gateway load is a great tactic. A true integration would let them scale down the proxy tier, not just add another service. If they can't show you those metrics, it's a sidecar, no matter what the marketing says.