The firewall remembers the connections it has allowed, so it can recognise legitimate return traffic without a rule permitting it.

A stateless filter examines each packet alone, so allowing a reply requires a rule permitting inbound traffic on the relevant ports - broad, and easily abused.

A stateful firewall records each permitted connection in a table and matches subsequent packets against it. Return traffic belonging to an established connection is allowed because it belongs to that connection, not because a rule permits it independently. Traffic that claims to be a reply but matches no entry is dropped.

That is why policies can be written as outbound rules only, and why unsolicited inbound traffic is blocked by default.

Session table size is therefore a real capacity limit. When it fills, new connections fail while existing ones continue - a distinctive symptom worth recognising, since it presents as intermittent failure to connect rather than as an outage.

Review it on a schedule, document why each rule exists, order it deliberately, and remove what is unused - none of which happens without a process.

Every rule should have an owner, a reason and a date. A rule with a comment saying which change request created it can be assessed years later; one without cannot, and so it stays forever.

Most firewalls report per-rule hit counts. Rules with no hits over months are candidates for removal, and this single report is the most effective cleanup tool available.

Order matters for both correctness and performance - specific rules before general ones, and the busiest rules high where the platform evaluates sequentially.

Group objects and use named services rather than raw addresses, so that a change happens in one place.

Schedule a review at least annually, ideally tied to a change process that requires a removal date for temporary rules. Without that, a rulebase only ever grows, and its effective policy is whatever the broadest surviving rule permits.

Identifying traffic by what it actually is rather than by the port it uses - which is necessary because port numbers stopped being meaningful.

Historically a port implied an application. Now most traffic is on 443, including applications the organisation may not want, and blocking a port blocks everything or nothing.

An application-aware firewall examines the traffic and identifies the application by its behaviour and signature. Policy can then permit a business application while blocking file sharing on the same port, or allow a social platform in general while blocking file uploads.

Combined with user identity from the directory, rules become statements about people and applications, which are far easier to review than address lists.

The caveats: identification requires seeing enough of the session, so some decisions occur a few packets in; encrypted traffic limits what can be identified without decryption; and application databases need regular updates, which is a subscription. Accuracy also varies between vendors, particularly for less common applications.

Enough that each trust level is separate, plus room for the ones you have not thought of - and zones cost nothing while interfaces are finite.

A minimal deployment has inside, outside and a DMZ. That is rarely sufficient for long: guest wireless, building systems, cameras, operational technology, partner connections and management networks all warrant separation.

Most firewalls use zones rather than physical interfaces for policy, so a single physical link carrying tagged VLANs can present many zones. That is the usual arrangement and it scales well - but it makes the link a shared resource, so size it accordingly.

Physical separation is still worth using for genuinely distinct trust boundaries, particularly anything relating to operational technology or to a partner's network.

Plan for high availability interfaces and a dedicated management interface as well. Discovering that every port is used when the second unit arrives is a common and avoidable problem.

Connection logs for permitted and denied traffic, sent off the device, retained long enough to investigate - which is longer than the device can store.

Denied traffic shows what is being attempted. Permitted traffic shows what actually happened, and it is the permitted log that answers the questions asked during an incident: what did this host connect to, and when.

Volume is the constraint. Logging every permitted session at a busy boundary produces a great deal of data, so the usual approach is to log everything centrally with sufficient retention, rather than reducing what is logged.

On-device storage is small and wraps quickly, which is precisely why forwarding to a central collector matters. An investigation typically begins weeks after the event.

Ensure the time is synchronised and the timezone documented. Correlating firewall logs with other sources is the main analytical technique available, and it fails entirely if the clocks disagree.

Only where it sits between the parts of the network in question - and in most networks it does not.

A firewall at the internet boundary sees traffic leaving and entering. It sees nothing of a compromised workstation reaching a file server on the same network, or of movement between VLANs routed by a Layer 3 switch.

Since most incidents involve internal movement after an initial foothold, that is a significant gap. Closing it means placing enforcement between internal segments: routing sensitive VLANs through the firewall, deploying internal firewalls in front of data centre segments, or using host-based controls and micro-segmentation.

The practical starting point is to identify what must not be reachable from the general user network - domain controllers' management interfaces, backup infrastructure, operational technology - and put a boundary in front of those specifically.

That targeted approach delivers most of the benefit without the cost and disruption of inspecting all internal traffic.

In a high-availability pair, with a configuration backup, a tested rollback and a read of the release notes - and never during a period nobody can support.

With a pair, upgrade the standby, fail over, verify, then upgrade the former active. Traffic continues throughout, and if the new version misbehaves the pair can be reverted with one unit still on the old code.

Without a pair, the upgrade is an outage and needs a window, a full configuration export held off the device, and a documented method of reinstalling the previous version.

Release notes matter more on firewalls than on most equipment, because policy semantics occasionally change between versions - a default that was permissive becoming restrictive, or an option being retired. Those changes appear as connectivity failures immediately after an upgrade.

Check licence and subscription compatibility with the target version, and verify that the high-availability pair supports running mixed versions during the upgrade window - some do only for a limited time.