Is it impossible to invert “Dst. Limit” (no exclamation mark there), like we do for “Limit”?
If not, please consider this a feature request.

Is it impossible to invert “Dst. Limit” (no exclamation mark there), like we do for “Limit”?
If not, please consider this a feature request.

Follow up by “same” rule minus the limit and desired action.
Ex:
in-intf=wan & state=new & limit 5/s → action: accept
in-intf=wan & state=new → action: drop
Result:
limit number of “new” connection on wan interface to 5/s max. Any additional will be dropped.
What would be a typical usage for such setups?
Resource limiting / protection: rate, capacity, …
Why not use queues?
too vague of an answer for me…
What does this limiting actually do and why would I apply it to my pc, somebody elses PC, a printer, etc…
This works nice, I forgot I could do it, thanks.
how about that?
create specific chain for this
in there 2 rules:
within limit action=return
over limit action=mark
@gotspring: queues are for bandwidth only, number of connections, rate of new connections can’t be controlled there
@anav: most normal users (even power users having a Tik) won’t need it, I’ve it configured because I’ve a publicly accessible service, which is sometimes abused. hence I want to reduce the impact of abusers on the rest of users, and limiting connection establish rate (and connections counts, but that’s on server itself)
Okay so you are limiting how many sessions a person can have open on your site? For example an FTP server, to limit of 3 would not allow someone to download more than 3 files at any one time? The rate of connections is a harder one to pin down. Hmmm, can you think of an example???
The only thing I miss now about dst-limit is that it does not allow to match source port (only source address, dst address, dst port).
This makes it hard to distinguish between:
What I’m doing is:
when an outgoing HTTPS connection is filtered by ISP (it drops packets), I add the IP address into address list and direct further connections into a tunnel.
#connection analogy is fitting
“limit” in doc: Matches packets up to a limited rate (…). Rule using this matcher will match until this limit is reached. …
together with reject rule after such limit rule, one can limit the rate at which events occur.
ex:
number of pings:
type=icmp & limit=10/s action=accept
type=icmp action=drop
→ only accept upto 10 pings /s
number of new connection requests
state=new & limit=10/s action=accept
state=new action=drop
possible situation: suppose that creating a new connection is heavy activity (ex ssl setup). then an individual with many clients could impact the service if he made a lot of connections at once. limiting how many heavy activities can happen during a period, allows to control load on the system