From owner-freebsd-pf@FreeBSD.ORG Mon Feb 27 11:07:42 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 6EA6A106564A for ; Mon, 27 Feb 2012 11:07:42 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5CAF08FC19 for ; Mon, 27 Feb 2012 11:07:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1RB7g97090299 for ; Mon, 27 Feb 2012 11:07:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1RB7fjL090296 for freebsd-pf@FreeBSD.org; Mon, 27 Feb 2012 11:07:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Feb 2012 11:07:41 GMT Message-Id: <201202271107.q1RB7fjL090296@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org 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: Mon, 27 Feb 2012 11:07:42 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/165315 pf [pf] States never cleared in PF with DEVICE_POLLING o kern/164402 pf [pf] pf crashes with a particular set of rules when fi o kern/164271 pf [pf] not working pf nat on FreeBSD 9.0 [regression] o kern/163208 pf [pf] PF state key linking mismatch o kern/160370 pf [pf] Incorrect pfctl check of pf.conf o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 48 problems total. From owner-freebsd-pf@FreeBSD.ORG Tue Feb 28 01:40:44 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 D43C5106567E for ; Tue, 28 Feb 2012 01:40:44 +0000 (UTC) (envelope-from csbender@bellsouth.net) Received: from nm15-vm0.access.bullet.mail.sp2.yahoo.com (nm15-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.164]) by mx1.freebsd.org (Postfix) with SMTP id AC11D8FC13 for ; Tue, 28 Feb 2012 01:40:44 +0000 (UTC) Received: from [98.139.44.106] by nm15.access.bullet.mail.sp2.yahoo.com with NNFMP; 28 Feb 2012 01:27:58 -0000 Received: from [98.139.44.91] by tm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 28 Feb 2012 01:27:58 -0000 Received: from [127.0.0.1] by omp1028.access.mail.sp2.yahoo.com with NNFMP; 28 Feb 2012 01:27:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 491425.95328.bm@omp1028.access.mail.sp2.yahoo.com Received: (qmail 425 invoked by uid 60001); 28 Feb 2012 01:27:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1330392478; bh=nM00PJJoJ9WRHUrs+0EjOxPcTRKmuV8UcPcPkWAtHVg=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=xpOySTl7ZWQ3gJCS8oiccZtO7JnR3+67wRdeTQU6MCJ2uxil5o2ydQTvestH8KuiXs7Z9L56ZUp/RilOhIB6O229JbpXe22ZTL9xKXuUdgoJwwRgI6thFlrDRHrkF2yuKyvLX4W++rdEiUyF7M5N30wWYo9cJFl4JaVYmBSAHAU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=bellsouth.net; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=6qXY6VI2O33yRFK5AU9bBUnqhihZvAFmjRtksEZE+0CmKg2AYJC8iU8rVth4hicFlKCC0hkxmMH6dGwZovAg7LEnF1ykUq1MVdxfOWVO7LX3/AChNlVGVsPQEtX/+qaoZgI+pqkxcvy4aG9fYezDGt7BHyH5LP/TIxg+ker8zLU=; X-YMail-OSG: v1hm.vEVM1lDLCjLh_XvuH7uK0Qs746Zaz35qWAed4TXJXW wheRHcX8MwX.nIWU4WdfUKfhtwqfOK8exZ0rvJFYKFs.ovbNd6eyj2981XcE txHHMBC0bkrH.hq5rdYdfPX402UMYKSxwJHbmS6N6Y0n3rZ06_zdt3Jfi4aM 6efe6ABqVZi.j6zRNM8cEPKNX1X2_WQpgmWlTVtHakRTuPUbq.FpDPsS.hH3 b1JVy65_whj.qXHJ6yyKIAztPsyuq7FMJ8I5LAti7DAaMVzxVelNEua_WZKR 1JtE7Js2RjE3pSy6rQ096w3a6UZbctYRt8W0G4miOLkzDSH1RcABskWD_2AZ yLLH6gcLPwQt9mnNYuOFP93HZZwSXzNUd5uiyCBGGvdCQlIW4lkWpxDej0RN lH_YtTZVkNc4SAHNf60AR8j44JpRUyj0INTYR7c35wK9YpSB0qIpyWQ-- Received: from [12.199.110.20] by web180716.mail.sp1.yahoo.com via HTTP; Mon, 27 Feb 2012 17:27:58 PST X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.116.338427 Message-ID: <1330392478.216.YahooMailRC@web180716.mail.sp1.yahoo.com> Date: Mon, 27 Feb 2012 17:27:58 -0800 (PST) From: csbender To: freebsd-pf@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: 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: Tue, 28 Feb 2012 01:40:45 -0000 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 (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 (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. Do I need to pass my rules? Thanks folks in advance From owner-freebsd-pf@FreeBSD.ORG Tue Feb 28 08:06:59 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 79A94106566C for ; Tue, 28 Feb 2012 08:06:59 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0264B8FC14 for ; Tue, 28 Feb 2012 08:06:58 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so1849082wib.13 for ; Tue, 28 Feb 2012 00:06:57 -0800 (PST) Received-SPF: pass (google.com: domain of ml@my.gd designates 10.180.97.196 as permitted sender) client-ip=10.180.97.196; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ml@my.gd designates 10.180.97.196 as permitted sender) smtp.mail=ml@my.gd Received: from mr.google.com ([10.180.97.196]) by 10.180.97.196 with SMTP id ec4mr35799462wib.11.1330416417946 (num_hops = 1); Tue, 28 Feb 2012 00:06:57 -0800 (PST) Received: by 10.180.97.196 with SMTP id ec4mr28354928wib.11.1330416417825; Tue, 28 Feb 2012 00:06:57 -0800 (PST) Received: from dfleuriot.local (did75-17-88-165-130-96.fbx.proxad.net. [88.165.130.96]) by mx.google.com with ESMTPS id dw7sm27131549wib.4.2012.02.28.00.06.56 (version=SSLv3 cipher=OTHER); Tue, 28 Feb 2012 00:06:56 -0800 (PST) Message-ID: <4F4C8B1F.1000302@my.gd> Date: Tue, 28 Feb 2012 09:06:55 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <1330392478.216.YahooMailRC@web180716.mail.sp1.yahoo.com> In-Reply-To: <1330392478.216.YahooMailRC@web180716.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnifLbnhr1T8PjCOCB7upPtDH2TiLIweBVVLmWTPAZKYr/H1y1gxvIX0+VpAsO6lCR2Jjo1 Subject: 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: Tue, 28 Feb 2012 08:06:59 -0000 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 From owner-freebsd-pf@FreeBSD.ORG Tue Feb 28 14:43: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 7AA02106566B for ; Tue, 28 Feb 2012 14:43:25 +0000 (UTC) (envelope-from csbender@bellsouth.net) Received: from nm18-vm0.access.bullet.mail.sp2.yahoo.com (nm18-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.170]) by mx1.freebsd.org (Postfix) with SMTP id 539628FC0A for ; Tue, 28 Feb 2012 14:43:25 +0000 (UTC) Received: from [98.139.44.102] by nm18.access.bullet.mail.sp2.yahoo.com with NNFMP; 28 Feb 2012 14:43:24 -0000 Received: from [98.139.44.90] by tm7.access.bullet.mail.sp2.yahoo.com with NNFMP; 28 Feb 2012 14:43:24 -0000 Received: from [127.0.0.1] by omp1027.access.mail.sp2.yahoo.com with NNFMP; 28 Feb 2012 14:43:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 947610.8875.bm@omp1027.access.mail.sp2.yahoo.com Received: (qmail 55783 invoked by uid 60001); 28 Feb 2012 14:43:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1330440204; bh=hgA3ex2i+ZwnEJ8TxXBmsUPtAE2SnnRKcrqo25OUb5A=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=JiH4pHmUSVVy4+ihxPcT5kudR5YNbkM3cdCOGPafeGelMqJggX2HQa9Pmfvojj1rrL9l5251dVMNnQJiieUy2+gpM/JC+qRKU8Y8gTBmNF7OS6xnuO4KRuhA/7xwwtO4To7Zl+BI8Mwu8ZXHR0dtaG4sZro30w9CUoaSv36XzGg= 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:In-Reply-To:MIME-Version:Content-Type; b=AiiLxBzYfBz0ekWQgoOtzUUyNajf09GNR+rt445tYfuAmfh9AN9FPiVj70soNnsc9BbJWH5tQvs+QCH7fzMPGA7UOhLwDK7OacN8jJry1EFzil6GFn+AXFtNj38oAhvVqNHtcYoqM0+5Jo2indVuCw1bbId/PWeAzebOn1otkSY=; X-YMail-OSG: PYWu8PEVM1mT3fwYDHOKDpmXpoHcZ.Dek.HZW08v.YnEj_p qalSLhLeN_9vjkpWZn35r.f0dBau7sd25K9BLO8df1tXCgClGvIW2So0dsdu 8x5duxY.eO1WlMIPnk7rjrX8iR5LAFOx6u51weTM2yCLx5FMoCPmJz_DcFS6 KB468Rrj6fG5BDMkArbLJ9ixcp3W3sDnz65UcvM_ATk7qwMwxqmNluM5gAhp kkQgAX3FAkmgYdjze_FB1rtQNmsjkVMSaOM.C.nojkq1F2Y_7__AZ7struvK rn.e2sX3rmm7GJS3P89TLmTSVxkXCKfKNLSMUNQs_wT3_rhAtnfmkyAdlkCz SNYo9ujex3.q.MR8bTuFZJd4Qyw5bARZuJoBvkg1zH75YoxKu_SqTm7xghVl JoRP3qKPDYb63nUlz Received: from [63.214.236.169] by web180705.mail.sp1.yahoo.com via HTTP; Tue, 28 Feb 2012 06:43:24 PST X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.116.338427 References: <1330392478.216.YahooMailRC@web180716.mail.sp1.yahoo.com> <4F4C8B1F.1000302@my.gd> Message-ID: <1330440204.54973.YahooMailRC@web180705.mail.sp1.yahoo.com> Date: Tue, 28 Feb 2012 06:43:24 -0800 (PST) From: csbender To: Damien Fleuriot , freebsd-pf@freebsd.org In-Reply-To: <4F4C8B1F.1000302@my.gd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: 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: Tue, 28 Feb 2012 14:43:25 -0000 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 (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 [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 (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 [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" From owner-freebsd-pf@FreeBSD.ORG Tue Feb 28 15:18:00 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 A00D7106564A for ; Tue, 28 Feb 2012 15:18:00 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2C9FE8FC12 for ; Tue, 28 Feb 2012 15:17:59 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so2862778bkc.13 for ; Tue, 28 Feb 2012 07:17:59 -0800 (PST) Received-SPF: pass (google.com: domain of ml@my.gd designates 10.204.157.138 as permitted sender) client-ip=10.204.157.138; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ml@my.gd designates 10.204.157.138 as permitted sender) smtp.mail=ml@my.gd Received: from mr.google.com ([10.204.157.138]) by 10.204.157.138 with SMTP id b10mr9431442bkx.75.1330442279067 (num_hops = 1); Tue, 28 Feb 2012 07:17:59 -0800 (PST) Received: by 10.204.157.138 with SMTP id b10mr7597283bkx.75.1330442278832; Tue, 28 Feb 2012 07:17:58 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id jc4sm31873460bkc.7.2012.02.28.07.17.57 (version=SSLv3 cipher=OTHER); Tue, 28 Feb 2012 07:17:57 -0800 (PST) Message-ID: <4F4CF024.9000202@my.gd> Date: Tue, 28 Feb 2012 16:17:56 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: csbender References: <1330392478.216.YahooMailRC@web180716.mail.sp1.yahoo.com> <4F4C8B1F.1000302@my.gd> <1330440204.54973.YahooMailRC@web180705.mail.sp1.yahoo.com> In-Reply-To: <1330440204.54973.YahooMailRC@web180705.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQluLM2Vq9IEV11YfKx8XBAjKkUfvbfKFpCKgg3nHvrAaWCBGk5oiEBrIBWzU4pNaJtGQe1u Cc: freebsd-pf@freebsd.org Subject: 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: Tue, 28 Feb 2012 15:18:00 -0000 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" > From owner-freebsd-pf@FreeBSD.ORG Tue Feb 28 18:10:04 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 15A73106566C for ; Tue, 28 Feb 2012 18:10:04 +0000 (UTC) (envelope-from csbender@bellsouth.net) Received: from nm3-vm2.bullet.mail.ne1.yahoo.com (nm3-vm2.bullet.mail.ne1.yahoo.com [98.138.91.19]) by mx1.freebsd.org (Postfix) with SMTP id B80678FC0C for ; Tue, 28 Feb 2012 18:10:03 +0000 (UTC) Received: from [98.138.90.49] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2012 17:57:19 -0000 Received: from [98.138.226.163] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 28 Feb 2012 17:57:19 -0000 Received: from [127.0.0.1] by omp1064.mail.ne1.yahoo.com with NNFMP; 28 Feb 2012 17:57:19 -0000 X-Yahoo-Newman-Id: 85501.96494.bm@omp1064.mail.ne1.yahoo.com Received: (qmail 18249 invoked from network); 28 Feb 2012 17:57:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s1024; t=1330451839; bh=vlA3mwR/3xByAigGxYTxmx1YpjZx6EEaeyvtCPEm/LU=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=M8x2ZGHpUsDo3HpcfjwLMHqkjl6DEjcDjYCmvX3gpdZvfkxTOWn4A4TTUV3+cAZ1zFEYr7YP9tL2EO4RaeQgBb2HDFQbtGAueq0hHYpHPRi2scEob7HIfHDv0CK34nMpksse3WW6XWjwKKncFHfDIkPY2odHHP0H0DyZogDHmVA= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: e7ak.AsVM1kXdrC3ox2eUs2NcDadLx7Uv0tobbvX_RMKKQk T7h0cTB2RXRxlY4dfEnEEvx7UaRLxXpjqq1FFQGnm2CR5cWnmS9Ns9ztrAEl zxoPajz1ICg4PbxxjGJu5Yi.35Ca7IxFIefitngDoHNSldtDvAtW1I2352pU sZ_RUZ8sxwcZW73b086r.6P7R90M0lMu_LYSjDoKXjZvOPqdxBcgMqjlJcty XnhjZdjomFs8Rydg0W.6sdTuE0w3PFAAqF_KgToccRRoI.mEy6qFt4VU1XYd fAkz_WH3zgklGcgnJL3d_xcoQa10Ut3xFR7kHEHZOba1WRCx9FJ0H_vOzEbL 96bQn5z3aWHvRrkL4KBFbVQF0jTRvL4J5IfKAm3YmuAkEz0Yu8OwGeT6BXeT gY2VKQDKgY9L7kr7TLtOjYt5pmQi76hFmuvWKPX5n1sSYUJCfoh3LTPQIYn8 yc5o1Huwlw970sKW1dqwdY3mPDab2oqBp5cVTmOIN58MZKqVPSHLanCTIOHv QcYT6.LgmHAHrYpVK6w-- X-Yahoo-SMTP: MtHi0xqswBBkCxhn0S2UJx6ySWsxcOv8ZDv43KGtTM7wCrk- Received: from [10.74.101.18] (csbender@198.228.232.89 with xymcookie) by smtp105-mob.biz.mail.ne1.yahoo.com with SMTP; 28 Feb 2012 09:57:18 -0800 PST 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> In-Reply-To: <4F4CF024.9000202@my.gd> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Chris Bender Date: Tue, 28 Feb 2012 12:57:13 -0500 To: Damien Fleuriot Cc: "freebsd-pf@freebsd.org" Subject: 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: Tue, 28 Feb 2012 18:10:04 -0000 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. >=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 > 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 > 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 > 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 > 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 to 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 to 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 >> 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 >> 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 >> 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 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 From owner-freebsd-pf@FreeBSD.ORG Wed Feb 29 00:24:56 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 17872106566C for ; Wed, 29 Feb 2012 00:24:56 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8EEFA8FC0A for ; Wed, 29 Feb 2012 00:24:55 +0000 (UTC) Received: by werl4 with SMTP id l4so2135777wer.13 for ; Tue, 28 Feb 2012 16:24:54 -0800 (PST) Received-SPF: pass (google.com: domain of ml@my.gd designates 10.216.134.5 as permitted sender) client-ip=10.216.134.5; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ml@my.gd designates 10.216.134.5 as permitted sender) smtp.mail=ml@my.gd Received: from mr.google.com ([10.216.134.5]) by 10.216.134.5 with SMTP id r5mr10967428wei.39.1330475094772 (num_hops = 1); Tue, 28 Feb 2012 16:24:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=5GzQidmUYUwk6vz74tNWqBq4H4cUqoT0B2wpJXB6p9Y=; b=h8X3Nx50cPsmq1BGuBjf2i7VlWcem6729v/mNfptWRr0R40n6t5rHkeODfgEF6xVTL 6Xho1hACLESDJkZQlUQrwQGz5gpf7pJBbSIyGNJcZwsVlPR7bqQzMYYmhzvTds+IdS2G fISKbFleOKNmyzUbNmi3ixCkw+/sTVZ/LIzFq6Dysfxhyx2R+irYjBUkQPljRmG3bIXX Yv3Ij3lq24M9PcHl2vvgYzAD9GlynslgAjF28vqhSSjimqn4/gLVT7AQARG9LjDzjQhP e23d64gPqEOUypsPCgSJ5CZKMNTBSOhIS5NMS86gYHo1EUTT8YG6FbhbbPXkfpuv9N+G sgWg== Received: by 10.216.134.5 with SMTP id r5mr8711633wei.39.1330475094572; Tue, 28 Feb 2012 16:24:54 -0800 (PST) Received: from [192.168.0.47] (paris.c-mal.com. [88.170.200.60]) by mx.google.com with ESMTPS id k6sm17220643wiy.7.2012.02.28.16.24.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Feb 2012 16:24:53 -0800 (PST) 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> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8J2) From: Damien Fleuriot Date: Wed, 29 Feb 2012 01:24:07 +0100 To: Chris Bender X-Gm-Message-State: ALoCoQnvw/YWJIltsifTjEBm0FCnW+bdOInCkPJClr3ZSBFDkRT9JHw78/45msyB6KMm5C1aqWF2 Cc: "freebsd-pf@freebsd.org" Subject: 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 00:24:56 -0000 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= . >=20 > Thanks >=20 > Sent from my iPhone >=20 > On Feb 28, 2012, at 10:17 AM, Damien Fleuriot 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 >> 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 >> 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 >> 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 >> 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 to 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 to 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 >>> 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 >>> 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 >>> 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 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 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" >>>