ipfw: install_state: entry already present, done
Chris St Denis
chris at smartt.com
Mon Oct 19 17:38:07 UTC 2009
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 at 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 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"
> > > >
> > >
> > >
> >
> >
> > --
> > Chris St Denis
> > Programmer
> > SmarttNet (www.smartt.com)
> > Ph: 604-473-9700 Ext. 200
> > -------------------------------------------
> > "Smart Internet Solutions For Businesses"
> > _______________________________________________
> > 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"
>
--
Chris St Denis
Programmer
SmarttNet (www.smartt.com)
Ph: 604-473-9700 Ext. 200
-------------------------------------------
"Smart Internet Solutions For Businesses"
More information about the freebsd-ipfw
mailing list