Zedmos
Demo & pricing:info@zedmos.comRequest a demo

Central management

One console for every OPNsense and pfSense firewall — on your server, or ours

Multi-tenant management for OPNsense and pfSense CE, hosted where you decide. Organisations, branches and firewalls in one tree; roles scoped to any level of it; and enforcement that continues when the console does not.

Request a demo
The home page of the Zedmos console with the organisations, branches and gateways it manages.
The console: every customer and every firewall, on your serverconsole.zedmos.com

Building the network is drawing it

Place the sites and connect them. The console writes the configuration for both ends of every tunnel and pushes it — nobody opens a firewall and types a rule. Minutes, not an afternoon.

The SASE canvas of the console: gateways listed on the left, spokes and a primary hub placed on a dark map with green tunnels between them, and a toolbar with failover class, layout, history and a re-deploy button.

  1. Gateways, from the fleet

    The firewalls a customer already has, listed by site. Drag one onto the canvas and it becomes a spoke or the hub.

  2. One hub terminates every tunnel

    Everything arriving at the primary hub meets the same policy: application control, IDS/IPS, TLS inspection, DLP and the AI gateway.

  3. Each tunnel reports itself

    Up or down, latency, bytes in each direction — on the link, where you are looking, not in a log you would have to open.

  4. Failover, chosen per topology

    How quickly spokes move to a backup hub when the primary stops answering is a setting of the drawing, not of each firewall.

  5. Change the drawing, then deploy

    The canvas knows when it differs from what the firewalls run. One button writes the configuration for both ends of every tunnel and pushes it.

Nobody opens a firewall and types a rule. Both ends of every tunnel are written by the console and pushed.console.zedmos.com · SASE Network

Tunnel transport

Chosen once for the topology.

WireGuard
Recommended
OpenVPN
Remote devices supported
GRE
Site to site only

People, not just sites

Remote users are added the same way, with a one-time enrolment link. Access is per device, so a lost laptop is revoked on its own.

Keeping the fleet current

Zedmos publishes the releases. You decide which firewalls take them and when.

  1. Zedmos

    We publish a release

    For the console and for the firewall, on their own schedules. The console tells you one is available rather than waiting for you to look.

  2. You

    You choose who takes it

    A few firewalls first, then the rest — or the whole estate at once. Upgrading a small group before the others is what finds a problem while it is still small.

  3. You

    You can see what is running where

    The version of every firewall, in one list. A device that fell behind fell behind for a reason, and it is missing every fix since.

Where your customers live in the tool

Four levels. A role is granted at one of them and reaches everything below it — which is how a first-line engineer sees the customer they are assigned and nobody else's.

The organisations page of the console: a tenant switcher at the top, counters for organisations, branches, gateways and owners, and the organisation directory beneath.

  1. Console — yours

    Installed on your server, under your domain. Every customer you manage is an organisation in it; the count here is the whole estate.

  2. Organisation — one per customer

    Switch it at the top and every page below follows: their firewalls, their policy, their reports, and no sight of anyone else's.

  3. Branch — one per site

    A customer with eleven offices is eleven branches under one organisation. A site engineer can be scoped to exactly one of them.

  4. Firewall — the appliance itself

    Whichever platform it runs, it registers into its branch on first boot and reports here.

  5. Three roles, granted per level

    Owner changes anything including who else has access; administrator changes policy and configuration; viewer reads reports and sessions and changes nothing.

A role is granted at one level and reaches everything below it, and nothing beside it.console.zedmos.com · Organizations

What happens when you change a policy

Written once, in one place, for as many firewalls as it should reach — and enforced on each of them whether or not the console is reachable afterwards.

The gateways page of the console: a register-token button, counters for total, online, connected and offline nodes, filters, and a list of firewalls with their version, an update button and a live-watch button.

  1. One token per customer

    Generate a register token, put it in the installer, and the firewall registers itself into the right organisation and branch on first boot.

  2. The estate at a glance

    Registered, online, connected, offline. A firewall that stopped reporting is a number here before it is a phone call.

  3. Filter by customer, site or state

    The same list serves one engineer looking after one customer and the person responsible for all of them.

  4. Versions, per firewall

    Every firewall shows what it runs. A release is offered, not forced: a few firewalls first, then the rest, or the whole estate at once.

  5. Live watch, from here

    Open the live sessions of any firewall in the list without logging in to the firewall itself.

Zedmos publishes the releases. You decide which firewalls take them, and when.console.zedmos.com · Gateways

  1. You

    Write it at the level it belongs to

    A rule for one customer sits at their organisation; one for a single site sits at that branch. A firewall added later inherits it without anyone editing anything.

  2. You

    See what it would do first

    The risk in a policy change is never the syntax — it is a correct rule that matches more than you meant. Comparing it against real traffic surfaces that before your users do.

  3. Zedmos

    It reaches every firewall in scope

    Distribution is reported per device, so a partial rollout is visible rather than assumed. Three failures out of forty is a fact you are told, not one you discover.

  4. Zedmos

    Each firewall enforces on its own

    Management and enforcement are separate. If the console is unreachable, every firewall keeps enforcing what it already holds — a security control that failed when a management server did would fail at exactly the wrong moment.

Self-hosted
A container on your server, under your domain
Hosted
console.zedmos.com, operated from Frankfurt
3 × 3
Roles across organisation, branch and firewall
Separate
Management from enforcement

Every site on one map

Fleet · 1 of 9

Every site on one map — The console opens on the whole estate: organisations, branches and gateways in one tree, and every site placed on a live map with its current health.

The console opens on the whole estate: organisations, branches and gateways in one tree, and every site placed on a live map with its current health.

What the console does, and what it deliberately does not

Self-hosted: a container you run

One Docker bundle with the database, the update path and the backup script. It holds the tenancy tree, the policy sets and the counters, and nothing leaves it. Install token in, firewall registered, five minutes.

Hosted: the same console, from Frankfurt

For teams that would rather not run a server: console.zedmos.com, operated by us on German infrastructure. Same features, same roles, same firewalls. Move to self-hosted later without re-enrolling anything.

Enforcement does not depend on it

Every firewall holds its own policy and applies it on the box. The console distributes changes and collects records; it is not in the packet path. If it is unreachable, nothing stops protecting.

Demo & pricing: info@zedmos.com

Request a demo