DEV Community: Neil Briscoe

How to reduce Azure Firewall costs: 7 ways, ranked by savings

Neil Briscoe — Mon, 03 Aug 2026 15:00:10 +0000

Azure Firewall's bill has a floor and a meter. The floor is the
per-deployment-hour fee: $1.25/hr on Standard, which is about $912 a month
before a single byte moves. That is a strong interpretation of
"pay as you go". The meter is $0.016 per GB processed, uncapped, on
everything you route through it. And the floor multiplies: the same rates
re-apply per secured virtual hub, so a tidy multi-region hub-and-spoke
diagram is also a multiplication exercise. (Rates Central US, dated
2026-07-04, directional.)

Disclosure before we start: I work on Enforza, which is option 7 below.
It gets one section, at the end, after six things you should try first. Most
of them are configuration, not products.

Same rules as the AWS version of this guide:
ranked by how much of the bill each move typically removes, boring ones first,
because that's where the money is.

The ranking at a glance

Right-size the SKU. Premium without TLS inspection in use is $365/month of nothing. Basic below ~12 TB/month beats Standard's floor.
Deallocate what sleeps. Azure Firewall has an off switch. Dev and test firewalls off nights and weekends drop ~70% of their hourly line.
Count your deployments. Every extra firewall or secured hub is another $912/month floor. Consolidate where the architecture allows.
Keep Azure-bound traffic off the meter. Service endpoints are free; stop paying $0.016/GB to inspect your own backups.
Hunt your top talkers. Firewall logs, aggregate, rank, be mildly annoyed, fix with caching and routing granularity.
Prune the forgotten floors. Idle POC and staging firewalls bill $912 a month for existing. Delete or deallocate them.
A flat-priced NVA. Same egress-firewall job, flat licence, no per-GB meter, one floor instead of several.

Now each one, with the arithmetic.

1. Right-size the SKU

Three rate cards, frequently mixed up, occasionally all paid at once.
Standard is $1.25/hr plus $0.016/GB. Premium is $1.75/hr plus the same
$0.016/GB: the extra $0.50/hr, about $365 a month per deployment, buys
TLS inspection and IDPS. Premium is excellent value right up until you check
whether anyone actually enabled those features. If they didn't, that's a
one-line change worth $4,380 a year.

Basic runs the other direction: a $0.395/hr floor, about $288 a month, but a
$0.065/GB meter, four times Standard's rate. The break-even sits around
12 to 13 TB of processed data a month. Below it, Basic's lower floor
wins. Above it, Basic is the expensive option wearing a budget name badge.
Basic also caps throughput and trims features, so read the limits first. The
one unforgivable move is quoting Standard's floor with Basic's meter, or vice
versa; the two rate cards never mix.

2. Deallocate what sleeps

Here is the rarest thing in cloud billing: an off switch. Azure Firewall can
be deallocated. Stopped, the per-hour fee stops with it; allocated again,
it comes back in a few minutes. AWS offers nothing like this for a NAT
Gateway, which makes it strange that so few Azure teams use it.

A dev firewall runs 730 hours a month. The team that uses it works maybe 200
of those. Deallocating outside working hours removes roughly 70% of that
firewall's hourly line, which on Standard is around $640 a month per dev
firewall, for the cost of a small automation script and a few minutes of
patience on Monday morning. A firewall guarding an empty dev environment at
3am is protecting sleep nobody is having.

3. Count your deployments

The rates re-apply per deployment and per secured virtual hub. This is where
tidy architecture gets expensive: firewalls multiply the way meeting invites
do, one per region, one per environment, one per team that didn't want to
share, and each one brings its own $912 floor before traffic.

The consolidation play is standard hub-and-spoke: one firewall in the hub,
spokes peered to it, instead of a firewall per VNet. The honest caveats: VNet
peering carries its own per-GB charge, consolidation concentrates blast
radius, and cross-region traffic should stay regional. But the arithmetic is
blunt. Two Standard deployments doing the work of one is $912 a month of
duplicated floor; count yours, then justify each one out loud.

4. Keep Azure-bound traffic off the meter

With a blanket 0.0.0.0/0 route through the firewall, everything pays the
meter, including traffic to your own Azure services. Backups to your own
storage account, container image pulls from ACR, log shipping to your
workspace: $0.016/GB each, for the privilege of being inspected on the way
to your own resources.

Service endpoints are free and keep Azure-service traffic on the Microsoft
backbone without the firewall hairpin. Private endpoints cost roughly
$0.01/hr plus $0.01/GB (checked 2026-08-03, directional) and buy the same
bypass with a private IP where you need it. Route with some granularity
instead of one blanket default, and the meter only sees the traffic that
actually warrants inspection. Your security team keeps control of what
matters; your backups stop paying tolls.

5. Hunt your top talkers

Same discipline as on AWS, different console. Azure Firewall's logs (or the
built-in workbook) aggregated by destination will produce a top-ten list, and
the list will annoy you. The usual suspects: image pulls that a cache would
kill, telemetry sending the same heartbeat uncompressed every ten seconds,
CI downloading identical packages hundreds of times a day in case they
changed, and one chatty third-party API nobody remembers integrating.

Fix with caching, batching and compression, then re-check quarterly. New
workloads invent new talkers. They always do.

6. Prune the forgotten floors

Somewhere in your subscriptions there is a firewall from a proof of concept
that ended in March. It bills $912 a month for existing. The floor charges
whether bytes flow or not, which makes idle firewalls the purest waste on
this list: nothing is being protected, inspected or even routed. Sweep for
firewalls with near-zero processed data, then delete them, or deallocate the
ones somebody swears they'll need again. The POC will not miss it.

7. Replace the floor and the meter with one flat price (this is us)

The last option is the one I have a stake in, so weigh my enthusiasm
accordingly. Enforza is a network virtual appliance,
one Linux VM in your own VNet, that does the egress-firewall job: stateful
L3/L4, FQDN/SNI-based allow and deny on what leaves, and its own source NAT,
so it covers the outbound role too. Flat per-firewall licence, about $239 a
month, less at fleet volume, $0/GB processed, and the VM stays on your
Azure bill because physics and Microsoft both insist.

Against Standard's floor-plus-meter that typically lands up to 60–80%
lower, and the gap widens with traffic and with every consolidated hub
deployment, because a flat line doesn't multiply. Directional and dated, so
check it against your own bill: the savings calculator
takes two minutes, and the 20 TB worked example
prices the comparison line by line if you'd rather see the working.

The honest boundaries. At low volume on Basic the gap narrows, and if you're
deep into Premium's TLS inspection or Sentinel-native tooling, the native
integration is a real reason to stay. And a deadline worth knowing either
way: Microsoft is retiring default outbound access on March 31, 2026,
after which every workload needs an explicit egress path: Azure Firewall,
NAT Gateway, Load Balancer outbound rules, or an NVA. You'll be making this
decision anyway; the only question is whether you cost it first.

The short version

Audit first, then take the configuration savings, then decide what the
remainder is worth:

Right-size the SKU. Premium unused features off; Basic only below ~12 TB/month.
Deallocate dev and test outside working hours. The off switch exists.
Count deployments; consolidate the duplicate floors.
Service endpoints and granular routes; stop metering your own backups.
Logs, top talkers, caching. Repeat quarterly.
Delete the POC firewall from March.
Flat-priced NVA if the floors and meters still add up to real money.

For the line-by-line anatomy, see Azure Firewall pricing
and the Azure NAT Gateway breakdown; for the same
exercise on AWS, how to reduce AWS NAT Gateway costs;
for the multi-cloud view, reducing cloud NAT costs.

FAQ

Frequently asked questions

How much does Azure Firewall cost?

Two charges at once. A per-deployment-hour fee of $1.25/hr on Standard (about $912/month) or $1.75/hr on Premium (about $1,278/month), before any traffic, plus $0.016 per GB processed, uncapped. The cheaper Basic SKU is $0.395/hr (about $288/month) but pays a higher $0.065/GB. The same rates re-apply per secured virtual hub, so multi-region hub-and-spoke estates multiply the hourly line. Rates Central US, dated 2026-07-04, directional.

Can I turn Azure Firewall off when I'm not using it?

Yes, and almost nobody does. Azure Firewall supports deallocation: stop it and the per-hour billing stops with it; allocate it again when you need it, which takes a few minutes. For a dev or test firewall that nobody touches outside working hours, deallocating nights and weekends removes roughly 70% of that firewall's hourly line. It needs a small automation script and the willingness to wait a few minutes on Monday morning.

Is Azure Firewall Basic cheaper than Standard?

On the floor, yes: about $288/month versus about $912/month. On the meter, no: Basic processes data at $0.065/GB against Standard's $0.016/GB, four times the rate. The break-even is around 12 to 13 TB of processed data a month; below it Basic wins, above it Basic quietly becomes the expensive option. Basic also caps throughput and drops features, so check the limits before celebrating. Never mix the two rate cards in one estimate.

Do I need Azure Firewall and a NAT Gateway?

Usually not both for egress. Azure Firewall performs its own source NAT, so there is no AWS-style NAT-gateway-behind-firewall stacking. The question is becoming unavoidable anyway: Microsoft is retiring default outbound access (March 31, 2026), after which every workload needs an explicit egress path: Azure Firewall, a NAT Gateway, Load Balancer outbound rules, or an NVA. Which one you pick is now a costed decision rather than a default.

What Azure Firewall traffic costs the most?

Whatever you hairpin through it that never needed inspection. With a blanket 0.0.0.0/0 route through the firewall, backups to your own storage accounts, container image pulls and log shipping all pay $0.016/GB for the privilege of being waved through. Firewall logs (or the workbook) aggregated by destination will show your top ten. The fixes are routing granularity, service endpoints and caching, in that order.

How much can I save replacing Azure Firewall?

It depends on volume and how many deployments you run, and anyone quoting one number without asking is selling something. A flat-priced NVA such as Enforza does the same egress-firewall job (stateful L3/L4, FQDN/SNI filtering, its own source NAT) at a flat per-firewall licence, about $239/month, less at fleet volume, plus the VM on your Azure bill. Against Standard's $912/month floor plus metering, that typically lands up to 60–80% lower, and the gap widens with traffic and with every extra hub deployment. At low volume on Basic, the honest answer is the gap narrows. Run your own numbers in the savings calculator, or read the 20 TB worked example priced line by line.

How to reduce AWS NAT Gateway costs: 7 ways, ranked by savings

Neil Briscoe — Mon, 03 Aug 2026 14:49:39 +0000

The AWS NAT Gateway bill has two lines. The hourly fee is $0.045 per
gateway-hour, about $33 a month, and it is the least interesting number on your
invoice. The other line is the data-processing charge: $0.045 for every
gigabyte the gateway touches, in either direction. That one compounds. It grows
with traffic you didn't know was internet-bound, it multiplies across
Availability Zones, and it surfaces in a bill review three months later as a
number nobody can explain and everybody has approved. Nobody has ever been
paged for a NAT Gateway, which is precisely why nobody looks at it. (Rates
us-east-1, dated 2026-07-31, directional.)

Disclosure before we start: I work on Enforza, which is option 7 below. It
gets one section, at the end, after six things you should try first. Several of
them are free, which is a difficult price to argue with.

The list is ranked by how much of the bill each move typically removes, not by
how interesting it is to implement. The boring ones are at the top. That's
where the money is.

The ranking at a glance

Free gateway endpoints for S3 and DynamoDB. Often removes 30–60% of the per-GB line. Costs nothing. Do it today.
Interface endpoints for busy AWS services. The next 10–30%, wherever a service clears the break-even.
Hunt your top talkers with VPC Flow Logs. 10–40% once you can actually see the traffic. The fixes are mostly caching and hygiene.
Route zonally, or consolidate deliberately. Stops the cross-AZ surcharge stacking on top of NAT processing.
Consolidate non-production. Pure hourly-line savings. Sprawling dev estates leak $33 a month per forgotten gateway.
Swap in a NAT instance (fck-nat). Kills the per-GB line entirely, in exchange for owning the operations.
A flat-priced NVA with egress filtering built in. Kills the per-GB line and the separate firewall meter, for a flat licence plus a VM you run.

Now each one, with the arithmetic.

1. Add the free S3 and DynamoDB gateway endpoints

Gateway endpoints for S3 and DynamoDB are free in the way AWS things rarely
are: actually free. No hourly fee, no per-GB fee. A route-table entry sends
that traffic over the endpoint instead of through NAT, and the charge simply
stops.

This is usually the single largest cut available, and it is bigger than people
expect for one sneaky reason: container image pulls ride on S3. ECR stores
image layers in S3, so a busy EKS cluster pulling through a NAT Gateway has
been paying NAT rates to re-download the same Ubuntu layers it downloaded
yesterday. And the day before.

There is no threshold, no break-even and no trade-off here beyond a route-table
change per VPC. If you read no further, do this one.

2. Add interface endpoints for the busy AWS services

Interface endpoints (PrivateLink) extend the same idea to the rest of AWS:
ECR's API, CloudWatch Logs, STS, SSM, Secrets Manager. Unlike gateway
endpoints they are not free. Roughly $0.01 per hour per endpoint per AZ plus
about $0.01/GB (us-east-1, checked 2026-07-31, directional).

The arithmetic that matters: you save about $0.035/GB versus NAT processing,
and the endpoint's standing cost is about $7.30 a month per AZ. So an
interface endpoint pays for itself at roughly 200 GB a month per service.
ECR and log shipping clear that on any real cluster without noticing. The
service you call twice a day does not, and endpointing it anyway is how people
end up reducing their NAT bill by increasing their total bill.

Which services are busy enough? That's step 3.

3. Find your top talkers with VPC Flow Logs

You can't cut traffic you can't see. Turn on VPC Flow Logs for the NAT
Gateway's network interfaces, aggregate by destination, rank, and prepare to be
mildly annoyed by what you find. Every big NAT-savings write-up on the
internet, all the "how we cut 40%" and "how we cut 52%" posts, is secretly this
step wearing a headline.

The usual suspects, and the usual fixes:

Image pulls. Slim the images, add a pull-through cache, and check the S3 endpoint from step 1 is actually carrying the layers.
Log and telemetry shipping. Batch and compress, and send CloudWatch-bound traffic over an interface endpoint rather than out the front door.
Package registries in CI. Your build farm is downloading the same packages four hundred times a day, apparently in case they change. A proxy cache (or CodeArtifact) turns that into once.
Chatty third-party APIs. Batch where the API allows it. You are paying NAT processing on every iteration of somebody's polling loop.

Expect to repeat this quarterly. New workloads invent new talkers, reliably.

4. Stop paying the cross-AZ surcharge

Traffic from a subnet in one Availability Zone through a NAT Gateway in
another pays cross-AZ data transfer on top of NAT processing. You are
paying a surcharge for your bytes to commute between buildings before they
leave. If you consolidated to one gateway "to save money" and now push serious
traffic to it from three AZs, part of that saving is being quietly clawed
back, and you gained a cross-AZ failure dependency as a bonus.

High-traffic estates want a gateway per AZ with zonal route tables so traffic
stays local. Small quiet estates want the opposite: one gateway, accept the
cross-AZ pennies, bank the duplicate hourly fees. There is no universal
answer, just a break-even, and it takes ten minutes with your traffic numbers
to find out which side of it you live on.

5. Consolidate non-production

Production topology gets designed. Dev topology gets copied from the
production template, faithfully, including the parts that cost money at 2am.
Every sandbox VPC with three NAT gateways (one per AZ, because that's what
prod does) is paying the hourly line for connectivity nobody is using.

Ten forgotten gateways is $330 a month, which is a decent team dinner nobody
got to eat. Centralise non-prod egress where isolation requirements allow, and
for truly ephemeral environments let the IaC tear the gateway down with the
rest of the stack. It will not miss you. (If you're consolidating egress
across VPCs properly, the AWS landing-zone pattern
shows the route-table shape; it's the same pattern whoever's appliance sits in
the middle.)

6. Swap in a NAT instance you operate

A NAT instance is a VM doing source NAT, which is what the managed gateway is
underneath anyway. It pays no per-GB processing fee at all. Just the
instance and normal data-transfer-out. fck-nat is the
well-maintained open-source version (the name tells you the founding mood):
current ARM images, a clean Terraform module, and instances that cost a few
dollars a month per AZ. On the metered line it is unbeatable, and our own
comparison page says so.

What you take on in exchange: high availability (its documented failover is
active-passive with route reconvergence), patching, monitoring, and the box's
own attack surface. And it is exactly NAT. It is excellent at what it does;
what it does is NAT. If you need to control or even see what is leaving your
network, that is not on the menu.

7. Replace the meter with a flat price (this is us)

The last option is the one I have a stake in, so weigh my enthusiasm
accordingly. Enforza is a network virtual appliance,
one Linux VM in your own VPC, that does the NAT Gateway's job with no per-GB
charge at a flat per-firewall licence: about $239 a month, less at fleet
volume, and the VM itself stays on your AWS bill because we are not magicians.
The difference from option 6 is that it's managed (HA, patching and fleet
policy handled) and it's also an egress firewall: FQDN/SNI-based allow and
deny on what leaves, with logs your auditor will accept. So it can replace a
separate firewall meter as well as the NAT one.

The honest boundaries. At low volumes a plain NAT Gateway with free endpoints
is hard to beat, and I'd rather tell you that here than have you discover it
in a renewal meeting. The "up to 60–80%" saving we quote is against a metered
NAT-plus-firewall stack at meaningful volume: dated, directional, and worth
checking against your own bill in the
savings calculator rather than taking on faith. One
wrinkle worth knowing: since 2026-02-06 AWS waives the NAT Gateway fee when
the gateway sits behind AWS Network Firewall. If you're already paying Network
Firewall's $0.065/GB, filtered egress is one meter, not two, and that one
meter is the comparison to run.

The short version

Measure first, take the free money, then decide how much of the remainder is
worth engineering away:

Gateway endpoints for S3 and DynamoDB. Free, immediate, often the biggest single cut.
Interface endpoints where a service clears ~200 GB a month.
Flow Logs, then fix the top talkers. Mostly caching and hygiene.
Zonal routing (or deliberate consolidation). Stop stacking cross-AZ on NAT.
Non-prod cleanup. The hourly line there is pure waste.
NAT instance / fck-nat, if you can own the ops.
Flat-priced NVA with egress filtering, if you want it managed or you were about to pay for a firewall anyway.

For the line-by-line anatomy of the bill itself, see
what an AWS NAT Gateway actually costs
and the rates-at-a-glance page; for the mechanics of
NAT, how NAT gateways work.

FAQ

Frequently asked questions

How do I reduce AWS NAT Gateway costs?

In order of typical impact: add the free S3 and DynamoDB gateway endpoints so that traffic never touches the NAT Gateway at all; add interface endpoints (PrivateLink) for busy AWS services like ECR and CloudWatch; use VPC Flow Logs to find and fix your top talkers; route zonally so you aren't paying cross-AZ transfer on top of NAT processing; consolidate non-production gateways; and for the remaining internet egress, replace the gateway with a NAT instance you operate or a flat-priced NVA. The per-GB data-processing charge is almost always the line to attack. The hourly fee is a rounding error next to it.

What uses the most NAT Gateway data?

On most estates the biggest single slice is traffic to AWS's own services: container image pulls (ECR layers are stored in S3), log shipping, and S3 access from private subnets. None of it needed to go through NAT in the first place. After that come package registries during builds, telemetry agents, and chatty third-party APIs. VPC Flow Logs aggregated by destination will show your actual top ten in an afternoon.

Are VPC endpoints free?

Gateway endpoints for Amazon S3 and DynamoDB are free. No hourly fee, no per-GB fee, which is why they are always step one. Interface endpoints (PrivateLink) are not free: roughly $0.01 per hour per endpoint per Availability Zone plus about $0.01/GB (us-east-1, checked 2026-07-31, directional). That beats the NAT Gateway's $0.045/GB from roughly 200 GB a month per service. Below that volume the endpoint costs more than it saves.

Does one NAT Gateway per Availability Zone save money?

It removes the cross-AZ data-transfer charge you pay when a subnet in one AZ routes through a gateway in another, and it removes a cross-AZ failure dependency. But each gateway also adds its own hourly fee, about $33 a month. High-traffic production estates usually save with per-AZ gateways; small quiet VPCs often save by consolidating to one gateway and accepting the cross-AZ pennies. Which side of the line you are on is arithmetic, not doctrine.

Is a NAT instance cheaper than a NAT Gateway?

On the metered line, dramatically. A NAT instance pays no $0.045/GB processing fee, just the VM and normal data-transfer-out. fck-nat, the well-maintained open-source option, runs on instances costing a few dollars a month per AZ. The trade is operational: high availability, patching and monitoring are yours, and it is plain source NAT with no egress filtering. It is the right answer when you can own the ops and only need connectivity.

How much can I save replacing the NAT Gateway entirely?

It depends on volume, and anyone who gives you one number without asking about your traffic is selling something. A NAT instance removes the per-GB line for the cost of your own operations. A flat-priced NVA such as Enforza removes it for a flat per-firewall licence (about $239/month, less at fleet volume, plus the VM on your AWS bill) and adds FQDN egress filtering. Against a metered NAT-plus-firewall stack that typically lands up to 60–80% lower from meaningful egress volumes, and the gap widens as traffic grows. At low volumes the honest answer is that a plain NAT Gateway with free gateway endpoints is hard to beat. Run your own numbers.

enforza-cockpit: a free web GUI for nftables

Neil Briscoe — Fri, 31 Jul 2026 14:07:37 +0000

nftables is the right tool for a Linux firewall and a genuinely nice piece of
engineering, but writing rulesets by hand is a niche pleasure. If you run a homelab
or a small cloud box and you want a firewall you can see and click, without pulling
in a whole appliance distribution or standing up something in the cloud, there is a
free, open-source option worth knowing about:
enforza-cockpit. It is a Cockpit plugin that gives you a browser GUI over
nftables. Install it, build a policy, and watch per-rule logs land in your syslog.

This article walks through what it is and how to use it. It asks nothing of you and
there is nothing to buy, so read it as a how-to. The one-line disclosure of who
makes it is at the bottom where it belongs.

What it actually is

enforza-cockpit turns a single Linux box into three things that usually come
separately, all on the one host and with nothing external to depend on:

A firewall. Three rule sections compile to a live nftables ruleset that filters traffic to, through, and from the host.
A router and NAT gateway. Turn on IP forwarding and the box routes between its interfaces; mark a rule SNAT and it masquerades outbound traffic, so it works as an edge gateway for whatever sits behind it.
A management console. Cockpit's web UI is the console. You build, preview, apply and log every rule from the browser. There is no separate controller, no agent phoning home, and no cloud account.

Because it runs entirely on the one host and inside Cockpit's own authentication
and TLS, the result is a stand-alone appliance you happen to manage from a web
page. That is the whole idea: a clean GUI wrapper for a local nftables firewall,
nothing more clever than that.

Installing it

You need a Linux server with root or sudo, inbound access to TCP 9090 (Cockpit's
web port) from wherever you browse, and a browser. On a cloud instance, open 9090
in the security group to your own IP only, not the world.

There are two scripts. The first clones the repo and installs the prerequisites,
detecting your package manager along the way:

git clone https://github.com/enforza/enforza-cockpit.git
cd enforza-cockpit
sudo ./bootstrap.sh

That pulls in nftables, its JSON/Python bindings (so the GUI can read and write the
ruleset programmatically), ulogd2 for userspace netfilter logging, and Cockpit
itself. It enables Cockpit's socket immediately, and enables the nftables service
but deliberately does not start it with an empty ruleset, so it cannot lock you out
before you have written a policy.

The second script installs the plugin into Cockpit:

sudo ./deploy.sh

That copies the built files into Cockpit's system package directory
(/usr/share/cockpit/enforza). Browse to https://<your-host>:9090, accept the
self-signed certificate warning on a fresh install, and log in with a local system
account that can use sudo. The firewall plugin needs administrative privilege, so
if Cockpit shows a "Limited access" banner, click it and re-authenticate. The
plugin then appears as Firewall (enforza) in the left-hand menu.

The three chains, in plain terms

The reason a GUI over nftables is useful is that the mental model is simple once
someone lays it out. enforza-cockpit gives you three rule sections, and each maps
directly to one of nftables' filter hooks:

Tab	nftables hook	What it controls
Management	`input`	Traffic to the box itself: SSH, the Cockpit port, health checks.
Network	`forward`	Traffic passing through the box between other hosts and the internet.
Local	`output`	Traffic originating from the box: updates, DNS, outbound calls.

Each section has a default action (accept or drop). First match wins; anything a
rule does not catch falls through to the default. There is also an Objects tab
for reusable named network (CIDR) and port sets: define home-lan, mgmt, web
once and reference them as @home-lan, @web and so on across any rule. Edit the
object and every rule using it updates, which is the same reason you use named sets
in a hand-written ruleset, minus the typing.

If you have ever stared at input, forward and output in the docs and not
been quite sure which one your rule belonged in, seeing them as three labelled
tabs is most of the value on its own.

Building a first policy

The safe first policy is a locked-down Management section: allow SSH and the
Cockpit port from your own address, drop everything else. In the Management tab,
set the default action to drop, then add a rule:

Action accept, Protocol tcp, Destination port 22
Source your admin IP or CIDR (or any to start with)
Tick Log matches, which is what puts the rule in your syslog
Comment SSH from admin, which is included in the log line, so make it mean something

Add a second rule the same way for TCP 9090 so you keep the Cockpit UI. And heed
the obvious warning: allow SSH and Cockpit from your own IP before you apply a
default-drop policy, or you will be relying on the auto-revert to get back in.

Then the apply flow, which is the part that makes this safe to do on a box you care
about:

Preview renders the policy to nftables JSON and dry-runs it against the kernel. A green "Valid" means the kernel accepts it.
Apply puts it live and starts a confirm-or-revert banner with a 60-second countdown.
Verify you still have access. Open a fresh SSH session, or just check the Cockpit page still responds.
Confirm to keep the ruleset. Do nothing and it auto-reverts to the previous one; there is also a Revert now button.
Save persists the policy document to /etc/enforza/policy.json so it reloads next time.

Your rules are now live in the inet enforza nftables table, and you can always
check what actually landed from a shell with sudo nft list table inet enforza.
The GUI is a front end; the kernel state is the truth, and nothing stops you
reading it directly.

Turning it into a router and NAT gateway

The Network tab (the forward path) is where the box stops being just a host
firewall and becomes a gateway. Turn on Enable routing to switch on IP
forwarding, then add a Network rule and mark it SNAT. That masquerades outbound
traffic from the hosts behind the box out through its public interface, so a single
Linux instance becomes the edge gateway for a whole segment: a lab network, a set
of VMs, or the machines on a home LAN. Network rules can carry both a LOG flag
and the SNAT flag, so you can log and source-NAT the same traffic, and
reference @objects for source, destination and ports to keep the rules readable.

That is the same job a small cloud NAT instance does, on hardware you already have.

Watching the logs

Any rule with Log matches ticked emits a kernel log line each time it matches,
and enforza-cockpit tags every line with three useful things: the section
(to-firewall, through-firewall or from-firewall), a plain verdict word
(ALLOW, DENY or REJECT), and your rule's comment. So a matched SSH accept
reads like:

kernel: enforza to-firewall ALLOW: SSH from admin IN=eth0 ... SRC=203.0.113.10 DPT=22 ...

Because the verdict is a plain word, grep does the rest:

sudo tail -f /var/log/syslog | grep 'enforza.*DENY'   # only denials
sudo tail -f /var/log/syslog | grep 'SSH from admin'  # one rule, by its comment

On distributions without /var/log/syslog (many dnf-based ones), read the kernel
log through the journal instead with sudo journalctl -kf | grep enforza.

One gotcha worth internalising, because it catches everyone once: a section's
default drop is not logged. If you want to see what is being denied, add an
explicit last rule with Action drop (or reject), Source any and
Log matches ticked, and make sure it sits at the bottom of the list. First
match wins, so a logging catch-all only works as the final rule.

What it isn't

Since being honest about limits is more useful than a feature list, here is what
enforza-cockpit does not do:

No application-layer filtering. It is plain nftables: L3/L4 rules plus SNAT. There is no FQDN or hostname filtering, no SNI inspection, no L7 anything. If you need to allow github.com but not the rest of the internet, this is not the tool.
One host, not a fleet. It manages the box it runs on. There is no central console, no pushing one policy to many machines, and no policy-as-code pipeline. For a homelab that is exactly right; for fifty boxes it is fifty logins.
A static ruleset. The kernel enforces the rules you compiled. It does not learn, score, or adapt, and it does not pretend to.

None of that is a criticism. It is a small, sharp tool that does one job well, and
knowing the edges is what lets you use it confidently.

Who makes it

enforza-cockpit is a free, MIT-licensed community tool from the people behind
enforza, a managed cloud-firewall platform. It needs no
account and no cloud connection, the code is open so you can read exactly what it
does to your box, and contributions and bug reports are welcome. That is the whole
disclosure. Go build a firewall.

FAQ

Frequently asked questions

Is enforza-cockpit really free?

Yes. It is MIT-licensed and open source, needs no account, no cloud connection and no subscription, and all firewall state stays on your machine. The repo is github.com/enforza/enforza-cockpit.

What is it built on?

It is a plugin for Cockpit, the web console that ships with most Linux distributions. The GUI renders your policy to a live nftables ruleset (in a table called inet enforza) and lets the kernel do the enforcing. A bootstrap script installs nftables, its JSON/Python bindings, ulogd2 for logging, and Cockpit itself.

Which Linux distributions does it support?

Debian and Ubuntu, Fedora, RHEL/Rocky/Alma, and openSUSE. The bootstrap script detects your package manager (apt, dnf, yum or zypper) so the same steps work across the common homelab and small-cloud distributions.

Can a bad rule lock me out of the box?

It is designed so it cannot, permanently. Every apply uses a confirm-or-revert model: after you click Apply you have 60 seconds to click Confirm, and if you do not, the previous ruleset is automatically restored. Keep a second way onto the box handy the first few times anyway. If you ever do get stuck, get on out-of-band and run nft flush ruleset or nft delete table inet enforza.

Does it do FQDN or application-layer filtering?

No, and it is worth being clear about that. It is a GUI over plain nftables: L3/L4 rules on the three chains (traffic to, through and from the host) plus SNAT. There is no FQDN, SNI or other L7 filtering, and it manages one host, not a fleet. If that is what you need, this is not the tool.

Can it act as a router and NAT gateway?

Yes. Turn on Enable routing (IP forwarding) and the box routes between its interfaces; mark a Network rule SNAT and it masquerades outbound traffic, so it works as an edge gateway for the machines behind it. That is the homelab use case it is happiest in.