I have designed and built firewall estates on Cisco, Palo Alto, Fortinet and Check Point, and I work to the same model on all of them. This page shows how each platform handles a packet, how I keep rule bases clean, and how I find a drop fast.
Underneath the vendor names, every stateful firewall follows the same steps. The first packet of a flow takes the slow path through routing, policy and NAT (network address translation). Every later packet matches the session and takes the fast path. Step through one TCP (Transmission Control Protocol) connection. The model is the same on a Cisco ASA (Adaptive Security Appliance) or FTD (Secure Firewall Threat Defense), Palo Alto, FortiGate or Juniper SRX.
Swipe sideways to see the whole diagram.
A user's TCP SYN (synchronise), the first packet of a new connection, arrives on the inside interface. The interface decides the source zone, and early checks such as anti spoofing and DoS (denial of service) screens run here.
The firewall looks for an existing session with the same five values: source and destination IP (Internet Protocol) address, source and destination port, and protocol. There is none, so this packet takes the slow path.
A route lookup on the destination finds the egress interface, and so the destination zone. Where destination NAT applies, vendors do this step in different orders, which is the root of most vendor differences.
The rules for that zone pair are read top down and the first match wins. If nothing matches, the implicit deny at the end drops it. Here rule 12 allows HTTPS (secure web traffic) from inside to outside. I always add an explicit deny that logs.
The packet is allowed, so NAT is applied and a session is written with both the original and translated addresses. From now on the session, not the rule base, decides what happens to this flow.
On a next generation firewall (NGFW), inspection follows. The application is identified a few packets in, here as web traffic over TLS (Transport Layer Security), the rule is checked again with that knowledge, and IPS (intrusion prevention) and malware checks run on traffic that is allowed.
The server's reply matches the session, so NAT is reversed and it goes straight back to the client with no rule lookup. That is why return traffic needs no rule, and why a reply that arrives at a different firewall is dropped.
A FIN (finish) or reset ends the session, or an idle timer removes it. Idle timers vary by vendor: typically 30 to 60 minutes for TCP, and from a few seconds to a few minutes for UDP (User Datagram Protocol) and ICMP (Internet Control Message Protocol). Long lived database or BGP (Border Gateway Protocol) sessions may need a longer timer.
| Idea | Cisco ASA and FTD | Palo Alto | FortiGate | Juniper SRX | Check Point |
|---|---|---|---|---|---|
| Trust areas | Security levels (ASA), zones (FTD) | Zones | Interfaces or zones | Security zones | Network objects and topology |
| Virtual firewalls | Security contexts | Virtual systems (vsys) | VDOMs (virtual domains) | Logical and tenant systems | Virtual systems (VSX) |
| Central manager | Security Cloud Control or CSM (Cisco Security Manager) for ASA; FMC (Firewall Management Center) for FTD | Panorama | FortiManager | Security Director | Security Management Server |
| Change model | Immediate on ASA, deployed from FMC on FTD | Candidate, then commit | Immediate | Candidate, commit and rollback | Edit, then install policy |
The biggest difference between vendors is the order of NAT and the policy check, because it decides which address a rule must use. Pick a platform to see its path. Orange stages translate addresses; pink stages make the allow or deny decision.
Labels in the figure: ACL is an access control list, ARP the Address Resolution Protocol, and DNAT and SNAT are destination and source NAT. VIP is a virtual IP address, ALG an application layer gateway, DPI deep packet inspection and SMC the Forcepoint Security Management Center.
Swipe sideways to see the whole diagram.
Cisco ASA. Since software 8.3, destination NAT is reversed before the ACL check, so access lists use the real, inside address of a published server. NAT lives in one table read in three sections: manual NAT, then object NAT, then manual NAT placed after object NAT.
Cisco FTD (Secure Firewall Threat Defense). One image with two engines: Lina, the ASA derived engine for routing, state and NAT, and Snort for application control, intrusion and file checks. Prefilter rules sit at the top of the same Lina access list, checked after destination NAT is reversed, so they use real addresses too. Lina builds the translation and the connection before Snort gives its verdict. A drop can come from either engine, and the FMC events show which.
Palo Alto. The NAT rule is looked up early to find the post NAT zone, but applied on the way out. Security rules therefore use the original addresses with the post NAT destination zone. A published server's rule points at its public address with the DMZ (demilitarised zone) as the zone.
FortiGate. Destination NAT through a VIP (virtual IP) object happens before routing, and the policy names the VIP. Source NAT is applied per policy on the way out, or from a central SNAT table if central NAT mode is on. The policy ID appears in every log line.
Juniper SRX. Screens run first, then static and destination NAT, then the route lookup and the policy, which matches the translated destination and the original source. Source NAT comes last. It is the opposite habit to Palo Alto, which catches people moving between them.
Check Point. The rule base matches the original packet on the way in. Destination NAT happens on the client side by default and source NAT on the way out. SecureXL accelerates established flows, so debugging sometimes means turning acceleration off for one flow.
SonicWall. SonicWall publishes no detailed packet flow, so this order follows how its rules behave. The zone pair needs the egress zone, which comes from a route lookup on the translated address, while inbound rules for a published server reference the public address object. NAT policies sit in their own table, matched by priority. The Packet Monitor shows forwarded, consumed and dropped packets with the reason.
Forcepoint NGFW. Access rules are processed first and NAT rules after, so access rules use original addresses. For high assurance networks, Sidewinder proxies can terminate and rebuild a connection, checking the protocol strictly on the way. Policy is always edited in the SMC (Security Management Center) and installed to the engines.
| Platform | Policy model | NAT and the address a rule uses | High availability | Management | Proves a drop |
|---|---|---|---|---|---|
| Cisco ASA | Interface ACLs plus a global ACL, security levels 0 to 100 | Object and manual NAT; ACLs use the real address | Failover pair with failover and stateful links; clustering on larger models | CLI (command line), ASDM (Adaptive Security Device Manager) or Security Cloud Control | packet-tracer, capture with trace, show asp drop |
| Cisco FTD | Access control policy in layers: prefilter, access, intrusion, file | As ASA; the real address | High availability (HA) pair or cluster | FMC, FDM (Firewall Device Manager) or Security Cloud Control | packet-tracer with the Snort verdict, system support trace |
| Palo Alto | Zone based rules with App-ID and User-ID | NAT rules separate; original addresses, post NAT zone | HA1 and HA2 links for active and passive, HA3 for active and active | Panorama | test security-policy-match, show session all, global counters |
| FortiGate | Policy by interface or zone pair, with a policy ID | VIP for destination NAT; the policy names the VIP | FGCP (FortiGate Clustering Protocol) active and passive or active and active; session pickup off by default | FortiManager and FortiAnalyzer | diagnose debug flow, the sniffer |
| Juniper SRX | Zone pair policies, then global policies | Destination NAT first; translated destination, original source | Chassis cluster with control and fabric links | Security Director | show security match-policies, flow traceoptions |
| Check Point | Rule base in ordered and inline layers | Automatic or manual NAT; rules match the original packet | ClusterXL high availability or load sharing, with state sync | Security Management Server and SmartConsole | fw ctl zdebug + drop, fw monitor |
| SonicWall | Access rules per zone pair | Separate NAT table; inbound rules use the public address | Active and standby, stateful on supported models | Network Security Manager | Packet Monitor |
| Forcepoint NGFW | Access rules, then NAT rules, then inspection | Access rules use original addresses | Clusters with CVI (cluster virtual IP) and NDI (node dedicated IP) addresses | SMC | SMC logs, sg-status and other sg tools |
The model is the same everywhere, but each platform has its own habits and its own best tool for proving what happened. These are the facts and commands I reach for first. The addresses are examples.
same-security-traffic permit inter-interface. Once an ACL is applied, it decides.show nat detail shows the section and the hits.object-group-search access-control saves the memory on large rule bases.| Task | Command |
|---|---|
| Simulate a flow | packet-tracer input inside tcp 10.1.1.20 50000 203.0.113.10 443 detailed |
| Capture with the decision | capture CAPIN interface inside trace match ip host 10.1.1.20 host 203.0.113.10 |
| Drop reasons | show asp drop and capture ASP type asp-drop all |
| Sessions and NAT | show conn address 10.1.1.20, show xlate |
| Failover | show failover, show failover history |
| Image check | verify /sha-512 disk0:/IMAGE.SPA |
| Task | Command |
|---|---|
| Simulate a flow, with the Snort verdict | packet-tracer input inside tcp 10.1.1.20 50000 203.0.113.10 443 detailed |
| Trace live traffic through both engines | system support trace |
| Watch the access control decision | system support firewall-engine-debug |
| Deployed policy | show running-config access-group |
| Task | Command |
|---|---|
| Which rule a flow hits | test security-policy-match from trust to untrust source 10.1.1.20 destination 203.0.113.10 destination-port 443 protocol 6 |
| Which NAT rule applies | test nat-policy-match with the same values |
| Live sessions | show session all filter source 10.1.1.20 |
| Drop counters | show counter global filter delta yes packet-filter yes |
| Why a session ended | Traffic log session end reason, such as policy-deny, aged-out or tcp-rst-from-server |
| Did the push finish | show jobs all |
| HA state | show high-availability state |
| Task | Command |
|---|---|
| Trace a flow | diagnose debug flow filter addr 10.1.1.20, diagnose debug flow trace start 20, diagnose debug enable |
| Stop the trace | diagnose debug disable and diagnose debug reset |
| Sniff packets | diagnose sniffer packet any "host 10.1.1.20" 4 0 l |
| Sessions | diagnose sys session filter src 10.1.1.20, then diagnose sys session list |
| HA health | get system ha status, diagnose sys ha checksum cluster |
host-inbound-traffic on the zone or interface, a common reason management stops working.commit check validates and commit confirmed 5 rolls back automatically unless I confirm.| Task | Command |
|---|---|
| Which policy a flow hits | show security match-policies from-zone trust to-zone untrust source-ip 10.1.1.20 destination-ip 203.0.113.10 source-port 50000 destination-port 443 protocol tcp |
| Unused and shadowed policies | show security policies hit-count, show security shadow-policies |
| Sessions | show security flow session source-prefix 10.1.1.20 |
| Trace drops | set security flow traceoptions with a packet filter, then show log |
| Cluster | show chassis cluster status |
| Task | Command |
|---|---|
| See drops and the reason | fw ctl zdebug + drop, filtered to the host |
| Watch a flow at each inspection point | fw monitor -e "accept host(10.1.1.20);" |
| Cluster state | cphaprob state |
| Live performance | cpview |
| VPN (virtual private network) tunnels | vpn tu |
| Task | Tool |
|---|---|
| Capture with the drop reason | Packet Monitor |
| Current connections and the rule in use | Connection monitor |
| Denies, VPN events and admin logins | Event logs, sent to the SIEM (security information and event management) |
| Support bundle | Tech support report |
acat. Control Center manages policy across many Sidewinders, the same role as Panorama or FMC.| Task | Command or tool |
|---|---|
| Which rule allowed or discarded a flow | The SMC logs view, filtered by source, destination and service |
| Engine state and version | sg-status, sg-version |
| Cluster node state | sg-cluster |
| Reconnect an engine to the SMC | sg-contact-mgmt |
| Sidewinder audit, live | acat -k |
Most firewall NAT comes down to three jobs: letting many users share one public address with PAT (port address translation), publishing a server, and leaving VPN traffic untranslated. Switch between them and watch the translation table.
Swipe sideways to see the whole diagram.
Port address translation. Inside users share one public address and the firewall tells them apart by source port. One address gives roughly 64,000 ports per destination, so very large sites use a small pool instead.
Publishing a server. Static NAT maps a public address and port to the server's private address in the DMZ. The security rule then has to name either the public or the private address, depending on the vendor's order. That is where most published server faults come from.
VPN exemption. Traffic to the branch must keep its real addresses so it matches the VPN's traffic selectors. Identity NAT, or a no NAT rule, sits above the internet PAT rule. If it is missing, the traffic is translated and never enters the tunnel.
| Platform | Destination in the security rule | Why |
|---|---|---|
| Cisco ASA and FTD | The real, private address | Destination NAT is reversed before the ACL check |
| Palo Alto | The public address, with the DMZ as destination zone | Rules use original addresses and the post NAT zone |
| FortiGate | The VIP object | The VIP carries both addresses in the default NAT mode |
| Juniper SRX | The real, private address | Destination NAT runs before the policy |
| Check Point | The public address, or the object with automatic NAT | The rule base matches the original packet |
| SonicWall and Forcepoint | The public address | Access rules are matched on original addresses |
Inside users who reach a published server by its public address need hairpin NAT. It translates the source as well as the destination, so replies come back through the firewall. An ASA also needs same-security-traffic permit intra-interface. Split DNS (Domain Name System), which gives inside users the private address, is usually cleaner.
Active FTP (File Transfer Protocol), SIP (Session Initiation Protocol) and H.323 carry addresses inside the payload or open extra connections. An ALG (application layer gateway) reads the control channel, opens a pinhole for the data and rewrites embedded addresses. When control works but data or media fails, such as one way audio, I check the ALG first and tune it for that flow only.
ASA inspections: show service-policy. SRX: show security alg status. FortiGate session helpers: show system session-helper. Palo Alto uses App-ID decoders. Encrypted control traffic, such as SIP over TLS, hides the addresses from every ALG.
Every boundary I design has a firewall pair or cluster. What matters is how they share sessions, how they fail over, and what happens when traffic takes a different path back. Compare the four situations.
Swipe sideways to see the whole diagram.
Active and standby. The units share configuration over one link and session state over another, so the standby always knows every connection. Both units must match: model, software, licences and monitored interfaces.
Failover. A failed unit, link or path monitor triggers the standby to take over the shared addresses and virtual MACs. It sends gratuitous ARP so switches learn the new port. With state sync on, users see a pause, not a dropped session. I fix the cause before failing back, in a window.
Cluster. ASA and FTD clusters, Palo Alto active and active with its HA3 link, and Check Point load sharing all handle asymmetric traffic. One member owns each flow, and a packet that lands on another member is passed to the owner over the cluster link.
Split brain. If the HA links fail, both units can go active and the switches see the same addresses on two ports. I use two separate HA links, monitor them, and alert on any failover so this is caught at once.
| Platform | Links | Points I check | Health command |
|---|---|---|---|
| Cisco ASA | Failover link for hellos and config, stateful link for sessions | Active and active needs multiple context mode; use virtual MACs so a replaced unit keeps the MACs | show failover |
| Palo Alto | HA1 for control, HA2 for sessions, HA3 for packet forwarding in active and active | Preemption is off by default; add backup HA1 and HA2 links | show high-availability state |
| FortiGate | Two direct heartbeat links | Session pickup is off by default; group IDs must differ between clusters on one network | get system ha status |
| Juniper SRX | Control link and fabric link | Redundancy group 0 for the routing engine, groups 1 and up for traffic with reth interfaces | show chassis cluster status |
| Check Point | A dedicated sync network | ClusterXL high availability or load sharing, and which connections are synced | cphaprob state |
| Forcepoint | Heartbeat and sync over node addresses | CVI MAC mode against the switches; all nodes on the same policy | sg-cluster |
The real fix is symmetric routing, or a cluster that shares state across both paths. Where a path cannot be made symmetric, each vendor has a bypass: ASA TCP state bypass (set connection advanced-options tcp-state-bypass), Palo Alto asymmetric path bypass in a zone protection profile, FortiGate set asymroute enable, and SRX set security flow tcp-session no-syn-check.
Each one switches state checking off, so I use it only for a named flow, with security approval and a review date.
Firewalls rarely fail on day one. They decay: rules pile up, broad rules hide narrow ones, and nobody remembers why a rule exists. Step through how I find and fix that with evidence.
Swipe sideways to see the whole diagram.
Rules are read top down and the first match decides. Order is design: specific rules first, broader ones after, and an explicit deny that logs at the end of each section.
A user's flow to the finance database hits the broad rule 2 and is allowed. The deny in rule 3 can never fire, so it is shadowed. A shadowed deny under a broad allow is a real exposure, so I fix those first.
Hit counts and last hit dates, gathered over a full business cycle including month and year end, show which rules are used. Rule 4 duplicates rule 1 and has no hits. Counters reset on reload or failover, so I check how long they have run.
Every rule carries an owner, a reason, a change reference and a review date. Rule 2 has no owner and allows anything, so it goes to the security lead to justify or remove.
The deny moves up, the broad rule is narrowed to web browsing, and the duplicate is removed. Removal is in two steps: disable and watch the logs, then delete through change.
Pick a flow and see which rule decides it, top down. The services are HTTPS for web, SQL (Structured Query Language) for the database and SSH (Secure Shell) for remote logins. Then fix the order and run it again.
| # | Action | Source | Destination | Service |
|---|---|---|---|---|
| 1 | Allow | Users | Web servers | HTTPS |
| 2 | Allow | Users | Any | Any |
| 3 | Deny | Users | Finance database | Any |
| 4 | Allow | Users | Web servers | HTTPS |
| 5 | Deny | Any | Any | Any, and log |
With the original order, the finance database flow matches rule 2 and is allowed. Rule 3 never fires.
Most firewall outages are caused by a change. A good change is boring: assessed, tested before and after, approved by the CAB (change advisory board), and recorded in the CMDB (configuration management database). This is the path every rule request takes on the estates I design and support.
Swipe sideways to see the whole diagram.
A request names the requester, the owner and the application, and the exact flow: source, destination, protocol, ports, direction and any NAT. Vague requests such as "open the firewall for the new app" go back for detail.
I check least privilege, reuse existing objects, look for overlap and shadowing, and flag clear text protocols with a secure alternative. Rules that cross an accredited or regulated boundary need that boundary's approval.
Before anything changes, the vendor's policy match tool shows what happens today with the real values. That baseline proves later that the change did what it should.
The change board approves it with a window, an implementer, a checker and a backout plan. Emergency changes follow the same checks, faster, and are reviewed afterwards.
The change is made in the central manager, previewed and validated, then committed, pushed or installed. Panorama pushes and policy installs are jobs, so I check they finished.
The same test now matches the new rule, the hit counter rises, the user confirms, and the logs show nothing unexpected being denied.
The change closes with its evidence, the rule register and CMDB (configuration management database) are updated, and any temporary rule gets an expiry date.
Firewall and VPN gateways face the internet, so attackers hunt for their flaws. Public examples carry CVE (Common Vulnerabilities and Exposures) numbers. They include the PAN-OS GlobalProtect flaw CVE-2024-3400 in April 2024, and the Cisco ASA and FTD VPN web server flaws CVE-2025-20333 and CVE-2025-20362 in September 2025, which led to a US emergency directive. SonicWall's CVE-2024-40766 and the FortiCloud single sign on bypass CVE-2026-24858 followed the same pattern.
My response is the same each time. I confirm whether the vulnerable feature is exposed and check for signs of compromise before patching, because patching removes evidence. Then I apply the fix or the vendor's mitigation, and rotate credentials and review admin activity if there is any doubt.
A vendor change is the best chance to clean a rule base, and the easiest way to break one. Conversion tools do the bulk of the typing, but they copy mistakes as faithfully as good rules. This is the order I work in.
Swipe sideways to see the whole diagram.
I export the rules, objects, NAT, VPNs and routes, with hit counts and logs over a full business cycle, and match each rule to an owner.
Unused, shadowed, duplicate and ownerless rules are removed on the old firewall first, through normal change. Migrating fewer rules means less to convert, less to test and less to get wrong.
A migration tool converts objects, rules and NAT. Cisco's Secure Firewall Migration Tool takes ASA, Check Point, Palo Alto and Fortinet rule bases to FTD, and Fortinet's FortiConverter targets FortiGate. Palo Alto's Expedition tool reached end of life at the end of 2024. Every tool's output gets a human review.
Rules are rewritten for the new vendor's NAT order, port based rules move to application based ones where the platform supports it, and inspection profiles are attached.
Key flows are replayed through both firewalls' policy match tools and the results compared. Failover, VPNs and logging are tested before any traffic moves.
Traffic moves zone by zone or VLAN (virtual local area network) by VLAN in agreed windows. The old pair stays powered and configured until the last zone has run cleanly through a business cycle.
When users say "the firewall is blocking it", I check four things in order: did the packet arrive, what did the firewall decide, did it leave, and did the reply come back? Captures on both sides settle it quickly.
Swipe sideways to see the whole diagram.
I capture on the ingress interface with a tight filter. An empty capture rules the firewall out: the problem is the client, the switch, routing or another device before it.
The firewall's own tool replays or traces the flow and names the rule, the NAT and the drop reason: packet-tracer on ASA and FTD, test security-policy-match on Palo Alto, diagnose debug flow on FortiGate, flow traceoptions on SRX and fw ctl zdebug + drop on Check Point.
A capture on the egress side, filtered on the translated address, proves the packet left. Captures by stage on Palo Alto show receive, firewall, transmit and drop in one go.
If the packet leaves but nothing returns, the fault is beyond the firewall: the next hop, the return route or the server itself. Evidence from both captures saves a long argument.
A session with bytes out and none back, or replies dropped as "not part of a session", means the reply came back another way. I fix the routing so both directions use the same firewall.
Likely causes: a deny above it, or the rule placed at the bottom; the wrong zone pair, because routing decides the egress zone; the wrong address for the vendor's NAT order. Also check for an object typo or wrong port, an App-ID that differs from the rule, and a commit, push or install that never finished.
packet-tracer input inside tcp 10.1.1.20 50000 203.0.113.10 443 detailed, then show running-config access-group to check the ACL is applied.test security-policy-match from trust to untrust source 10.1.1.20 destination 203.0.113.10 destination-port 443 protocol 6, and show jobs all to confirm the push.diagnose debug flow with a filter on the host. "Denied by forward policy check (policy 0)" means the implicit deny.show security match-policies with the real values, and show security policies hit-count.fw ctl zdebug + drop filtered to the host, and check the policy installed without errors.Likely causes: the reply returns through another firewall, or NAT is not reversed or not routed back. Other causes are a server with two network cards answering from the wrong one, reverse path checks, or an HSRP (Hot Standby Router Protocol) active router on one side and the active firewall on the other.
show conn address 10.1.1.20 detail and show asp drop, looking for tcp-not-syn or rpf-violated.show session all filter source 10.1.1.20: bytes in one direction only.diagnose sys session list after a filter; "reverse path check fail" in debug flow.show security flow session source-prefix 10.1.1.20: packets on the in leg, none on the out leg.fw monitor on the host to see which inspection points the reply reaches.Reading the counters: if neither side's counters move, check routing, NAT exemption and traffic selectors. If my encrypt rises and their decrypt stays flat, ESP (Encapsulating Security Payload) or UDP 4500 is blocked between us. If both sides encrypt but my decrypt stays flat, their packets are not reaching me: I check ESP or UDP 4500 on the path towards me, then their SA (security association) and routing. If small packets work and large ones fail, it is the MTU (maximum transmission unit).
show crypto ipsec sa peer 203.0.113.1 for encaps and decaps, and show nat detail for the exemption.show vpn ipsec-sa, and check proxy IDs match a policy based peer exactly.diagnose vpn tunnel list name TO_BRANCH for selectors and encrypt and decrypt counters.show security ipsec security-associations and show security ipsec statistics.vpn tu to list and reset tunnels, with the VPN logs in SmartConsole.Likely causes: a tunnel or overlay lowers the MTU and the ICMP "fragmentation needed" message is blocked, so path MTU discovery fails. Test with ping -f -l 1472 on Windows or ping -M do -s 1472 on Linux, then step down. The fix is to allow that ICMP and clamp the TCP MSS (maximum segment size).
sysopt connection tcpmss 1380 (the default) and show asp drop.set tcp-mss-sender 1360 and set tcp-mss-receiver 1360 in the policy.set security flow tcp-mss ipsec-vpn mss 1350fw monitor on both sides to see whether the large packets leave and come back.Likely causes: state sync off or failing, so sessions were not copied; switches still sending to the old unit's port; a flapping monitored link; both units active; configuration or software out of step.
show failover and show failover history for the reason and the stateful counters.show high-availability state and show high-availability state-synchronization.get system ha status and diagnose sys ha checksum cluster; check session pickup is on.show chassis cluster status and show chassis cluster statistics.cphaprob state and cphaprob -a if.Likely causes: the rule names the wrong address for the vendor's NAT order; the NAT rule is shadowed by another; nothing answers ARP for the public address; the server's default route does not point back through the firewall.
packet-tracer input outside tcp 203.0.113.50 50000 198.51.100.10 443 detailed; the ACL must use the real address.test nat-policy-match; the security rule uses the public address with the DMZ zone.show security nat destination rule all, and add security nat proxy-arp for the public address.fw ctl zdebug + drop.Firewall work is rarely a fresh build. It is usually a refresh, a consolidation or a vendor change on a live estate. I run it the same way each time: agree the outcome, prove the current rule base with data, design the target policy, test it, and hand over an estate that stays clean.
Swipe sideways to see the whole diagram.
I agree what the programme is for: retiring end of life kit, consolidating vendors, adding inspection or closing an audit finding. I name the risk owner for each boundary, because they approve the rules that cross it, and set up a RACI (responsible, accountable, consulted, informed).
Functional requirements cover zones, VPNs, inspection and identity. Non functional ones cover throughput with threat features and TLS decryption on, session counts, failover time, log retention and change windows, each with a number that can be tested.
I export the rule base, hit counts and logs over a full business cycle, then run them through analysis tools to find unused, shadowed and overly broad rules. Every rule that stays needs an owner who can say why it exists.
I design the zone model, the rule and naming standard, NAT and VPNs, HA and the management platform. When the vendor changes, I rewrite rules for the new vendor's NAT order rather than copying them across line by line.
I build the new pair, test failover and throughput, and replay the important flows through the vendor's policy match tools. Cut over goes zone by zone or VLAN by VLAN, with the old pair kept ready to take traffic back.
Operations get runbooks for common faults, alerts on HA state, sessions and resources, logs in the SIEM, and a change process that checks every request for least privilege, shadowing and NAT impact before it is approved.
Edge firewalls are a favourite target, so I track each vendor's advisories and support dates, upgrade HA pairs one unit at a time, recertify rules on a fixed cycle and plan hardware refresh before end of support.
What it must do.
How well it must do it, with a number wherever one can be agreed.
These are typical starting targets for a firewall refresh. Datasheet throughput is often measured with features off, so I size from the vendor's threat protection and TLS decryption figures.
| Tool or source | What it tells me |
|---|---|
| Rule base exports and hit counts | Which rules are used, how often and when they were last hit. |
| Tufin, AlgoSec or FireMon | Shadowed, redundant and overly broad rules, and risky services. |
| Palo Alto Policy Optimizer | Port based rules that can move to application based rules. |
| SIEM and firewall logs | Real flows over time, including rare month end jobs. |
| Vendor sizing tools and datasheets | Throughput with threat inspection and TLS decryption turned on. |
| Packet captures | Proof of what really crosses a boundary when the logs are unclear. |
Every firewall fault comes down to four checks: did the packet arrive, what did the firewall decide, did it leave, and did the reply come back? I work through them in that order, with captures and the vendor's own tools.
| Layer | What I check |
|---|---|
| 1 · Physical | Interface errors, optics, HA links and the links the HA pair monitors. |
| 2 · Data link | VLANs and trunks, ARP for the next hop and for NAT addresses, virtual MAC ownership after a failover. |
| 3 · Network | Routing on both paths, the egress zone and NAT: show nat detail, test nat-policy-match. |
| 4 · Transport | The session and its state: show conn, show session all, diagnose sys session list, TCP flags and MSS. |
| 5 to 7 · Application | App-ID and decoders, IPS drops, TLS decryption, certificates and ALGs (application layer gateways). |
My general method, with worked faults, is on the troubleshooting page. The fault finder further up this page has the vendor commands.
A firewall estate decays without care: rules pile up and nobody remembers why. I build the habits into the support model from day one.
Every rule request is checked for least privilege, shadowing, NAT impact and an owner, then tested with the vendor's policy match tool before approval.
Alerts on HA state, processor load, memory, session counts and VPN tunnels, with every log in the SIEM.
Step by step guides for the common faults, for failover and failback, and for emergency blocks.
Owners confirm their rules on a fixed cycle. Unclaimed rules are disabled, then removed.
Configuration backed up off the device after every change, encrypted and restore tested.
A drop or failover that keeps coming back gets a root cause from captures and HA history, and a known error record the service desk can search.
Firewalls sit at the edge, so their software and hardware must stay current. I plan their whole life from the vendor's release and support dates.
I have designed and delivered firewall estates in industrial software, publishing and the public sector, and worked under strict change control in a regulated bank. I keep three vendors running side by side in my home lab.
My home lab runs a physical Cisco ASA alongside virtual Palo Alto and Check Point firewalls, so I can test policy and NAT on each before it goes near a live network.
Integrated a multi site estate after the merger on Cisco, Palo Alto and VMware, with warehouse automation segmented from the corporate network.
Modernised a council network across switching, wireless and firewalls, including FortiGate and Check Point, leading 7 engineers and third party suppliers.
Cloud, SDN (software defined networking), disaster recovery and security architecture for the firm's enterprise clients, on Nexus, Viptela, Palo Alto, F5 and Aruba.
Led network and security transformation through AVEVA's reverse merger, modernising every site worldwide remotely during the COVID lockdowns.
Delivered the EMEA (Europe, Middle East and Africa) network refresh with no service outages and MiFID II (Markets in Financial Instruments Directive) compliance kept throughout.
I work across Palo Alto, Check Point, Cisco Firepower, FortiGate, F5 and IPsec (IP security) VPN. I have passed the CCIE (Cisco Certified Internetwork Expert) Security written exam and hold the Cisco Certified Specialist Security Core certification. The security page shows how firewalls fit into my wider security designs.
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.