Date: Tue, 28 Feb 2006 08:45:13 +0500 From: "Roman Serbski" <mefystofel@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: Help with IP Filter 4.1.8 Message-ID: <cca5083b0602271945q5ef76163m5712a386e3eb3008@mail.gmail.com> In-Reply-To: <44031DC4.6060804@locolomo.org> References: <cca5083b0602260715w2f4a9e49o494f2f537afca2db@mail.gmail.com> <4402232A.8010908@locolomo.org> <cca5083b0602270548s4147d332v5df89fdb9a0b7ccd@mail.gmail.com> <44031DC4.6060804@locolomo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/27/06, Erik Norgaard <norgaard@locolomo.org> wrote: > read this line: This tells you where the packet is blocked. IIRC @0:2 > means group 0 (you don't use groups) and 2 should be the second rule. > > If you list the ruleset with ipfstat -n that should give you rules with > the same labeling. > > Also, add log keyword to your outgoing rule, to see that it is actually > there the decision is made. You could have some default pass that does > not create the state. > > I know that you've checked and rechecked - but it is really helpful for > us to have the whole ruleset. If you like, change your ip's to x.x.x.x > (but keep different ips different). Hello Erik, My ruleset consists of only 6 rules: pass out quick on lo0 from any to any pass out quick on xl0 proto tcp from any to any port =3D domain flags S/FSRPAU keep state pass out quick on xl0 proto udp from any to any port =3D domain keep state block out log quick on xl0 all pass in quick on lo0 from any to any block in quick on xl0 all The rule # 2 which was blocking reply from DNS server is 'block in quick on xl0 all'. Adding 'log' keyword to the rule allowing outgoing 53/udp gives the followi= ng: xl0 @0:3 p YYY.YYY.YYY.YYY,50359 -> XXX.XXX.XXX.XXX,53 PR udp len 20 57 K-S= OUT So outgoing 53/udp was successfully passed through, but incoming reply was blocked again: xl0 @0:2 b XXX.XXX.XXX.XXX,53 -> YYY.YYY.YYY.YYY,50359 PR udp len 20 298 IN= bad Yes, I also tried another DNS server - same results. I think this is more ipf issue, so I'll try to ask for assistance in ipf maling list, I was just thinking if someone else has faced with the similar problem during upgrade from ipf v3.4.35 to v4.1.8. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cca5083b0602271945q5ef76163m5712a386e3eb3008>