Limit src address may not work well:

[Alexander V. Chernikov]

Blog Tieng Viet wrote:
> Dear all, 
> 
> I am using IPFW in FreeBSD 7.3-RELEASE.
> I have some problems as following:
> 
> Limit src address may not work well:
> 
> For example, I want to limit google robot not over 1 connection establishment:
> 
> ${fwcmd} add 5625 pass tcp from 66.249.0.0/16 to me 80 limit src-addr 1
> 
> But I saw there are about 6 ESTABLISMENT of this address in the results of "netstat -n"
> 
> Is it my wrong, please give me an advice.

Do you have some rule before 5625 consuming all TCP established traffic,
for example?

You need to get ALL traffic from '66.249.0.0/16 to me 80' to match this
exact rule.



> 
> Best regards.
> 
> 
> --- On Thu, 11/3/11, Tim Gustafson <tjg at soe.ucsc.edu> wrote:
> 
>> From: Tim Gustafson <tjg at soe.ucsc.edu>
>> Subject: Re: IPFW Problems
>> To: "Michael Sierchio" <kudzu at tenebras.com>
>> Cc: freebsd-ipfw at freebsd.org
>> Date: Thursday, November 3, 2011, 1:56 AM
>>> You may want to tweak the sysctl
>> items that control the lifespan
>>> of dynamic rules.
>>>
>>> sysctl net.inet.ip.fw
>>>
>>> in particular, the default value of
>> net.inet.ip.fw.dyn_ack_lifetime
>>> is probably way too long for your purposes.
>> Here's what I have right now:
>>
>> root at bsd-02: sysctl net.inet.ip.fw
>> net.inet.ip.fw.static_count: 48
>> net.inet.ip.fw.default_to_accept: 0
>> net.inet.ip.fw.tables_max: 128
>> net.inet.ip.fw.default_rule: 65535
>> net.inet.ip.fw.verbose_limit: 0
>> net.inet.ip.fw.verbose: 0
>> net.inet.ip.fw.autoinc_step: 100
>> net.inet.ip.fw.one_pass: 1
>> net.inet.ip.fw.enable: 1
>> net.inet.ip.fw.dyn_keepalive: 1
>> net.inet.ip.fw.dyn_short_lifetime: 5
>> net.inet.ip.fw.dyn_udp_lifetime: 10
>> net.inet.ip.fw.dyn_rst_lifetime: 1
>> net.inet.ip.fw.dyn_fin_lifetime: 1
>> net.inet.ip.fw.dyn_syn_lifetime: 20
>> net.inet.ip.fw.dyn_ack_lifetime: 300
>> net.inet.ip.fw.dyn_max: 32768
>> net.inet.ip.fw.dyn_count: 805
>> net.inet.ip.fw.curr_dyn_buckets: 256
>> net.inet.ip.fw.dyn_buckets: 256
>>
>> I'm assuming that's in seconds.  Is 300 seconds too
>> long?  It seems like the dynamic rules are hanging
>> around for hours or days, and I think the timeout is getting
>> reset by the fact that the system is constantly sending out
>> ACK packets to clients that aren't acknowledging them.
>>
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> Tim Gustafson           
>>                
>>                
>>     tjg at soe.ucsc.edu
>> Baskin School of Engineering       
>>                
>>          
>>    831-459-5354
>> UC Santa Cruz           
>>                
>>              Baskin
>> Engineering 317B
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> _______________________________________________
>> freebsd-ipfw at freebsd.org
>> mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>>
> _______________________________________________
> freebsd-ipfw at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>