Firewall rules that quietly stop working

A firewall policy is not a static document. It describes a network that keeps changing underneath it, and the rules that cause trouble are rarely the wrong ones — they are the ones that were right on the day they were written. Here are the five we see most.

1. The address object nobody decommissioned

An object called FINANCE-SRV points at an address whose server was retired two years ago. The rule that allows the internet to reach it on 443 is still there. It matches nothing, so nobody notices — until DHCP hands that address to a visitor's laptop, or a new appliance is given it by hand because it was "free".

Audit address objects quarterly against what actually answers. Prefer FQDN objects where the platform supports them; a name that stops resolving is a rule that stops matching, which is the safe direction.

2. "Temporary" with no expiry

The rule added at 6pm so the vendor could finish the migration. It has a comment that says temp — remove Monday. It has been there since 2023. Most firewalls can put a schedule or an expiry on a rule; use it, and let the rule switch itself off rather than relying on a Monday that never came.

3. The any-any that was going to be tightened later

A new segment goes in, the application does not work, somebody adds segment → any, any service, allow to get it working, and the plan is to narrow it once the application's real ports are known. They are never written down, so it is never narrowed. Six months later that segment is the one with the least protection on the network, and it is usually the one holding the CCTV recorder or the building controller.

Narrow it the same day by reading the session log for that rule. The ports in use are all there.

4. Shadowed rules

A deny rule sits below an allow that already matches the same traffic. It looks correct on the screen. It never fires, because the allow above it wins first. Every platform has a rule-usage counter; a deny with zero hits since it was created is either shadowed or unnecessary, and either way it is not doing what its author thinks.

5. NAT that outlived the policy

The port forward for the old remote-desktop gateway is still in the NAT table after the gateway was replaced with a VPN. NAT and policy are two tables on most firewalls, and cleaning up one does not clean up the other. A forward with nothing behind it is harmless today and a straight path to whatever is given that address tomorrow.

The review that catches all five

Export the policy, sort by last-hit, and read the rules with no hits in ninety days. Read the objects with no rules referencing them. Read the NAT table against the policy. It takes an afternoon, it needs no tool the firewall does not already have, and it is the difference between a policy and a list of things that used to be true.