ipfw, keep-state and limit

Luigi Rizzo rizzo at icir.org
Mon Apr 16 15:45:51 UTC 2007


On Mon, Apr 16, 2007 at 03:44:00PM +0200, Ivan Voras wrote:
> Luigi Rizzo wrote:
> >>> if i remember well (the implementation dates back to 2001 or so)
> >>> you just need to use "limit", as it implicitly installs
> >>> a dynamic state entry (same as keep-state).
> 
> My new rule is:
> 06079    376036    286721568 allow tcp from any to me dst-port 80 setup 
> limit src-addr 15
> 
> And now ipfw -d show displays (among others):
> 
> 06079         0            0 (0s) PARENT 2 tcp xx.53.98.13 0 <-> 0.0.0.0 0
> 06079         0            0 (0s) PARENT 1 tcp xx.29.147.17 0 <-> 0.0.0.0 0
> 06079         0            0 (0s) PARENT 5 tcp xx.29.242.18 0 <-> 0.0.0.0 0
> 06079         0            0 (0s) PARENT 0 tcp xx.53.68.19 0 <-> 0.0.0.0 0
> 06079         0            0 (0s) PARENT 1 tcp xx.53.18.22 0 <-> 0.0.0.0 0
> 06079         0            0 (8s) PARENT 1 tcp xx.55.213.39 0 <-> 0.0.0.0 0
> 06079         0            0 (6s) PARENT 1 tcp xx.53.76.41 0 <-> 0.0.0.0 0
> 06079         0            0 (0s) PARENT 0 tcp xx.164.34.41 0 <-> 0.0.0.0 0
> 
> I assume 0s in this case is good, and "PARENT n" means n connections 
> from the client?

you have to look at the source code because it has been a few years
since i implemented them, but i believe the PARENT lines (which have
0's in the counters and unused fields) are the summary for the individual
clients, and the individual entries are the 'LIMIT' rules below.
I am not sure why there is a non-zero timeout in some of the parent
rules

	cheers
	luigi

> I've also got some dynamic rules referencing LIMIT on the same rule #:
> 06079      1471      1211349 (300s) LIMIT tcp xx.198.150.143 1507 <-> 
> my.ip.ad.dr 80
> 06079      1243       988046 (300s) LIMIT tcp xx.198.150.143 1508 <-> 
> my.ip.ad.dr 80
> 06079        25        15740 (299s) LIMIT tcp xx.53.74.51 1368 <-> 
> my.ip.ad.dr 80
> 06079         7         1392 (223s) LIMIT tcp xx.254.251.10 3168 <-> 
> my.ip.ad.dr 80
> 
> These are the individual connections, right?
> 




More information about the freebsd-net mailing list