A next-generation firewall (NGFW) is built to inspect traffic closely, not to absorb floods, so a large volumetric DDoS attack can overwhelm it long before the internet link is full. The reliable design is layered: an upstream DDoS mitigation service or network absorbs the flood, and the NGFW behind it does the deep inspection it was built for. This guide explains why NGFWs struggle under DDoS and how to test your own firewall’s limits safely, without relying on vendor marketing figures.
What an NGFW does well
An NGFW combines a traditional stateful firewall with deeper inspection:
- Application awareness: identifying applications regardless of port.
- Intrusion prevention (IPS): matching traffic against signatures of known attacks.
- Malware and URL filtering: blocking known-bad files and destinations.
- TLS inspection: decrypting traffic to inspect it, where policy allows.
- User and group policies: rules based on who is connecting, not only on IP address.
All of this costs CPU and memory for every connection. That is the trade-off that matters under attack.
Why DDoS attacks hurt firewalls
State table exhaustion
A stateful firewall keeps an entry for every connection it tracks. Floods of new connections, such as TCP SYN floods or high-rate UDP traffic with many source addresses, can fill the state table. Once it is full, legitimate new connections are dropped even if the link still has spare capacity.
CPU exhaustion
Deep inspection is expensive. When the packet rate rises sharply, the inspection engines can saturate the CPU. Depending on configuration, the device may start dropping traffic, bypass some inspection, or become unstable.
Link saturation upstream
If an attack is larger than your internet connection, no device on your premises can help, because the link is full before traffic reaches it. Only mitigation upstream, at your provider or a DDoS protection network, can deal with that.
Datasheet numbers versus real traffic
Vendor throughput figures are measured under specific test conditions, often with particular packet sizes, traffic mixes and features enabled or disabled. Figures with every inspection feature turned on are usually much lower than headline firewall throughput. Treat datasheet numbers as a starting point and test with your own configuration.
How to test your firewall’s limits safely
Stress testing is only appropriate on equipment and networks you own or are explicitly authorised to test, ideally in a lab or a maintenance window. Never point attack traffic at third-party systems or across a provider’s network without written permission, and tell your internet provider before any test that crosses their network.
1. Build a representative lab
Use the same model or virtual appliance, the same software version and the same security profile as production, with all the inspection features you actually use enabled. Place a traffic generator on each side of the firewall and a simple server farm behind it.
2. Measure a baseline
Send only realistic legitimate traffic, such as web and API requests at your expected peak, and record:
- Goodput: how much legitimate traffic gets through.
- Latency: round-trip time for a typical request.
- New connections per second and concurrent sessions.
- CPU and memory use on the firewall.
3. Add attack traffic in steps
Keep legitimate traffic running and add attack-style traffic gradually: a UDP flood, a SYN flood, then a high rate of small HTTP requests. Increase each in steps rather than jumping to the maximum, so you can see where performance starts to bend.
4. Record the breaking point
For each step, record goodput, latency, dropped sessions, CPU and whether inspection features stayed active. The useful result is not a single number but the point at which legitimate users would notice, and how the device behaves beyond it.
5. Test your protections
Repeat with your mitigation settings enabled, such as SYN cookies, connection-rate limits and flood thresholds, to see how much headroom they add. Then document the limits and decide what must sit in front of the firewall.
A layered design that holds up
- Upstream mitigation absorbs volumetric floods before they reach your link, through your provider or a DDoS protection network.
- A reverse proxy or CDN in front of websites, such as Cloudflare, filters attack traffic at the edge and hides the origin server’s address.
- The NGFW enforces policy and inspects the traffic that remains.
- Rate limiting and caching at the application reduce the cost of each request.
- Monitoring and a response plan so someone acts when an attack begins.
How Tremhost can help
Tremhost is a Cloudflare partner, and Cloudflare has a data centre in Harare. For websites, Armor Guard provides Cloudflare Pro for $9 a month and Armor Shield provides Cloudflare Business for $200 a month, configured and monitored by Tremhost. For multi-site organisations, Armor Network joins branches and remote staff to one Cloudflare network with one rule set, from $9 a person a month with a ten-person minimum. Managed security plans, from $200 a month, cover firewall, DDoS protection, malware removal and email filtering with monthly reporting.
Frequently asked questions
Can an NGFW stop a DDoS attack on its own?
It can handle small attacks and application-layer abuse, but large volumetric attacks need mitigation upstream.
Is it legal to run a DDoS test?
Only against systems you own or are authorised in writing to test, and with your network provider informed. Testing anyone else’s systems can be a crime.
What should I measure first?
Legitimate goodput and latency at your normal peak, with all inspection features on. Every later result is compared with that baseline.
Next step
To put DDoS protection in front of your website or network, see Tremhost Armor, or ask on WhatsApp on +263 73 563 9917, Monday to Friday, 08:00 to 17:00 CAT.
