On this page
A port rule can carry two packet-rate ceilings. One bounds the port as a whole, the other bounds a single connection. They do different jobs, and one of them does nothing on its own.
The two ceilings
Whole port, packets/sec is the aggregate. Every source sending to that port counts towards it, so this is the ceiling that bounds a distributed flood coming from thousands of addresses at once.
Per connection, packets/sec applies to one established flow. It exists because an aggregate cap alone leaves a gap. In one incident 2,275 established connections pushed 569,000 packets per second through a port whose aggregate cap was set to 5,000. Each individual connection looked reasonable. Together they did not.
pps_limitpackets/sec, all sources combineddefault 0Set from the field labelled Whole port, packets/sec (0 = unlimited). This is the number that stops a distributed flood.
0 means: no aggregate limit, the port accepts any rate
estab_flow_ppspackets/sec, one established flowdefault 0Set from the field labelled Per connection, packets/sec (0 = service default). Only has an effect when a whole-port limit is also set. See below.
0 means: the filter uses its built-in default for that service, which is not the same as unlimited
The per-connection limit needs a whole-port limit
The Per connection field is greyed out until Whole port is above zero. That is not a UI quirk. The filter only consults the per-flow ceiling inside the aggregate one, so a per-connection number set on its own is never applied. The panel says this next to the field:
Needs a whole-port ceiling above. The datapath only consults this inside that limit, so on its own it is not applied.
If you want per-connection limiting, set both.
Choosing numbers
Start from what your server does when nothing is wrong, then leave headroom. A cap below your own busy-hour traffic will drop real players, and it will look exactly like an attack to you.
A worked example. A Minecraft server on port 25565, during a SYN flood from 336 separate sources:
| Setting | Result |
|---|---|
pps_limit 10000 | The edge shed about 85% of the flood and the server stayed responsive |
pps_limit 0 | The same flood put 66,000 packets per second onto the server |
On that service estab_flow_pps of 250 is about what a single established
player needs, and 80 is low enough to cut real players off. Treat 250 as a floor
for Minecraft rather than a number to trim.
What the panel accepts
Rules are validated before they are saved:
- Ports are whole numbers from 1 to 65535.
- The end of a range cannot be lower than its start.
- Protocol is TCP or UDP.
- Rate limits cannot be negative.
Ownership is re-checked on every change, so a rule can only ever be written against a server on your own account.
What saving a rule changes
Editing a rule updates the fields shown in the form and leaves the rest of that rule alone.
One thing to know: a field the form does own is saved exactly as you leave it, and a cleared box means zero. Clearing Whole port, packets/sec saves 0, which turns the aggregate limit off. It does not mean "leave it as it was".