A firewall can slow your internet, but a correctly sized one usually adds delay you cannot feel. Slowdowns appear when the device runs out of CPU or memory, when deep inspection is enabled on weak hardware, or when rules are poorly ordered. Measure throughput and latency with and without it before changing policy.
What actually costs time inside a firewall?
Every packet is checked against policy, and how much work that takes depends on the type of firewall. NIST's guidelines on firewalls describe three broad techniques. Packet filtering looks at headers only. Stateful inspection also tracks each connection in a state table. Application proxies see the full application conversation, which NIST notes can add latency and is a question to ask when choosing one.
More awareness means more work per packet. The same NIST document says some firewalls require additional resources, particularly memory, for features such as reassembling fragmented traffic, and that running VPN functions on a firewall needs extra capacity depending on traffic volume.
Which settings make it slower?
- Deep inspection. Stateful protocol analysis, intrusion prevention and content scanning cost more than header checks.
- Encrypted traffic inspection. Decrypting and re-encrypting sessions is heavy work.
- Rule order. NIST notes that many firewalls check rules sequentially until a match, so placing the rules most likely to match near the top improves performance.
- Logging. Verbose logging to a slow destination can add overhead.
- Undersized hardware. A device bought for a 100 Mbps office will struggle when the link becomes 1 Gbps.
The guidance tells buyers to define throughput, maximum simultaneous connections, connections per second and latency requirements so the firewall does not become a bottleneck for current and future traffic.
Is the firewall really the problem?
Often it is not. Before blaming the firewall, rule out the usual suspects: Wi-Fi congestion, an oversubscribed internet link, DNS delay, a busy VPN concentrator or a slow server. A quick way to separate causes is to test the same path with the firewall bypassed in a controlled window, if your policy allows it, or to test against a local server on each side of the firewall to see what the device itself adds.
A constructed example
A small office upgrades to a faster fibre line and reports that the speed test shows a third of what they pay for. Their firewall, bought years ago, lists a throughput figure that applies to plain packet forwarding. With intrusion prevention and content scanning on, its realistic figure is lower. A check of the device shows CPU pegged during tests. The fix is either to turn off the heaviest inspection for trusted traffic with a documented exception, or to replace the unit with one rated for the real inspection workload. Both fixes keep a firewall in place. Removing it is not the answer.
How to check or apply this
- Run a baseline: measure throughput and latency to a nearby test server across the firewall, then compare with a direct test if you can.
- Watch CPU, memory and session counts on the firewall during the test.
- Read the vendor's throughput figures by feature set. Figures with inspection enabled are the ones that matter.
- Move high-hit rules to the top and remove dead rules.
- Review which traffic really needs deep inspection and which can use simpler checks.
- Plan capacity for growth, including VPN users and encrypted traffic share.
- Test before and after every change, using traffic that resembles real use.
Quick check
Does a software firewall on my laptop slow my connection?
Usually not noticeably. A host firewall competes for the laptop's own CPU, so the effect shows up only on very fast links or old machines.
Is it safe to turn the firewall off to test speed?
Only briefly, in a controlled setup, and only if your security policy allows it. A safer test is to compare against a path that crosses a second device.
Sources
Last reviewed: 18 October 2026.
