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 <m...@my.gd> wrote: > Regarding your rule #12, I confirm it is matched, and you have seen it > yourself: the bytes and states values change. > > > Regarding modulate state, you can find the manual entry for OpenBSD's > page which states that: > === > 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. > === > > > In a nutshell, it randomizes Initial Sequence Numbers for TCP to provide > better protection against certain specific attacks. > > > As an initial test, I would like you to adjust your rule to use "keep > state" instead of "modulate state" and try again. > > > 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 > > > > > On 2/28/12 3:43 PM, csbender wrote: >> Hi Damien, PF folks >> yes >> checking the pflog is important. I am not entirely sure but please correct >> were >> I go off path. >> >> I send SMTP traffic from client here is pflog: >> >> # tcpdump -nei pflog0 host 10.156.81.10 and port 25 >> tcpdump: listening on pflog0, link-type PFLOG >> 09:37:14.901238 rule 12/(match) pass in on bge0: 10.156.81.10.55718 > >> 172.19.4.41.25: S 3029008357:3029008357(0) win 64240 <mss >> 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 > >> 172.19.4.41.25: S 3597046675:3597046675(0) win 64240 <mss >> 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 > >> 172.19.4.41.25: S 3029008357:3029008357(0) win 64240 <mss >> 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 > >> 172.19.4.41.25: S 3619107731:3619107731(0) win 64240 <mss >> 1260,nop,nop,nop,nop,nop,nop,nop,nop,[|tcp]> [tos 0xb8] >> >> >> Now I am not sure what indicated this rules is used. From below >> >> @11 pass in quick inet proto tcp from 172.19.4.75 to 172.19.5.1 port = ssh >> flags >> 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 = >> smtp >> flags any modulate state label "RULE 0 -- ACCEPT " >> [ Evaluations: 111973184 Packets: 12400 Bytes: 893938 States: 6 >> >> ] >> >> you have packets, byes and states. Is it the state I must see incrementing? >> I >> have doen this several times and I see the state incrementing. >> >> >> >> @11 pass in quick inet proto tcp from 172.19.4.75 to 172.19.5.1 port = ssh >> flags >> 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 = >> smtp >> flags any modulate state label "RULE 0 -- ACCEPT " >> [ Evaluations: 111650386 Packets: 12362 Bytes: 891246 States: 24 >> >> ] >> >> >> I do see states changing on this rule @12. >> >> What is the modulate state, I was looking in the book of PF didn't see it as >> modulate, what setting or how to change that? >> >> Lastly, how to disable scrub in tcp reassembly. I am not sure. >> >> I will look into these though >> >> >> Regards >> >> ----- Original Message ---- >> From: Damien Fleuriot <m...@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) >> >> >> >> 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 least >>> for >>> >>> now. >>> >>> >>> >>> I have a PF running freebsd 8.2. >>> >>> Here is my issue... >>> >>> 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. >>> >>> Evidence...Here is am sending email from a network which comes across the >>> FW. >>> Here is the tcpdump. >>> >>> >>> # tcpdump -ni bge0 host 10.156.81.10 and port 25 >>> tcpdump: listening on bge0, link-type EN10MB >>> 14:26:50.220591 10.156.81.10.60809 > 172.19.4.41.25: S >>> 3154136673:3154136673(0) >>> >>> win 64240 <mss >>> 1260,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop> (DF) >>> [tos >>> >>> 0xb8] >>> 14:26:50.244314 10.156.81.10.60809 > 172.19.4.41.25:R >>> 3154136674:3154136735(61) >>> >>> ack 1245040067 win 0 (DF) [tos 0xb8] >>> 14:27:11.233494 10.156.81.10.60809 > 172.19.4.41.25: S >>> 3154136673:3154136673(0) >>> >>> win 64240 <mss >>> 1260,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop> (DF) >>> [tos >>> >>> 0xb8] >>> 14:27:11.245057 10.156.81.10.60809 > 172.19.4.41.25:R 0:61(61) ack 1 win 0 >>> (DF) >>> >>> [tos 0xb8] >>>> From the above it is easy to see traffic isn't passing. >>> >>> Below is the rule that this traffic should be matching. >>> >>> pass log quick inet proto tcp from <tbl.r0.d> to any port = smtp flags any >>> modulate state label "RULE 1 -- ACCEPT " >>> >>> First question ...what command can I run to verify that the rule above is >>> pertaining to the traffic above? >>> Secondly....what else could be squashing this SMTP traffic. It all works >>> well >>> when pfctl is -d. >>> >> >> First, check the logs from PF itself, not just a tcpdump from the >> interface, and check what rule number matches: >> >> tcpdump -nei pflog0 >> >> Then, obviously, display your pf rules and check what rule matched the >> traffic, using its number: pfctl -vvsr >> >> >> >> Second, get rid of "modulate state" and use "keep state" instead. >> >> Third, if that doesn't fix your problem, disable tcp reassembly in your >> "scrub" rules. >> >> We had similar problems with scrubbing + TCP reassembly enabled over a >> year ago on 8.x >> >> _______________________________________________ >> freebsd-pf@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org" >> _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
