Neurowall's packet filter runs in one of four modes — Legacy, Prefilter, DDoS Inline, and DDoS Only — each built from the same underlying filter engine, each striking a different balance between throughput and how much protection runs on every packet. Switching between them is a config-driven API call, not a redeploy.
Most firewalls run one monolithic packet-processing path regardless of what a given deployment actually requires. A pure-passthrough edge node pays the same per-packet cost as a fully-loaded gateway running DDoS mitigation and a large ruleset — CPU spent evaluating stages that were always going to pass. Neurowall's data plane runs in one of four modes precisely so that cost is proportional to what's actually enabled.
Rule evaluation and DDoS flood-gate checks both consume CPU cycles per packet, even when they ultimately pass everything through — capacity that's wasted if the deployment doesn't need those stages.
A mobile game backend, a competitive FPS matchmaking server, and an internal segmentation gateway have genuinely different requirements — one fixed pipeline either under-protects some or over-costs others.
For sub-millisecond workloads like game servers, skipping a stage that isn't needed is measurable — see the per-mode numbers on the Game Server Benchmarks page.
A gateway's requirements change — a new DDoS campaign, a new compliance rule set. Modes can be switched live via the API without restarting the packet filter or dropping traffic.
Every mode shares the same allow/ban check as its first step. What differs is whether DDoS flood-gate logic and custom rule evaluation run after it, and how those two stages are wired together.
Runs the same allow/ban check, DDoS flood gates, and custom rules as the default mode, but through an older, monolithic code path instead of the current staged design. Kept as a compatibility fallback — use it only if you have a specific reason to run the older code path; new deployments should use one of the other three modes.
The lightest mode. Runs only the allow/ban check — no DDoS flood-gate evaluation, no custom rule matching. Every packet that isn't explicitly banned passes straight through. Best for pure-passthrough or bandwidth-bound edges where DDoS heuristics and custom policy aren't the priority for that interface.
Runs the allow/ban check, then evaluates your custom rule set first. DDoS flood-gate logic runs inline as a fallback only when a packet doesn't match any custom rule — so explicit policy is always the primary gate, and DDoS detection catches whatever your rules didn't already decide.
The most stripped-down mode: DDoS flood-gate checks run, but the allow/ban check and custom rule evaluation are both skipped. Because there's no rule stage to decide traffic, this mode requires the interface's default action to be set to allow — a guard against silently ending up in an unexpectedly restrictive posture.
In Legacy, Prefilter, and DDoS Inline mode, banning a source IP — whether from a manual block, a threat-intel feed match, or a DDoS-triggered promotion — is enforced by the allow/ban check that runs as the very first step. DDoS Only is the one exception: it skips that check entirely, so bans don't apply on an interface running DDoS Only.
| Mode | Do manual/threat-feed bans enforce? |
|---|---|
| Legacy | Yes — allow/ban check runs before anything else |
| Prefilter | Yes — it's the only check this mode runs |
| DDoS Inline | Yes — runs before rules and before the DDoS fallback |
| DDoS Only | No — this mode skips the allow/ban check by design; only DDoS flood gates apply |
The practical implication: choosing Prefilter for throughput doesn't leave you exposed to already-known bad actors — your ban list still enforces. Choosing DDoS Only trades that away deliberately, in exchange for the lowest possible per-packet cost on an interface that's meant to do nothing but absorb floods.
DDoS protection in Neurowall is enforced in the fast packet-filtering layer, not in the connection-limiting layer. That means DDoS thresholds and settings are only acted on by Legacy, DDoS Inline, and DDoS Only — turning on DDoS settings for an interface running Prefilter mode is accepted but has nothing to execute against.
DDoS configuration — thresholds, enabled flood types — can be overridden per interface, including which mode that interface runs, without touching global defaults.
Legacy, DDoS Inline, and DDoS Only all gate SYN/ACK/ICMP/FIN/RST floods at the network level — see DDoS Threat Detection for how that engine works. Prefilter is the only mode without it.
Because DDoS Only has no rules stage to fall back on, it's only permitted when the interface's default action is allow — a guard against silently ending up in a fully-open or fully-closed state.
Per-IP connection limiting operates independently of which mode is loaded — it's a different enforcement layer from the flood-gate checks described here.
| Mode | Allow/Ban Check | DDoS Protection | Custom Rules |
|---|---|---|---|
| Legacy | ✓ always | ✓ included | ✓ included |
| Prefilter | ✓ always | — | — |
| DDoS Inline default | ✓ always | ✓ inline fallback | ✓ evaluated first |
| DDoS Only | — (skipped by design) | ✓ | — (requires allow default) |
The filtering mode is a per-interface setting exposed through the DDoS configuration API. Changing it swaps in the matching filter build at the next config-apply cycle — existing state (bans, active rules) is preserved across the switch, so an in-flight ban list doesn't reset when you change modes.
Different interfaces on the same box can run different modes — a public-facing WAN interface on DDoS Inline, an internal LAN interface on Prefilter, for example.
The API validates the mode name and enforces the DDoS Only + allow-default constraint before applying — an invalid combination is rejected, not silently accepted.