Firewall Troubleshooting
Firewall problems are unusually traceable, because the device logs every decision it makes. The habit worth building is checking the logs before forming a theory — most of the time the answer is a specific denied session with a rule number attached, and the whole investigation takes two minutes.
Do this first
- Check the logs for the specific traffic, filtered by source and destination.
- Ask what changed — a firmware update, a new rule, an expired subscription, or an enabled feature.
- Establish scope — one application, one user, one site, or everything.
- Check whether it is the firewall at all by testing from a position that bypasses it.
Start here
| Symptom | Most likely cause |
|---|---|
| One application broke after enabling inspection | TLS inspection and certificate pinning |
| Everything slowed down suddenly | Inspection feature enabled on an undersized device |
| A rule does not seem to apply | A broader rule higher in the list matches first |
| VPN tunnel drops periodically | Mismatched lifetimes or keepalive settings |
| Remote users connect but reach nothing | Split tunnel, routes, or policy for VPN clients |
| Inbound service unreachable from outside | NAT configured, policy missing, or vice versa |
| Works from inside, not from outside | Testing from within the network — a false result |
| Certificate warnings on every site | TLS inspection without the firewall's certificate deployed |
| Guest network reaching internal systems | Policy or VLAN misconfiguration |
| Security features silently stopped | Expired subscription |
| High CPU, sluggish management | Inspection load, or an attack in progress |
| Random sites blocked | Web filtering category, or a false positive |
An application broke after you turned on inspection
This is the most common post-deployment complaint and it usually has one cause.
- Check whether TLS inspection is applied to that traffic Applications using certificate pinning deliberately reject any intermediate certificate, including yours. They do not fail gracefully — they simply stop connecting.
- Add an exclusion for that destination Every deployment ends up with an exclusion list. Banking, payment, and some vendor applications are common entries.
- Check application control is not blocking it Application signatures update, and a newly recognised application may land in a blocked category it was not in last month.
- Check IPS is not matching a false positive The log names the signature. Legitimate applications occasionally trigger one, and the fix is an exception for that signature and destination rather than disabling IPS.
- Check web filtering categorisation Miscategorised sites happen. Most vendors accept recategorisation requests, and you can override locally in the meantime.
- Test by disabling one feature at a time In a controlled window. This identifies the responsible feature quickly rather than by argument.
When an application breaks under inspection, the fastest fix is switching the feature off — and the result is that a control you bought protects nothing, usually permanently, because nobody re-enables it. Add a narrow exclusion for that destination or signature instead. It takes a few more minutes and preserves the protection everywhere else.
Rules that do not do what you expected
Firewall rules evaluate top to bottom and the first match wins. Almost every "the rule is not working" report is really a rule ordering problem.
- Check what actually matched in the logs. The entry names the rule, which usually ends the discussion immediately.
- Look above your rule for something broader that matched first.
- Check the interfaces and zones, since a rule on the wrong interface pair never matches.
- Check the service definition. A rule permitting one protocol will not carry another that the application also needs.
- Check address objects resolve to what you think, particularly group objects edited over time.
- Confirm the rule is enabled, and that any schedule attached to it is currently active.
VPN problems
| Symptom | What to check |
|---|---|
| Site-to-site tunnel will not establish | Both ends must agree on encryption proposals, authentication, and identifiers. The logs will usually say which phase failed, which tells you which half of the configuration to look at. |
| Tunnel establishes then drops periodically | Mismatched key lifetimes at each end, or an idle timeout with no keepalive. Match the settings on both sides. |
| Tunnel up but no traffic passes | Policy or routing. A tunnel is not automatically permitted to carry traffic; there must be rules for it in both directions. |
| Overlapping subnets at each site | If both offices use the same address range, the tunnel cannot route between them. This needs renumbering or translation — plan around it early. |
| Remote users connect but reach nothing | Check the routes pushed to clients, the policy for the VPN address pool, and whether split tunnelling is sending traffic the way you intend. |
| Slow VPN throughput | Compare against the device's rated VPN throughput, which is separate from and lower than firewall throughput. |
Everything got slow
- Check what was enabled recently. Inspection features have a throughput cost, and a device that was comfortable can become the bottleneck the day TLS inspection is switched on.
- Check CPU and session counts on the firewall. Sustained high CPU under normal traffic means the device is undersized for its feature set.
- Test with a device outside the firewall if you can, to establish whether the internet link itself is the problem.
- Check for saturation — a backup or update rollout can fill a link entirely.
- Look for a session flood. Unusual session counts can indicate misbehaving software or an attack.
- Compare against the rated threat protection throughput rather than the headline figure — see firewall sizing.
Expired security subscriptions do not cause an outage. Traffic keeps flowing, rules keep applying, and the threat intelligence simply stops updating. If you cannot remember when the subscription was last renewed, check now — this is a failure with no symptom, which is precisely why it persists.
Testing properly
- Test inbound access from outside the network. A phone on mobile data works. Testing from inside gives a false result because internal traffic may never traverse the rule you are checking.
- Actively try to reach what should be blocked. Segmentation that has never been tested is an assumption.
- Use the firewall's own diagnostic tools. Most can trace how a given packet would be handled, which is faster and more definitive than trial and error.
- Check logs from both ends for VPN issues.
- Keep a configuration backup before changes, so reverting is quick when a change makes things worse.
When traffic is denied, the log records which policy denied it. That single field resolves most firewall investigations immediately and turns a debate about what should happen into a fact about what did. Filter the log by source and destination before theorising.
Official manufacturer resources
Diagnostic commands, log formats, and VPN parameter names are vendor-specific. Confirm against documentation for your exact model and firmware.
Something broke after a firewall change?
Tell us what changed, what stopped working, and what the log says. That combination usually identifies it immediately — and the fix is normally a narrow exclusion rather than turning a feature off.
Still stuck? Talk to someone who works on this hardware daily.
Tell us the model, what you have already tried, and what you are seeing. We will tell you whether it is a setting, a consumable, or a part — and we will say so if you do not need to buy anything.
