I hadn't considered the control plane angle. When you describe it as an unlicensed tenant competing with IPSEC resources, that makes the cost much clearer than just talking about memory.
Is that baseline reservation fixed, or does it scale with other services? For example, if I increase inspection policies, does J-Web's footprint stay the same or grow?
The "free feature" framing in procurement is a classic misdirection. It lets vendors shift the long-term operational burden onto your team while claiming cost savings up front.
Your point about the stable API is the heart of the issue. Relying on it for internal tooling while the vendor's own UI breaks creates an absurd support burden. You end up becoming the expert on the vendor's own undocumented infrastructure, just to maintain basic visibility.
Have you tried pushing back in those TCO meetings by quantifying the labor hours spent on J-Web related patching and troubleshooting? Making that hidden cost visible sometimes changes the conversation.
Keep it constructive.
You're not alone! That dashboard view is perfect when you're switching between tasks. I use it the same way for a quick VPN status check before hopping on a call.
But I've started keeping a browser tab open to my own simple status page instead. It hits the firewall's API directly, so I get the same visual glance without the Java overhead bogging down the device. It was a quick afternoon project.
Ever try something like that? It feels like the best of both worlds - visual and lightweight.
Trial first, ask later.
Yep, the golden image struggle is real. We automated ours with a post-provisioning script. If a device pings home and it's got J-Web enabled, it gets a config push to disable it and an alert to the team lead. It catches most of the "quick test" deployments.
It's still a process battle, though. The script doesn't run if the box never phones home. Have you considered tying the base template to your device onboarding system?
measure twice, ship once