Air-gapped deployment
Nothing phones home to run. The licence is verified on the appliance, offline. Built for telco core, classified, and segmented OT networks where outbound HTTPS is blocked.
Air-gap support often hinges on a hidden dependency — a licence server, a telemetry endpoint, or a package CDN. DHCP Shield Pro has none of those at runtime: it is self-hosted on your own Linux host and, once installed, does not reach the internet to do its job. This page is the procurement-facing summary; the step-by-step reference lives in the installation docs.
Definitions
What “offline” means here
Runtime and install have different network needs, so they're stated separately.
- Runtime — fully offline. No outbound HTTPS, no phone-home, no licence round-trip. Inspection, enforcement, analytics, and licence verification all run on the host.
- Install — needs its packages. The installer pulls dependencies from your Linux distribution's repositories and the ClickHouse package repository. On a host with no internet you stage those packages on a local mirror first (see below); we do not ship a single bundle that contains every OS dependency.
Runtime
Runtime: no outbound connectivity required
After install, the appliance behaves like an ordinary Linux host running an nftables firewall that happens to inspect DHCP. None of its core functions depend on reaching the outside world:
- Packet inspection and kernel-level enforcement run locally.
- Events are stored in a local ClickHouse instance; reports and queries run against it.
- Anomaly detection runs locally; the optional LLM backend points at a server you host.
- The licence is verified on the appliance with no network call (see below).
- The optional support backchannel is the only outbound channel — and it is opt-in and stays off on an isolated site. Nothing else leaves the host.
Install
Installing on an isolated host
The appliance ships as Debian packages plus an installer that wires up ClickHouse, the web front end, the nftables ruleset, and the system services. On a connected host the installer fetches dependencies for you. On an isolated host, give it a package source it can reach without the internet:
- Stage the OS dependencies and the ClickHouse packages on a local mirror your isolated host can reach (or pre-seed them into an internal apt repository).
- Transport the shipped product packages to the host on approved removable media, after confirming their integrity against the checksums and signature we publish.
- Install the packages, then run the installer; it provisions an inline single-host deployment by default.
- Confirm the services are up and the web UI is reachable on the host.
Plan the mirror up front. A genuinely isolated install fails fast if the dependency mirror isn't staged first — this is the step most “offline” setups trip on. Treat it as part of procurement, not an afterthought.
Licence
Offline licence activation
Activation needs no network. The appliance verifies the licence's cryptographic signature using a public key built into the binary — entirely on the host. The flow on an air-gapped site is the same hot operation as anywhere else, with one extra transport step:
- On a connected workstation, receive the licence file from sales.
- Transport it to the isolated host via approved removable media.
- Upload it on the License page in the GUI and apply it; features unlock immediately.
The licence is tied to the appliance's Installation ID — a stable random identifier the host generates on first boot, not a hardware fingerprint — so routine hardware maintenance never forces a re-activation.
Air-gapped deployments can be issued a longer validity term at sales discretion so renewals are infrequent; request the extended term during procurement. See the licensing model for the full detail.
Remote sites
Covering isolated and remote sites
For sites you can't (or won't) place an enforcement host inside, the appliance also runs in a passive mirrored mode: it receives copies of DHCP traffic from a switch mirror port and only observes.
For distributed estates, a lightweight capture component at each remote site forwards DHCP frames over a packet-tunnelling protocol (TZSP) to a central collector for inspection — observation only, with no inline impact on the remote site's DHCP. That tunnel is plain UDP, so wrap it in your own VPN or transport encryption when it crosses untrusted links.
Lifecycle
Updates and support
Updates follow the same staged path as the initial install: verify the new packages' integrity on a connected machine, transport them in, and run the upgrade. Database migrations run in place.
For support, an isolated site can't use the outbound support tunnel, so escalation is handled through your normal support channel; when diagnostics are requested, the appliance can produce a text-only bundle of logs, configuration, and recent counters — no DHCP packet payloads — that you carry out on removable media.
On the support session, for sites that do allow it. The support session is consent-based and entirely under your control: it is explicitly auditable, time-boxed and revocable, can be disabled completely, and opens no standing inbound path to the appliance. On an air-gapped site it simply stays off, and support runs through the offline diagnostic bundle above.
Keep reading
Related
Self-hosted, and it stays that way.
No licence server, no telemetry endpoint, no package CDN to keep healthy. Talk to us about an isolated deployment.