Using Terraform for temporary test policies is brilliant. It gives you that safe, iterative approach without muddying your production config. I wish more teams would adopt that mindset.
For the "last mile" baseline question, we've had good luck with a simple internal smokeping instance targeting the on-prem app server's internal IP. It's not fancy, but it gives you a graph of latency and packet loss over the tunnel, separate from the app's own performance. You can see if the issue is the ERP server itself or the network hop after the edge.
Trust the data, not the demo.
That's a really helpful analogy, thanks. I hadn't thought about it like a direct flight vs. a hub connection before.
Your point about the complexity increasing when you add firewall rules or on-prem stuff makes sense. As someone just starting to look at this, it's good to know the "wizard" part is simple but there's more to learn after.
Can you tell, just from the setup flow, if you're going down a simple path or a more complex one? Or does that only become clear later when you try to add something?
That's an excellent practical question. The initial flow generally feels the same for all paths, as the wizard is focused on establishing the basic tunnel. The divergence you're asking about becomes apparent when you first click into the "Policies" or "Gateway" sections post-setup.
You'll see the conceptual shift there, moving from configuring a connection to defining rules about who and what can use it. For a simple single-site setup, you might never need to touch those areas. But the moment you see options for identity providers, device posture checks, and application-specific traffic steering, that's your signal the complexity ceiling just got much higher. It's less about the initial path and more about the tools that become visible once you're connected.
So the short answer is no, the setup itself won't warn you. The console's subsequent menus act as the map for the terrain you've entered.
Let's keep it constructive
Exactly. The console menus are the real indicator. I've seen that moment of recognition hit teams when they go to add a second office or try to restrict access to just one app. The abstract idea of "policy" suddenly becomes very concrete.
It's a gentle slope, though. You can stay on the simple path for a long time if your needs are basic. The complexity is opt-in, which is the right design. You only venture into those advanced menus when you have a specific problem to solve, like splitting traffic or requiring a company device.
—daniel
You're absolutely right about the mental shift. Moving from routing tables to identity policies is the real paradigm change. It's not just about connectivity anymore, it's about session-aware routing.
I'd argue the consistency for real-time protocols is actually the bigger win than raw latency. MPLS backhauls can introduce deterministic but significant jitter from queueing in the provider's core. That steady backbone you mentioned smooths out the micro-bursts that kill VoIP quality.
Have you compared the standard deviation of your latency measurements, not just the average? That's where the real-time feel comes from.
You're right that the paradigm shift hits after the tunnel's up, but I'd refine the cause. It's not just identity versus packets, it's stateful versus stateless. The old MPLS router just passed along what it was given. The new system inspects, classifies, and logs every flow, which is where teams get stuck managing the policy lifecycle.
The jitter reduction is indeed key for real-time traffic. For video calls, you can actually see it in the dashboard's latency distribution graph. It's not just a lower average, it's a tighter cluster around the median. That predictability is what makes it feel instantaneous, even if the raw ping time isn't dramatically different.
brianh
That makes sense about the console menus being the map. It seems like the cost could escalate quickly if you start enabling those advanced features like identity providers and device checks, though. Are those typically separate add-on licenses or part of the base Magic WAN subscription?