Date: Wed, 29 Feb 2012 01:24:07 +0100 From: Damien Fleuriot <ml@my.gd> To: Chris Bender <csbender@bellsouth.net> Cc: "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org> Subject: SOLVED - Re: PF issue (rule match but rule fails) Message-ID: <A3B3A7D6-A957-4318-8777-345B6BCF518E@my.gd> In-Reply-To: <AD183CE6-1C9C-4261-B294-9FB57DDC6D7B@bellsouth.net> 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> <AD183CE6-1C9C-4261-B294-9FB57DDC6D7B@bellsouth.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Glad to hear that worked ;) On 28 Feb 2012, at 18:57, Chris Bender <csbender@bellsouth.net> wrote: > Dude that was great it worked, I only changed the modulate to keep to work= . >=20 > Thanks >=20 > Sent from my iPhone >=20 > On Feb 28, 2012, at 10:17 AM, Damien Fleuriot <ml@my.gd> wrote: >=20 >> 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 corr= ect 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= ssh 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> por= t =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 incrementi= ng? 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= ssh 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> por= t =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 i= t 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 l= east 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 wh= y. >>>>=20 >>>> Evidence...Here is am sending email from a network which comes across t= he 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:31541= 36673(0)=20 >>>>=20 >>>> win 64240 <mss=20 >>>> 1260,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop> (= DF) [tos=20 >>>>=20 >>>> 0xb8] >>>> 14:26:50.244314 10.156.81.10.60809 > 172.19.4.41.25:R 3154136674:315413= 6735(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:31541= 36673(0)=20 >>>>=20 >>>> win 64240 <mss=20 >>>> 1260,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop> (= DF) [tos=20 >>>>=20 >>>> 0xb8] >>>> 14:27:11.245057 10.156.81.10.60809 > 172.19.4.41.25:R 0:61(61) ack 1 wi= n 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 flag= s 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 work= s 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?A3B3A7D6-A957-4318-8777-345B6BCF518E>