Ask SecureGuard a question. Answers come from this site's docs only. I will cite a page. I will not invent a product claim.
Object-based, zone-aware NGFW for the people who run it
The motto is simple technology, and it is meant literally: the hard part of a firewall is not the packet filter, it is the model an operator has to hold in their head at 2am. The product is the orchestration layer and the console over that model.
We did not rewrite the firewall
pf, FRR, strongSwan, Kea, Unbound, Suricata and Squid are excellent, battle-tested components maintained by people who have spent decades on them. Replacing them would be arrogant and slow. So the product is not a new dataplane — it is the orchestration layer above them: one canonical, object-based, zone-aware configuration document, a commit engine that renders it into each daemon's native config and applies it atomically, and a console over that model.
That boundary is why features that are usually separate projects here fall out of a single decision. Backup is copying a revision. Export for review is reading one. Rollback is an id. Config sync between HA nodes is shipping revisions. None of those needed to be built twice.
Why FreeBSD, and why closed source
SecureGuard is a commercial security appliance. A BSD-licensed base lets the parts we write stay proprietary without copyleft obligations creeping into a kernel or dataplane, and FreeBSD gives us pf and pfsync — native connection-state sync between cluster nodes — rather than something bolted on. ZFS-on-root gives us boot environments, which is what makes an upgrade something you can back out of.
Being closed source does place an obligation on us, though: you should never have to take the product's word for what it did. So the rendered daemon configs, the audit log, the revision history, a terminal and a support bundle are all in the console, and the documentation on this site describes mechanisms rather than benefits.
Borrowed ideas, credited
The management model comes from the old Astaro/Sophos UTM: objects and zones, one IP and one MAC per segment in a cluster, NAT kept away from policy. The commit pipeline — candidate, validate, render, apply, with a confirmed-commit window that reverts itself if you go quiet — comes from Junos and VyOS. Zone protection profiles, and the vocabulary of allow/alert/block/block-ip, come from Palo Alto. The console's shape is PAN-OS-shaped for the same reason: people already know it.
The parts we think are genuinely ours are the single-document engine, and the graduated response in the AI layer — throttling grey traffic into a slow queue instead of choosing between ignoring it and dropping it. That design is written up in full.
Talk to us
Rubix Technology LLC builds SecureGuard and the rest of the Rubix product line. Sales and evaluations: sales@secure-guard.io. Support: support@secure-guard.io. Or describe your network and we will answer honestly about fit.
Install the image on hardware or a VM you control
Get a free license, install the appliance, and turn the code plus the node ID it shows you into a node-locked license key.