Network security
that you actually
own.
Tangent Networks UTM is a self-hosted security appliance built on OpenBSD. Enterprise-grade firewall, encrypted DNS, deep content inspection, and full-stack threat blocking — deployed on your hardware, under your control, with no vendor in the middle.
Built secure, not patched secure.
The entire platform runs on OpenBSD, an operating system with a decades-long track record of proactive security auditing and a minimal default attack surface. Security is the starting point, not something added later.
The web server and every CGI script run inside a chroot jail. A compromised web request cannot read configuration files, access system binaries, or reach system processes. The kernel enforces the filesystem boundary, not policy alone.
Privileged operations such as firewall changes, DNS cache flushes, and filter mode switches never happen by elevating the web process. Dedicated root-side daemons watch file-based queues and execute commands independently. The CGI layer has no privilege path whatsoever.
Every operation that changes system state requires a valid session cookie and a per-request CSRF token. The security framework is enforced at the library level before any business logic runs, so individual scripts cannot bypass it regardless of how they are called.
All CGI scripts run under Perl's taint mode ( -T). Every value arriving from the browser must pass an explicit untaint regex before it can touch the filesystem, a shell command, or any system call. Tainted data has no path to execution.
No cloud APIs, no vendor dashboards, no telemetry endpoints. Threat intelligence feeds are fetched from public sources on your schedule. Configuration, logs, and user data never leave your infrastructure, keeping GDPR and local data retention obligations straightforward.
Four independent
shields.
Tangent Networks UTM stacks four distinct security technologies, each operating independently. A domain blocked at the DNS layer never reaches the firewall. A connection blocked by the firewall never reaches the content filter. Defence in depth is the whole point.
OpenBSD's packet filter manages every byte crossing your network boundary.
The firewall is your outermost layer, processing traffic before anything else in the stack sees it. Rules are built from live threat intelligence feeds, geographic IP data, and ASN lookups, letting you block entire hosting networks in a single entry without touching the base ruleset.
- ASN-aware blocking. Block every IP range belonging to a provider, CDN, or cloud service with one entry. Each submission is validated against PeeringDB and RIPE STAT before it goes live, with a full impact analysis showing exactly what traffic will be affected.
- GeoIP filtering. Restrict traffic by country using regularly updated CIDR databases sourced directly from RIPE NCC. No third-party subscription required.
- Live threat intelligence feeds. Blocklists download on your schedule and merge into the active ruleset atomically, with no gap in enforcement and no service interruption.
- Custom rule builder. Write syntax-validated PF rules through a guided interface. Every change passes through a staging pipeline: validate, preview, apply. Each successful apply produces a recoverable snapshot.
- Queue-based apply. Firewall changes are written to a file queue and processed by a root-side daemon. The web interface never calls pfctl directly, and the CGI process has no privilege path to the kernel.
Deep content inspection with three purpose-built filter modes.
Where the firewall blocks by address, e2guardian inspects by content. Three modes cover most deployment scenarios, and switching between them is a single click with no dropped connections and no service restart.
- ChildSafe mode. The recommended starting point for schools, libraries, and family networks. Malware domains, advertising networks, and adult content are all blocked simultaneously using a curated set of maintained threat feeds.
- General mode. Adult content filtering is disabled, but malware and advertising blocking remain active. A practical fit for staff networks or shared infrastructure where you need protection without restrictive content controls.
- Custom mode. Bring your own feeds. Add any public threat intelligence URL and the system validates, downloads, and processes it automatically within seconds of submission.
- Automated feed processing. Each mode refreshes its feed list daily. The processor handles hostfile format, plain domain lists, mixed lists, and the Capitole University archive format without any manual intervention.
- Live mode switching. Switching modes rewrites the active crontab entry and reloads e2guardian in the background. No connections drop and no manual restart is required.
Encrypted recursive DNS resolution with upstream threat blocking built in.
All DNS queries from your network are resolved by a local Unbound instance. Queries leave the network encrypted over TLS; no plaintext UDP port 53 traffic ever reaches your ISP. The upstream resolver adds an independent second layer of threat blocking before any HTTP connection is even attempted.
- DNS-over-TLS. All upstream queries go to Quad9 ( 9.9.9.11@853) over an encrypted TLS connection. Your ISP cannot observe or tamper with your DNS traffic.
- Quad9 threat blocking. Quad9's dns11 endpoint includes DNSSEC validation, ECS support, and a continuously updated threat feed that blocks malicious domains at the resolution stage.
- QNAME minimisation. Each resolver in the chain only receives the portion of a query it needs to answer (RFC 7816), limiting how much metadata any single operator can collect about your users' browsing activity.
- Cache management from the UI. Purge the full cache, flush a specific domain, export cache contents, or run a live DNS lookup test from the management interface, all processed through the privileged queue with no direct shell access.
- Tuned for sustained load. 384 MB combined cache (256 MB RRset plus 128 MB message cache), prefetch enabled, four processing threads, and a 30-minute minimum TTL to reduce upstream query volume under peak usage.
The admin plane is hardened to the same standard as the network plane.
A management interface that cannot be secured is not a management interface, it is an attack surface. Every design decision in the Tangent Networks admin panel assumes the interface may be exposed to an adversarial network.
- Three-tier auth enforcement. Every operation is classified as standard, protected, or restricted at the security library level. Protected operations require both a valid session and a per-request CSRF token. Restricted operations require an elevated admin role. No individual script can bypass this classification.
- No native browser dialogs. Every destructive or mutating action goes through a custom modal confirmation system. Native confirm() and alert() are never used, which structurally eliminates dialog-spoofing clickjacking attacks.
- Complete audit trail. Every authenticated operation is logged with session identity and a timestamp. Firewall changes, filter mode switches, and DNS cache operations all produce a permanent, reviewable record.
- Taint mode throughout. All CGI scripts run under Perl -T. Every value arriving from the browser must pass an explicit untaint regex before it can touch the filesystem, a shell command, or any privileged system call.
Correct architecture
is the security feature.
The web server serves exclusively as an unprivileged request processor. It operates without access to escalation utilities like sudo or doas, and without the permissions required to modify the firewall, reconfigure DNS, or toggle filter modes.
System state changes are decoupled from the web execution context entirely. The web process communicates intent by writing to a secure queue directory. Execution is handled by independent root-side processes that act on those queue entries. This enforces a strict one-way data flow: the web layer can express what it wants done, but it can never do it directly.
// Tangent Networks UTM design principleFile-Based Queue Architecture
Privileged operations are never triggered by elevating the web process. A CGI script writes a validated, structured request file to a watched directory. A dedicated root-side daemon reads it, executes the appropriate command, and writes the outcome back for the browser to collect.
- CGI writes a validated request file with structured parameters
- Root daemon executes unbound-control or pfctl as appropriate
- Outcome encoded as JSON via jq and written back to queue
- Request and outcome files removed after each completed operation
chroot Boundary Enforcement
The web server runs inside the /var/www chroot. System binaries, configuration files, and the host OS filesystem are invisible to any web process regardless of what an attacker might execute inside the chroot.
- CGI scripts see only the /var/www filesystem tree
- Debug logs write to /tmp, which maps to /var/www/tmp outside the chroot
- Paths constructed with File::Spec, never through string concatenation
- All external path values validated against untaint regex before use
Daemon Lifecycle Management
All background services start from /etc/rc.local via a shared start_service() function that validates executability, detects stale PID files, and verifies the process is still alive before writing the PID to disk.
- PID files stored under /data/run/webui/, readable by monitoring tools
- Runners loop on fixed sleep intervals rather than spawning via cron
- EXIT, INT, and TERM traps clean up PID files on shutdown
- Stale PID detection prevents duplicate daemon instances across reboots
Staging Pipeline for Firewall Changes
No firewall rule goes live without passing a full validation pipeline. Rules assemble into a staging configuration, are tested with pfctl -nf (dry run), and a verdict file is written before any apply is attempted. A failed validation stops the pipeline completely.
- pf_validator.pl assembles staging/pf-addons.conf from all queue inputs
- pfctl -nf validates syntax; verdict written before any live change
- Apply copies staging conf to /etc/pf, reloads anchor, writes snapshot
- Reset flushes the anchor, clears all user inputs, and purges all snapshots
IPv4 and IPv6.
Inspected equally.
Most network security systems treat IPv6 as an afterthought and leave a gap between what is filtered on one protocol and what is allowed on the other. Tangent Networks UTM provides identical inspection coverage across both address families, with no fallback paths and no unmonitored protocol.
NAT64 and DNS64
IPv6-only LAN clients can reach IPv4-only internet destinations transparently. PF performs address-family translation while Unbound synthesises AAAA records under the NAT64 prefix. The result is full internet access for IPv6 clients with no manual address mapping required.
Snort IPS on Both Families
Snort runs inline in IPS mode and inspects traffic from both IPv4 and IPv6 clients. The SSLproxy preprocessor was extended to correctly parse and map IPv6 client and server addresses, providing full rule enforcement across both protocol families without a parallel ruleset.
TLS Inspection for IPv6 Clients
SSLproxy intercepts and decrypts TLS sessions from both IPv4 and IPv6 LAN clients, re-originating the decrypted traffic on loopback for inspection by Snort and e2guardian. IPv6 clients receive exactly the same inspection depth as IPv4 clients throughout the chain.
Unified PF Ruleset
PF enforces policy across both address families from a single ruleset. NAT44, NAT66, and NAT64 all operate simultaneously. All traffic is logged to the same pflog1 interface regardless of protocol family, giving the WebUI a unified view of what is happening on the network.
The web process
has no privilege path.
The most important security property of Tangent Networks UTM is that the web server and everything running inside it cannot perform privileged actions directly. Not through sudo. Not through doas. Not through setuid binaries. The boundary is absolute and enforced at the kernel level.
// www process (chrooted)
// e2guardian, ksh, or any system binary.
// Cannot read: /etc, /usr, /bin, /sbin.
// Filesystem view limited to /var/www/*
// root daemons (full system access)
// Never triggered by: HTTP requests directly.
// Communication: file-based queue only.
// No socket or IPC exposure to www process.
Your network.
Your data. Your rules.
Cloud-managed network security means your traffic is observed, reported, or processed by someone else's infrastructure. Tangent Networks UTM runs entirely on your hardware, on your network, under your control, with no external dependency for any core security function.
What the interface
actually looks like.
No marketing mockups. These are real screenshots from a live Tangent Networks UTM management interface. Click any image to view full size.
Ready to take back
control of your network?
Tangent Networks UTM deploys on commodity hardware and can be managed day-to-day by a single IT coordinator. No vendor professional services, no proprietary appliance, no ongoing subscription. Request a demo to see the full management interface running on a live system.
Self-hosted · OpenBSD-based · No cloud dependency · Deployable on any organisation's hardware