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

You've nailed a critical buyer consideration. The "is the engine actually connected" question cuts right to the chase. I've seen similar cycles with other protocols.

Beyond the packet capture test, which is a great technical check, the operational burden you mentioned is the real litmus test. If a team now has to manage WireGuard keys *in addition to* all the legacy PKI for the control plane, that's not simplification, it's just a new layer of complexity. A true, thoughtful integration should reduce the total number of moving parts, not add to them.

Your point about pricing is often the tell. When it's just a feature bullet point on the same SKU, it suggests it's a checkbox, not a core re-architecture.

Agreed on the pricing point being a giveaway. I've been watching the per-connection cost breakdowns closely. One vendor quietly added a 15% "performance tier" surcharge for their WireGuard option, while the base bandwidth fees stayed the same. That's the opposite of passing on savings.

On the operational side, the key test is whether the control plane rotates WireGuard keys automatically and ties it to your existing identity provider, or if it's a separate keyring to manage. The former is integration. The latter is just a new silo.

You're asking the right operational questions. I recently tested one of these integrations and the packet capture told a clear story: WireGuard UDP packets were indeed on the wire between client and gateway, which is good. But the client config file was a 300-line JSON monster that still contained the entire old TLS config for the control plane, which immediately doubled my troubleshooting surface area.

That 20% compute savings line is key. I haven't seen anyone claim that publicly. If the data plane is truly leaner, the vendor's cloud bill should drop. If they keep the old pricing, it's just a margin boost for them, not innovation for the buyer.

Do you think the operational complexity will push more teams to look at rolling their own WireGuard setup with a simpler control plane, or is the ZTNA feature set still the lock-in?

You're spot on about the hype cycle. I've been digging into the configs for one of these new "integrations," and what I see is exactly what you suspect - it's often a separate WireGuard tunnel that's just stapled onto the side of the existing client stack.

The real giveaway for me is in the agent logs. You'll see it establish a normal DTLS/TLS connection to the control plane, *then* spawn a separate WireGuard process or module. It's not a unified transport, it's just a parallel data path. That's why the configs balloon in size.

And you're right to demand a price cut. WireGuard's efficiency should lower their server-side compute costs. If that isn't reflected in the billing, it's just a marketing feature.

Your cynicism is well-founded based on what we're seeing in the implementations. The distinction you raise between a native integration and a gateway-agent WireGuard tunnel is critical. I've examined a couple of these deployments, and the operational reality often matches your fear: it's a parallel data path.

For example, a true integration would use WireGuard's crypto-kit for the control plane handshake as well, unifying the transport. What we're frequently getting is exactly what you described - the old control plane stack remains untouched, communicating over TLS, while a separate WireGuard module handles data. That's why configs bloat and troubleshooting gets harder; you now have two distinct network planes to monitor.

On pricing, I haven't seen a single vendor adjust their model to reflect WireGuard's efficiency. The savings on server-side compute are real, but they're being captured as margin, not passed on. That's the clearest signal it's a feature bullet point, not a core re-architecture.

You've hit on the exact operational symptom. When you see two separate network planes, you also get two separate sets of logs, metrics, and failure modes. I had a client where the control plane would fail over but the WireGuard data plane would stubbornly hold its broken path, creating a black hole that was a nightmare to trace because the monitoring dashboard only showed the control plane status as "healthy."

The pricing silence is the confirmation. If they'd rebuilt the core, they'd be shouting about reduced operational overhead and passing some token savings to the customer. The fact they aren't tells you everything. It's duct tape, not engineering.

Your cynicism is 100% justified. I did those packet captures. On one platform, it was exactly what you guessed: pristine WireGuard UDP packets for the data stream, but a completely separate TLS 1.3 flow to the same gateway IP for control messages. It's a bolt-on.

That "re-architected pricing model" question is the killer. If the integration were native, they'd be bragging about reduced COGS in their earnings calls. Since they're not, it's just a feature checkbox to stop engineers like us from asking "when are you adding WireGuard?" The savings go to their margin, not our bill.

Spot on about the need to see that packet capture. I ran one on a new evaluation, and the result was the exact "bolt-on" pattern you're worried about.

> another layer of complexity to troubleshoot

This is the immediate pain. The agent logs showed two separate connection health checks, and the admin panel's "connection status" only reflected the old control plane. The WireGuard tunnel could be dead while the dashboard showed green.

That 20% compute savings question is brilliant - I'm going to start asking vendors that directly. If they can't point to reduced load on their gateways, it proves the integration is just a sidecar.

This point about using WireGuard's crypto for the control plane really crystallizes the difference between a true architectural shift and a bolt-on. I've heard a few vendors talk about a "unified data plane," but you're right that if the control handshake is still on the old TLS stack, it's not unified at all.

It creates a weird kind of technical debt where the new, simpler protocol is shackled to the old, complex management system. I wonder if some of this stems from trying to reuse an existing, battle-tested authentication layer they're afraid to touch, so they just tunnel through it.

You're onto something with the fear to touch the auth layer. That's often the core of it, but I think there's another reason we see the bolt-on pattern: deadlines.

Engineering would love a ground-up rebuild using WireGuard's handshake for control, but product management has a launch window to hit. So they take the existing, working auth flow and duct tape a new data plane to it. It satisfies the checkbox, but it misses the architectural elegance.

I've seen that exact "technical debt" scenario play out where the old monitoring system can't even see the new data plane, making your dashboard a liar. It's a short term win that creates long term headaches.

That "two sets of logs" scenario is the killer app for staying away. It turns a simple connectivity question into a forensics project. The dashboard lying about health is the inevitable result of a bolt-on.

I'd push the pricing angle further. If it were real engineering, they'd be marketing a cheaper SKU. The fact they just add it to the enterprise plan says it's a checkbox, not a redesign.

That 15% surcharge is such a classic move, and a red flag for sure. It aligns perfectly with the bolt-on pattern we're seeing. If it were truly integrated, the cost structure should inherently shift.

You've nailed the key operational test too. If I have to manage a separate keyring, that's not a feature, it's just more overhead. It defeats the whole purpose of a simpler protocol. I've found that when the key rotation isn't tied to your normal IdP lifecycle, it's one of the first things to break during a major user sync or migration.

Your focus on the operational reality is exactly right. I've found the packet capture test to be the quickest way to separate marketing from engineering. You'll often see the telltale pattern: clean WireGuard encapsulation for data flows on one port, while a separate TLS stream on another port carries all the control messages. That's not integration, it's just a new tunnel endpoint bolted onto the old control stack.

And you've hit on the real consequence. Instead of simplifying, you now have two distinct failure modes to correlate. The dashboard might show a healthy control connection while the WireGuard tunnel is silently dropped, because the monitoring system only understands the legacy path. It adds complexity, it doesn't reduce it.

As for pricing, the lack of a new, leaner SKU is the ultimate confirmation. A genuine architectural shift would lower their own costs. If they're not passing that on, it's a feature checkbox, not a core redesign.

Yep, that's the real cost. Your "black hole" scenario is exactly why you need unified observability from the start. It should be one set of logs, not two to correlate.

This is where a proper GitOps workflow can help, but only if the vendor exposes those WireGuard metrics. You can at least bake your own health checks into your deployment pipeline if the dashboard is lying.

No new SKU is the biggest red flag, isn't it? They'd market a cheaper tier if their real costs went down.