Date: Tue, 28 Feb 2012 12:57:13 -0500 From: Chris Bender <csbender@bellsouth.net> To: Damien Fleuriot <ml@my.gd> Cc: "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org> Subject: Re: PF issue (rule match but rule fails) Message-ID: <AD183CE6-1C9C-4261-B294-9FB57DDC6D7B@bellsouth.net> In-Reply-To: <4F4CF024.9000202@my.gd> References: <1330392478.216.YahooMailRC@web180716.mail.sp1.yahoo.com> <4F4C8B1F.1000302@my.gd> <1330440204.54973.YahooMailRC@web180705.mail.sp1.yahoo.com> <4F4CF024.9000202@my.gd>
next in thread | previous in thread | raw e-mail | index | archive | help
Dude that was great it worked, I only changed the modulate to keep to work. Thanks Sent from my iPhone On Feb 28, 2012, at 10:17 AM, Damien Fleuriot <ml@my.gd> wrote: > Regarding your rule #12, I confirm it is matched, and you have seen it > yourself: the bytes and states values change. >=20 >=20 > Regarding modulate state, you can find the manual entry for OpenBSD's > page which states that: > =3D=3D=3D > The modulate state option works just like keep state except that it only > applies to TCP packets. With modulate state, the Initial Sequence Number > (ISN) of outgoing connections is randomized. This is useful for > protecting connections initiated by certain operating systems that do a > poor job of choosing ISNs. To allow simpler rulesets, the modulate state > option can be used in rules that specify protocols other than TCP; in > those cases, it is treated as keep state. > =3D=3D=3D >=20 >=20 > In a nutshell, it randomizes Initial Sequence Numbers for TCP to provide > better protection against certain specific attacks. >=20 >=20 > As an initial test, I would like you to adjust your rule to use "keep > state" instead of "modulate state" and try again. >=20 >=20 > If that should fail as well, we'll get back to the scrub bit. > In the meantime you can read about it here: > http://www.openbsd.org/faq/pf/ru/scrub.html >=20 >=20 >=20 >=20 > On 2/28/12 3:43 PM, csbender wrote: >> Hi Damien, PF folks >> yes=20 >> checking the pflog is important. I am not entirely sure but please corre= ct were=20 >> I go off path. >>=20 >> I send SMTP traffic from client here is pflog: >>=20 >> # tcpdump -nei pflog0 host 10.156.81.10 and port 25=20 >> tcpdump: listening on pflog0, link-type PFLOG >> 09:37:14.901238 rule 12/(match) pass in on bge0: 10.156.81.10.55718 >=20 >> 172.19.4.41.25: S 3029008357:3029008357(0) win 64240 <mss=20 >> 1260,nop,nop,nop,nop,nop,nop,nop,nop,[|tcp]> (DF) [tos 0xb8] >> 09:37:14.901276 rule 12/(match) pass out on vlan579: 10.156.81.10.55718 >= =20 >> 172.19.4.41.25: S 3597046675:3597046675(0) win 64240 <mss=20 >> 1260,nop,nop,nop,nop,nop,nop,nop,nop,[|tcp]> [tos 0xb8] >> 09:37:35.901429 rule 12/(match) pass in on bge0: 10.156.81.10.55718 >=20 >> 172.19.4.41.25: S 3029008357:3029008357(0) win 64240 <mss=20 >> 1260,nop,nop,nop,nop,nop,nop,nop,nop,[|tcp]> (DF) [tos 0xb8] >> 09:37:35.901471 rule 12/(match) pass out on vlan579: 10.156.81.10.55718 >= =20 >> 172.19.4.41.25: S 3619107731:3619107731(0) win 64240 <mss=20 >> 1260,nop,nop,nop,nop,nop,nop,nop,nop,[|tcp]> [tos 0xb8] >>=20 >>=20 >> Now I am not sure what indicated this rules is used. =46rom below >>=20 >> @11 pass in quick inet proto tcp from 172.19.4.75 to 172.19.5.1 port =3D s= sh flags=20 >> any modulate state label "RULE -1 -- ACCEPT " >> [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0= ] >> [ Inserted: uid 0 pid 1901 State Creations: 0 ] >> @12 pass log quick inet proto tcp from <tbl.r0.s:22> to <tbl.r0.d:4> port= =3D smtp=20 >> flags any modulate state label "RULE 0 -- ACCEPT " >> [ Evaluations: 111973184 Packets: 12400 Bytes: 893938 States: 6= =20 >> ] >>=20 >> you have packets, byes and states. Is it the state I must see incrementin= g? I=20 >> have doen this several times and I see the state incrementing. >>=20 >>=20 >>=20 >> @11 pass in quick inet proto tcp from 172.19.4.75 to 172.19.5.1 port =3D s= sh flags=20 >> any modulate state label "RULE -1 -- ACCEPT " >> [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0= ] >> [ Inserted: uid 0 pid 1901 State Creations: 0 ] >> @12 pass log quick inet proto tcp from <tbl.r0.s:22> to <tbl.r0.d:4> port= =3D smtp=20 >> flags any modulate state label "RULE 0 -- ACCEPT " >> [ Evaluations: 111650386 Packets: 12362 Bytes: 891246 States: 2= 4 =20 >> ] >>=20 >>=20 >> I do see states changing on this rule @12. >>=20 >> What is the modulate state, I was looking in the book of PF didn't see it= as=20 >> modulate, what setting or how to change that? >>=20 >> Lastly, how to disable scrub in tcp reassembly. I am not sure. >>=20 >> I will look into these though >>=20 >>=20 >> Regards >>=20 >> ----- Original Message ---- >> From: Damien Fleuriot <ml@my.gd> >> To: freebsd-pf@freebsd.org >> Sent: Tue, February 28, 2012 3:06:55 AM >> Subject: Re: PF issue (rule match but rule fails) >>=20 >>=20 >>=20 >> On 2/28/12 2:27 AM, csbender wrote: >>> Hi Folks, >>> it is great to join you. >>> I am pretty new to the world of PF so please excuse some ignorance at le= ast for=20 >>>=20 >>> now.=20 >>>=20 >>>=20 >>>=20 >>> I have a PF running freebsd 8.2.=20 >>>=20 >>> Here is my issue... >>>=20 >>> I have SMTP rule allowing traffic in and out for certain networks. >>> Some SMTP traffic fails, eventhough I see rule match, I have no idea why= . >>>=20 >>> Evidence...Here is am sending email from a network which comes across th= e FW. >>> Here is the tcpdump. >>>=20 >>>=20 >>> # tcpdump -ni bge0 host 10.156.81.10 and port 25 =20 >>> tcpdump: listening on bge0, link-type EN10MB >>> 14:26:50.220591 10.156.81.10.60809 > 172.19.4.41.25: S 3154136673:315413= 6673(0)=20 >>>=20 >>> win 64240 <mss=20 >>> 1260,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop> (D= F) [tos=20 >>>=20 >>> 0xb8] >>> 14:26:50.244314 10.156.81.10.60809 > 172.19.4.41.25:R 3154136674:3154136= 735(61)=20 >>>=20 >>> ack 1245040067 win 0 (DF) [tos 0xb8] >>> 14:27:11.233494 10.156.81.10.60809 > 172.19.4.41.25: S 3154136673:315413= 6673(0)=20 >>>=20 >>> win 64240 <mss=20 >>> 1260,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop> (D= F) [tos=20 >>>=20 >>> 0xb8] >>> 14:27:11.245057 10.156.81.10.60809 > 172.19.4.41.25:R 0:61(61) ack 1 win= 0 (DF)=20 >>>=20 >>> [tos 0xb8] >>>> =46rom the above it is easy to see traffic isn't passing.=20 >>>=20 >>> Below is the rule that this traffic should be matching. >>>=20 >>> pass log quick inet proto tcp from <tbl.r0.d> to any port =3D smtp flags= any=20 >>> modulate state label "RULE 1 -- ACCEPT " >>>=20 >>> First question ...what command can I run to verify that the rule above i= s=20 >>> pertaining to the traffic above? >>> Secondly....what else could be squashing this SMTP traffic. It all works= well=20 >>> when pfctl is -d. >>>=20 >>=20 >> First, check the logs from PF itself, not just a tcpdump from the >> interface, and check what rule number matches: >>=20 >> tcpdump -nei pflog0 >>=20 >> Then, obviously, display your pf rules and check what rule matched the >> traffic, using its number: pfctl -vvsr >>=20 >>=20 >>=20 >> Second, get rid of "modulate state" and use "keep state" instead. >>=20 >> Third, if that doesn't fix your problem, disable tcp reassembly in your >> "scrub" rules. >>=20 >> We had similar problems with scrubbing + TCP reassembly enabled over a >> year ago on 8.x >>=20 >> _______________________________________________ >> freebsd-pf@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AD183CE6-1C9C-4261-B294-9FB57DDC6D7B>