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"
