From owner-freebsd-pf@FreeBSD.ORG Wed Feb 29 01:51:25 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95191106566B for ; Wed, 29 Feb 2012 01:51:25 +0000 (UTC) (envelope-from csbender@bellsouth.net) Received: from nm17-vm1.bullet.mail.sp2.yahoo.com (nm17-vm1.bullet.mail.sp2.yahoo.com [98.139.91.213]) by mx1.freebsd.org (Postfix) with SMTP id 657AB8FC0A for ; Wed, 29 Feb 2012 01:51:25 +0000 (UTC) Received: from [98.139.91.69] by nm17.bullet.mail.sp2.yahoo.com with NNFMP; 29 Feb 2012 01:38:49 -0000 Received: from [98.139.44.93] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 29 Feb 2012 01:37:49 -0000 Received: from [127.0.0.1] by omp1030.access.mail.sp2.yahoo.com with NNFMP; 29 Feb 2012 01:37:49 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 545923.23878.bm@omp1030.access.mail.sp2.yahoo.com Received: (qmail 16589 invoked by uid 60001); 29 Feb 2012 01:37:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1330479469; bh=nytMqQkAAlhELi1D5tg4nQUMkAszSMh5h9eMPASXDXk=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gonoZzL58CxZ/GneCpmBi1TJSKQ4tNBR+/uD4xPRiQG0oZ7UKM2CxEOR+noeshzCCNp+AhU45KrriEL6bxUFsNbWQmIQYOUa3xBd7XRuJHTRYAKpsFqJB2KD7LaZfbCY43xzL+syA3DszgapqPF42qUo5OFlRSRneZCJsuEck5o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=bellsouth.net; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tEnR39vHCocTkaKvVguI2z+bioXMKH57AXBC94LAQGx3M0tWPCN4nhExcl3OoPd62A29elZoxZXSraYeZQZglpuayTRg2+wtG4k7La8iAgUlWG5nDs2/Dm7BUjO4DhGJ3Lvmy8seYBCjMC0OlkEotLqpgXjAIPtJJn642rEzrZk=; X-YMail-OSG: kt4zLgYVM1k7JmNzMtLPsizHpGdq__gxE.VtEJK54rOyAdA TJD.hbYkU4XmslyIuWBVnUH740TA6cFYExSPHVtLa7sCcUIxMinX8PEKXtca Nl2wW1Yhefpg77LNiwDonaVLJ1jygCPUwl3wEsxxS64lTQEr5dN7EGL8oQgg yKtcrVdvMPn3V77vabu.ildO5z31wGUkv_OB.PFVkK.IhTONnai8wIfe119Q hLMscj5rrIEIxjGdIJGgGPsydGForZd5GxF5k9wbkcuSUhiOTnvl7Q3m5tpy qqmIJKLAmVhVrmtgNlPgEvUZl5FVsK4xwvfEfOlHfJ_T77LqNRRJ4x30obVA ehGTuPJkjk8d93FvwkLZSU7G4_njffnm8IxXPf0PIoZ9KbcFDmp33ANq5zYN U4H5.MtxxJODOrUwLR90Gwl2s1youfJE5BUtdHVBqOUytcJ0wbtyZGNzcOcf SdWVxcx_9PlUV8dIRvfOpZ.RMykdbzrwdyfL5sD0IJ9s- Received: from [12.199.110.20] by web180712.mail.sp1.yahoo.com via HTTP; Tue, 28 Feb 2012 17:37:49 PST X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.116.338427 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> Message-ID: <1330479469.12861.YahooMailRC@web180712.mail.sp1.yahoo.com> Date: Tue, 28 Feb 2012 17:37:49 -0800 (PST) From: csbender To: Damien Fleuriot In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "freebsd-pf@freebsd.org" Subject: Re: SOLVED - Re: PF issue (rule match but rule fails) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 01:51:25 -0000 You rock dude. Please to be part of this community! ----- Original Message ---- From: Damien Fleuriot To: Chris Bender Cc: "freebsd-pf@freebsd.org" Sent: Tue, February 28, 2012 7:24:07 PM Subject: SOLVED - Re: PF issue (rule match but rule fails) Glad to hear that worked ;) On 28 Feb 2012, at 18:57, Chris Bender wrote: > 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 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 >> 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 >> 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 >> 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 >> 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 to 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 to 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 >>> 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 >>> 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 >>> 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 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-unsubscribe@freebsd.org" >>>