Date: Mon, 19 Oct 2009 10:38:05 -0700 From: Chris St Denis <chris@smartt.com> To: Ian Smith <smithi@nimnet.asn.au> Cc: Jason Lewis <me@sharktooth.org>, freebsd-ipfw@freebsd.org, Freddie Cash <fjwcash@gmail.com> Subject: Re: ipfw: install_state: entry already present, done Message-ID: <4ADCA3FD.5080004@smartt.com> In-Reply-To: <20091017171148.T70724@sola.nimnet.asn.au> References: <4AC51F18.5050703@smartt.com> <b269bc570910011455i7fd46379p720a38a7ff50260e@mail.gmail.com> <4AC52918.2020705@smartt.com> <8d923f617db88c873c63bb2038752147.squirrel@users.sharktooth.org> <4ACF9341.2040406@smartt.com> <4AD8FDD0.30008@smartt.com> <20091017171148.T70724@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Interesting idea, but doesn't seem to help any :( I added it into the workstation set I had with it loading between the 127.0.0.1 rules and the check-state. Message didn't stop and "ipfw show" doesn't show anything hitting that rule. What "ipfw show" does show is a lot on the "allow tcp .... setup keep-state" and "allow udp .... keep-state" rules hitting all the packets (plus one each on 2 of the abuse ones farther down) I tried rolling back my sys/netinet/ip_fw2.c to the latest revision from 7.1 and that didn't help either, so I don't think it was a change to that file. Unless there is a kernel developer aroun who is more familiar with the network stack to fix this or point me in a better direction, I'll keep rolling back individual files trying to find which commit caused this. Ian Smith wrote: > On Fri, 16 Oct 2009, Chris St Denis wrote: > > > > This is definitely a regression in 7.2. > > > > Downgrades to 6.4, 7.0, 7.1 did not show this symptom. Upgrade the test > > server back to 7.2 and the messages come back. > > I notice neither your rules shown below nor the "workstation" rules - > unlike the "client" and "simple" rulesets - allow IP fragments to pass, > and I'm not sure what happens to frags that are associated with stateful > DNS rules. > > The only frags I usually see here are associated with DNS responses from > my forwarders, usually huge lists of NS for spamhaus.org that are almost > always fragmented (around 2Kbytes). > > You could maybe try a specific 'allow log all from any to any frag' ? > > Just a wild stab in the dark, > > cheers, Ian > > > Chris St Denis wrote: > > > check_state doesn't help. The error is also generated from the rc.conf > > > firewall_type="workstation" rule set which includes check_state among > > > several other rules. > > > > > > I made a copy of this server (it's a virtual server under WMware) and > > > downgraded it to 6.4-RELEASE-p7 and I no longer get the error. > > > > > > I downgraded another copy to 7.2-RELEASE (no patches) by copying the > > > generic kernel off the CD. Still gets errors. > > > > > > Downgraded it to 7.0-RELEASE and the message stopped. > > > > > > I'm going to try going to 7.1 and see which behavior it has. > > > > > > Looks like there may have been a regression in 7.2 (or maybe 7.1 pending > > > the results of my further testing) > > > > > > > > > Jason Lewis wrote: > > > > Did you try a check_state? I am using this same rule structure on BSD6 > > > > without a problem. > > > > > > > > Thanks, > > > > Jason > > > > http://jasonlewis.yaritz.net > > > > > > > > > > > > > Freddie Cash wrote: > > > > > > > > > > > On Thu, Oct 1, 2009 at 2:28 PM, Chris St Denis <chris@smartt.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Haven't gotten any response on -questions so trying here. I've also > > > > > > > opened > > > > > > > a PR (kern/139226) but it's gotten no replies so I figured I should > > > > > > > try > > > > > > > here > > > > > > > since I'm not certain if it's a bug or not. Regardless I am hoping > > > > > > > for > > > > > > > at > > > > > > > least a work-around -- a few extra rules or settings to keep my > > > > > > > console > > > > > > > from > > > > > > > being flooded by errors. So far only option I found is commenting > > > > > > > out > > > > > > > the > > > > > > > error display line in the kernel source which is far from optimal. > > > > > > > > > > > > > > I'm trying to setup a stateful firewall for my server such that any > > > > > > > traffic > > > > > > > can go out, and it's reply come back -- a fairly typical > > > > > > > workstation > > > > > > > setup. > > > > > > > However I'm getting the error message "ipfw: install_state: entry > > > > > > > already > > > > > > > present, done" repeated many times in my logs (tho the rules seemed > > > > > > > to > > > > > > > work > > > > > > > fine otherwise). > > > > > > > > > > > > > > I stripped down the rules to the minimum I could and discovered the > > > > > > > line > > > > > > > causing it is "allow udp from me to any keep-state". > > > > > > > > > > > > > > Only seems to happen when I have bind running as a slave dns server > > > > > > > (not > > > > > > > publicly listed, just the zone replication traffic causes the > > > > > > > error) > > > > > > > but I > > > > > > > assume any other large source of UDP traffic would also do it. > > > > > > > > > > > > > > Full firewall rules: > > > > > > > > > > > > > > dns2# ipfw list > > > > > > > 00100 allow ip from any to any via lo0 > > > > > > > 00200 deny ip from any to 127.0.0.0/8 > > > > > > > 00300 deny ip from 127.0.0.0/8 to any > > > > > > > 00400 allow udp from me to any keep-state > > > > > > > 65535 deny ip from any to any > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you add "out xmit em0" to the udp rule, do the errors stop > > > > > > > > > > > I added that and restarted bind (thus generating a bunch of UDP > > > > > traffic) > > > > > and the error still floods the console. > > > > > > > > > > Current rule set: > > > > > 00100 allow ip from any to any via lo0 > > > > > 00200 deny ip from any to 127.0.0.0/8 > > > > > 00300 deny ip from 127.0.0.0/8 to any > > > > > 00400 allow udp from me to any out xmit em0 keep-state > > > > > 00500 allow ip from any to any > > > > > 65535 deny ip from any to any > > > > > > > > > > _______________________________________________ > > > > > freebsd-ipfw@freebsd.org mailing list > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > > > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > freebsd-ipfw@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > > > > > > > > > > > > > > -- > > Chris St Denis > > Programmer > > SmarttNet (www.smartt.com) > > Ph: 604-473-9700 Ext. 200 > > ------------------------------------------- > > "Smart Internet Solutions For Businesses" > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > -- Chris St Denis Programmer SmarttNet (www.smartt.com) Ph: 604-473-9700 Ext. 200 ------------------------------------------- "Smart Internet Solutions For Businesses"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ADCA3FD.5080004>