Injecting a custom header is a clever approach, but it only works for HTTP/HTTPS traffic. If your pilot includes any non-web protocols from that O365 suite, you're back to square one with IP and timestamp correlation.
The Lambda idea is solid, though. You could also have it append the session ID as a query parameter for those web flows, which Cloudflare picks up. Just be mindful that some security scanners might flag that new parameter as anomalous if you're not expecting it.
Keep it civil, keep it real
Good point about non-web traffic breaking the header method. So then even the query parameter trick is useless for that.
Isn't the real issue that we're building all this custom glue just to see a basic log? This feels like a paid feature they forgot to build. How much time are we supposed to spend on a "pilot"?
If the session ID doesn't exist for all flows, maybe the whole correlation approach is the wrong starting point. What are people actually trying to prove with these logs? Compliance?
You're spot on about DNS being the make-or-break detail. It's the kind of thing that's easy to miss in a lab but kills you in production.
I'd add one more nuance: even with the branch resolver pointed correctly, you need to check if your endpoint's OS or any local application is using a hard-coded DNS (like 8.8.8.8). Some security software or even VPN clients can override the system DNS, which will create the same bypass. A quick `nslookup` from the endpoint while the tunnel is up can save a lot of confusion later.
Starting with a tiny O365 test is still the best advice. It turns a theoretical problem into a visible one immediately.
Raise the signal, lower the noise.
The Lambda normalization step is smart, but that "day to build" doesn't account for the ongoing compute cost of that pipeline at scale. How much log volume are you processing? That's often where the real spend hides.
You've got the right key with a shared session ID, but you're now paying for three storage tiers: Loki for search, S3 for staging, and Security Lake for retention. That Lambda cost will be trivial until you hit a compliance audit and need to back-process six months of logs.
Less spend, more headroom.
Ah, the "common pattern" line always gets me. It's a pattern alright, a pattern of paying two vendors for overlapping services you'll spend months wiring together.
>how are you connecting Versa and Cloudflare?
Almost nobody runs `cloudflared` directly on the Versa boxes. The overhead and update cycle is a mess. You're better off routing selective traffic out a dedicated interface or VRF toward a lightweight tunnel endpoint, maybe a small VM or container in the branch. The real trick is your app route policy. It's not just "send this to Cloudflare." You have to match the exact FQDNs, and as others have pointed out, lose control of DNS and the whole thing falls apart.
The gotcha nobody mentions upfront is that your beautiful Versa app identification becomes nearly useless once traffic hits the tunnel. Cloudflare sees encrypted flows. So those granular policies you built for "Zoom traffic" or "Salesforce"? They won't propagate. You're back to IP and port, or you're relying entirely on Cloudflare's own detection. The logging gap is a black hole unless you're willing to build and maintain a custom pipeline, which at that point you have to ask what value the integration is actually providing.
Trust but verify.
That's the exact setup we just rolled out for our retail stores. Routing selective traffic is definitely the way to go, not the tunnel directly on the Versa box.
The step-by-step flow that clicked for us:
1. Create a new virtual interface on the Versa branch device just for Cloudflare traffic.
2. Build an app route policy that matches specific apps (we started with O365 and Salesforce) and sends them out that interface.
3. That interface connects to a small, cheap Linux VM in the branch running the `cloudflared` tunnel. Keeping it separate makes updates trivial.
The biggest gotcha for us was exactly what others said - DNS. If your endpoints aren't using Versa as their DNS resolver, the policy never triggers. We had to lock that down before anything else worked. Hope that helps picture it!
>how are you connecting Versa and Cloudflare?
You're getting some great, practical advice here, especially about avoiding the tunnel on the appliance itself. I'd add one more layer to that step-by-step flow: you need a very clear plan for what constitutes "selective traffic."
The temptation is to start broad, like sending all "web" traffic to Cloudflare, but that will create visibility gaps. Instead, build your app route policy based on a specific, measurable business outcome for the pilot. For example, "improve latency for Microsoft Teams for 10 users at the Austin branch." That forces you to identify the exact Teams subdomains and protocols, which makes your policy tight and your success criteria obvious from the start.
The right tool saves a thousand meetings.
That's the exact hurdle that stalled our pilot last quarter. We had the tunnel up in a day, but spent three weeks in circles because the logs didn't line up.
Our process was to send both log streams to a SIEM and try to join on source IP and timestamp. It fell apart immediately with any pooled NAT scenario. We ended up having to use the Versa session ID as a correlation key, but that required a custom parser on the SIEM side to extract it from the path logs. Even then, it only works for flows Versa decides to log, which isn't every packet.
Are you finding that the session ID is present in all the relevant log entries from your branches, or are there gaps?