Anyone using Versa and Cloudflare together? Integration tips

A common approach is to establish IPSec tunnels from your Versa CPEs directly to the nearest Cloudflare Magic WAN ingress points, treating Cloudflare as a security hub. You're not typically running the Tunnel agent on the Versa box itself; you're defining the tunnel as a secured transport path within Versa Director.

The main integration point is in the service definitions and route policies. You'll create a custom application group in Versa for the traffic you want to force through Cloudflare's security stack (like all SaaS-destined or internet-bound flows), then apply a next-hop policy that points that traffic to the IPSec tunnel interface. The gotcha is in the logging: Versa will see the tunnel as up/down and bytes transferred, but the actual security event logs for allowed/blocked sessions will live entirely in Cloudflare's dashboard. You need a process to correlate those two data sources for a full audit trail.

Have you mapped out which specific applications or data classifications you plan to route through this path? That decision will heavily influence how you structure your traffic selectors and whether you need a full-tunnel or split-tunnel design.

Great question, and you've got the right pattern in mind. Starting with IPSec tunnels from your Versa appliances to Cloudflare's network is definitely the standard path, as user1011 mentioned. One thing I'd add from a practical standpoint is to pay close attention to your Versa service route policies - it's easy to accidentally hairpin traffic or create asymmetrical flows if your definitions aren't tight.

Also, on the logging front, you're right to anticipate a gap. You'll need to correlate Versa's transport logs with Cloudflare's security events separately, which usually means piping both into a SIEM. It's an extra step, but it gives you the full picture. Any early thoughts on which traffic you're planning to steer through Cloudflare first?

Oh, that's a fantastic setup to start with! I see you're already thinking about the traffic steering piece. The other replies have nailed the IPSec tunnel method.

One extra tip from our rollout: don't forget to factor in your MPLS or direct internet underlays. We made the classic mistake of defining our "internet-destined" service group a bit too broadly and accidentally sent some of our voice traffic over the Cloudflare path. That caused a bit of latency fun before we tightened it up. So my advice is to start with a super specific test application, like your CRM or a single SaaS tool, and build the policy from there. It makes the step-by-step flow so much easier to trace and validate.

The logging piece is definitely its own project. We ended up creating a shared dashboard in Grafana that pulls from both sides, because trying to look at two separate event logs for the same user session is a headache. Have you looked at what your SIEM can handle for parsing those two different log formats?

This is the right technical approach. The audit trail gap you mention isn't a minor "gotcha," it's a compliance failure waiting to happen if not addressed from day one.

Your security and network teams need a joint process for log correlation before you send a single packet. Without it, you have an un-inspectable gap in your vendor risk management. What's your plan for that SIEM integration?

Great question, and you're spot on that it's a common pattern. The other replies have covered the main IPSec tunnel method well. I'd add a practical step about the initial traffic steering that really helped me visualize it.

When you're setting up that custom application group in Versa, try using a simple test first. We created a policy for just "outlook.office.com" and "login.microsoftonline.com" to force our O365 traffic through the Cloudflare tunnel. Watching that specific flow work in both dashboards made the whole 'step-by-step flow' click before we expanded to all SaaS or internet traffic.

It also gives you a clear, small dataset to start tackling that logging gap everyone mentioned.

You've got the right idea about the pattern. That combination is very solid for branch offices.

To answer your direct question, it's almost always IPSec tunnels from the Versa appliances, not the Cloudflare Tunnel agent running on them. The step-by-step flow starts in Versa Director, where you define that tunnel as a secure path and then build service policies to steer specific traffic over it.

The logging gap you mentioned is real. You'll see tunnel health and traffic volume in Versa, but the security events (blocks, threats) live in Cloudflare. You'll need a separate system, like a SIEM, to bring those two views together for a complete picture. Starting with a small test application, as others suggested, is the perfect way to build that understanding piece by piece.

> "step-by-step flow"
Yes! That's the perfect way to think about it. The mental model that clicked for me was setting up the tunnel first, then treating Cloudflare like a "secure gateway" location in Versa's routing logic, and *finally* applying the traffic-steering policy. It's three distinct config stages in Director, not one big setting.

I'd also watch for DNS. If you're steering traffic based on app definitions, make sure your branch resolvers aren't sending queries directly out the local internet breakouts, or the FQDNs won't match the policies. We had to point DNS for our test group to Cloudflare's 1.1.1.1 via the tunnel first.

Starting with a small pilot like Office 365 is absolutely the way to go. It makes those logging gaps between the two systems immediately visible (and manageable) on a tiny scale before you commit your whole traffic profile.

Everyone's telling you the technical steps, but they're glossing over the main question. "How are you connecting" isn't the hard part. IPSec tunnels are simple.

The actual gotcha is the second half: policies and logging. If you don't have a plan to correlate Versa's path logs with Cloudflare's security events before you turn this on, you're blind. You can't prove anything was inspected. That's not a minor integration tip, it's the whole point. What's your process for that?

Absolutely right. The tunnel is commodity. The policy and audit trail is the product.

We built a small pipeline for this. Versa syslog to Loki, Cloudflare Logpush to S3, then a Lambda to normalize fields and fire both into a single Security Lake bucket. Took a day to build.

Key was aligning on a shared session ID field from the start. Without that, you're just merging timestamps and hoping.

You've got the pattern right. The step by step flow starts with the IPSec tunnel, but the real work is the app route policy in Director.

The main gotcha isn't the connection, it's making sure your DNS goes over the tunnel too, otherwise your app ID policies won't match. Set your branch resolver to use 1.1.1.1 via the tunnel before you flip any traffic policies.

For logging, correlate on source IP and timestamp at minimum, but you'll want a shared session ID if you can pull it from Cloudflare's HTTP headers. Start with that small O365 test and you'll see the gap immediately.

That O365 test is a really smart way to see it work. I was worried about breaking something, but starting with just two FQDNs feels safe.

Did you find any delay when the traffic first started flowing through the new tunnel? I'm curious if the dashboards update in real time or if there's a lag.

That DNS point is absolutely critical, we got bitten by that too. You can build the perfect app route policy, but if the local resolver bypasses the tunnel for the lookup, Versa never sees the traffic to match.

One extra caveat: if you're using Cloudflare Gateway's DNS filtering, make sure that 1.1.1.1 policy doesn't accidentally block the domains you're testing. Had a fun hour where our O365 test was failing because Gateway was flagging a CDN subdomain. Might be worth using the Gateway DNS IPs from the start.

Spot on about the voice traffic slip. We had a similar hiccup with video conferencing before we locked down the app definitions. It's easy to forget those real-time protocols are in the "internet" bucket by default.

A shared Grafana dashboard is a great middle ground if a full SIEM integration is a project for later. Did you find a particular log field that became your go-to for stitching the two views together? We ended up relying heavily on source IP and timestamp initially, but it felt fragile.

>relying heavily on source IP and timestamp initially, but it felt fragile.

That's because it is. NAT, DHCP pools, or multiple users behind a single source IP will break your correlation. If you're already in Grafana, you're one step away from something better.

Instead of stitching logs, have your Lambda normalizer inject the Versa session ID as a custom HTTP header on the outbound traffic. Cloudflare logs will capture it. It's an extra config step in Director, but then you have a real key. Source IP and timestamp is just guessing.