From owner-freebsd-pf@FreeBSD.ORG Sun Aug 31 17:30:05 2008 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 E4749106566B for ; Sun, 31 Aug 2008 17:30:05 +0000 (UTC) (envelope-from bw@exodus.desync.com) Received: from exodus.desync.com (desync.com [IPv6:2607:f178::165]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7438FC0A for ; Sun, 31 Aug 2008 17:30:05 +0000 (UTC) (envelope-from bw@exodus.desync.com) Received: from exodus.desync.com (localhost [127.0.0.1]) by exodus.desync.com (8.14.2/8.14.2) with ESMTP id m7VHTiuF026220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Aug 2008 13:29:44 -0400 (EDT) (envelope-from bw@exodus.desync.com) Received: (from bw@localhost) by exodus.desync.com (8.14.3/8.14.2/Submit) id m7VHThYO026219; Sun, 31 Aug 2008 13:29:43 -0400 (EDT) (envelope-from bw) Date: Sun, 31 Aug 2008 13:29:43 -0400 From: ben wilber To: Adam McDougall Message-ID: <20080831172943.GA26180@exodus.desync.com> References: <20080829105422.GI1644@exodus.desync.com> <20080829110358.GA72503@icarus.home.lan> <20080829125549.GR64444@egr.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080829125549.GR64444@egr.msu.edu> X-Angst-Level: High User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: pf and mxge 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: Sun, 31 Aug 2008 17:30:06 -0000 On Fri, Aug 29, 2008 at 08:55:49AM -0400, Adam McDougall wrote: > I've seen this problem on RELENG_6, although the SSH connections > would not "time out" -- after a page or so of 'dmesg' output, they > would immediately get disconnected/severed. I believe the problem was > caused by my use of "modulate state" instead of "keep state" (since on > RELENG_6 "keep state" is not implicit). Bingo. The problem was "modulate state". Sorry if the answer is obvious, but any idea why a new NIC might have aggravated this? In any case, thanks! bw. From owner-freebsd-pf@FreeBSD.ORG Sun Aug 31 18:06:21 2008 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 72E78106564A for ; Sun, 31 Aug 2008 18:06:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 1AEF98FC1A for ; Sun, 31 Aug 2008 18:06:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 91bH1a0090QuhwU5266Lrj; Sun, 31 Aug 2008 18:06:20 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA02.westchester.pa.mail.comcast.net with comcast id 966H1a00L4v8bD73N66JqL; Sun, 31 Aug 2008 18:06:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=HSDlHQcgYpBBZRYkYG8A:9 a=weBh9fGcv_RxS_YzsGBrbnaAL6kA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id E048717B81A; Sun, 31 Aug 2008 11:06:18 -0700 (PDT) Date: Sun, 31 Aug 2008 11:06:18 -0700 From: Jeremy Chadwick To: ben wilber Message-ID: <20080831180618.GA34269@icarus.home.lan> References: <20080829105422.GI1644@exodus.desync.com> <20080829110358.GA72503@icarus.home.lan> <20080829125549.GR64444@egr.msu.edu> <20080831172943.GA26180@exodus.desync.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080831172943.GA26180@exodus.desync.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: pf and mxge 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: Sun, 31 Aug 2008 18:06:21 -0000 On Sun, Aug 31, 2008 at 01:29:43PM -0400, ben wilber wrote: > On Fri, Aug 29, 2008 at 08:55:49AM -0400, Adam McDougall wrote: > > I've seen this problem on RELENG_6, although the SSH connections > > would not "time out" -- after a page or so of 'dmesg' output, they > > would immediately get disconnected/severed. I believe the problem was > > caused by my use of "modulate state" instead of "keep state" (since on > > RELENG_6 "keep state" is not implicit). > > Bingo. The problem was "modulate state". Sorry if the answer is > obvious, but any idea why a new NIC might have aggravated this? A new NIC wouldn't have had anything to do with the problem; it's probably always been there, or you just didn't notice it before. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Mon Sep 1 11:07:00 2008 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 2D04E1065678 for ; Mon, 1 Sep 2008 11:07:00 +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 1D4738FC30 for ; Mon, 1 Sep 2008 11:07:00 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m81B6xaS068520 for ; Mon, 1 Sep 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m81B6xJQ068516 for freebsd-pf@FreeBSD.org; Mon, 1 Sep 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Sep 2008 11:06:59 GMT Message-Id: <200809011106.m81B6xJQ068516@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, 01 Sep 2008 11:07:00 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/93825 pf [pf] pf reply-to doesn't work s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/114095 pf [carp] carp+pf delay with high state limit o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o kern/121704 pf [pf] PF mangles loopback packets o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/125467 pf [pf] pf keep state bug while handling sessions between 10 problems total. From owner-freebsd-pf@FreeBSD.ORG Tue Sep 2 17:22:04 2008 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2F29106564A for ; Tue, 2 Sep 2008 17:22:04 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-defer01.adhost.com (mail-defer01.adhost.com [216.211.128.150]) by mx1.freebsd.org (Postfix) with ESMTP id A57928FC12 for ; Tue, 2 Sep 2008 17:22:04 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-in02.adhost.com (mail-in02.adhost.com [10.212.3.12]) by mail-defer01.adhost.com (Postfix) with ESMTP id A2B5E10890 for ; Tue, 2 Sep 2008 10:06:13 -0700 (PDT) (envelope-from mksmith@adhost.com) Received: from ad-exh01.adhost.lan (exchange.adhost.com [216.211.143.69]) by mail-in02.adhost.com (Postfix) with ESMTP id 363101EE839; Tue, 2 Sep 2008 10:06:12 -0700 (PDT) (envelope-from mksmith@adhost.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 x-pgp-mapi-encoding-version: 2.5.0 x-pgp-encoding-format: MIME Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="PGP_Universal_06019E09_6709CFB9_DEE85E37_3DCBB8AB" x-pgp-encoding-version: 2.0.2 Content-class: urn:content-classes:message Date: Tue, 2 Sep 2008 10:06:12 -0700 Message-ID: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Crazy Question - IPv6 to IPv4 and vice versa thread-index: AckNHi85kJIMpMajQK2g7/oDGiL94w== From: "Michael K. Smith - Adhost" To: , Cc: Subject: Crazy Question - IPv6 to IPv4 and vice versa 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, 02 Sep 2008 17:22:04 -0000 --PGP_Universal_06019E09_6709CFB9_DEE85E37_3DCBB8AB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: QUOTED-PRINTABLE Hello All: I'm wondering if it would be possible to create a mapping between an "outsi= de" IPv6 address and an "inside" IPv4 NAT (or round-robin group, to take it= to the next logical step) or vice versa? This would be on a FreeBSD 7.0 i= nstallation. As a second note, if it's not supported now would it be possi= ble to add this support? Regards, Mike -- Michael K. Smith - CISSP, GISP Chief Technical Officer - Adhost Internet LLC mksmith@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) --PGP_Universal_06019E09_6709CFB9_DEE85E37_3DCBB8AB Content-Type: application/pgp-signature; name="PGP.sig" Content-Transfer-Encoding: 7BIT Content-Disposition: attachment; filename="PGP.sig" -----BEGIN PGP SIGNATURE----- Version: 9.9.0 (Build 397) iQEVAwUBSL1yhPTXQhZ+XcVAAQjaPwgAmHLXYGBw45tgUG8s8mC2JFU6kRq7hg8e pExH1p46Cp189ZQqkzWafxv8lJ9L6dL0cslm00XNRMaFkppodu9tJEmN+Icfz4Rh HpKOnPMphFcRh/nkLbiMlcqRppF8PfyqXU9Nnh77Q7uabOQAP4FAc1a0vD8a6FSP +g6puZkHpUYTDFt9eRHeYMD6jcs5RNPpE3q3fa2rZ5PwlkBC89rxT3swgoS5UFL2 wMqXjVlTlxdBIGqTvuMxWrBYfNNefOFhXoPwkwb9SMbuoduMreK8Jgph0HQCPRW4 RaWTjLoD1hvXnLY8S0ApjX7Tmh61AY9ZUANHI0TRbE+NF9S/UWlwkQ== =Tdzh -----END PGP SIGNATURE----- --PGP_Universal_06019E09_6709CFB9_DEE85E37_3DCBB8AB-- From owner-freebsd-pf@FreeBSD.ORG Tue Sep 2 17:43:15 2008 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57FA1106564A for ; Tue, 2 Sep 2008 17:43:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 414788FC18 for ; Tue, 2 Sep 2008 17:43:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id 9m4N1a0040mlR8UA1tTFTg; Tue, 02 Sep 2008 17:27:15 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id 9tTE1a0054v8bD78XtTEgk; Tue, 02 Sep 2008 17:27:15 +0000 X-Authority-Analysis: v=1.0 c=1 a=nVaiF5OawtgA:10 a=tOo2Lc2CiHgA:10 a=QycZ5dHgAAAA:8 a=tcutQGWVzH3oJRn2z-oA:9 a=xjrqMLmK6EfOaqOP9_lIoMYNz9MA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id D26CC17B81A; Tue, 2 Sep 2008 10:27:13 -0700 (PDT) Date: Tue, 2 Sep 2008 10:27:13 -0700 From: Jeremy Chadwick To: "Michael K. Smith - Adhost" Message-ID: <20080902172713.GA73836@icarus.home.lan> References: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: pf@freebsd.org, pf@benzedrine.cx Subject: Re: Crazy Question - IPv6 to IPv4 and vice versa 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, 02 Sep 2008 17:43:15 -0000 On Tue, Sep 02, 2008 at 10:06:12AM -0700, Michael K. Smith - Adhost wrote: > I'm wondering if it would be possible to create a mapping between an > "outside" IPv6 address and an "inside" IPv4 NAT (or round-robin group, > to take it to the next logical step) or vice versa? This would be on > a FreeBSD 7.0 installation. As a second note, if it's not supported > now would it be possible to add this support? Do you mean something like faithd(8)? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Tue Sep 2 20:03:10 2008 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54CA1106567C for ; Tue, 2 Sep 2008 20:03:10 +0000 (UTC) (envelope-from stu@spacehopper.org) Received: from pyxis.spacehopper.org (pyxis.spacehopper.org [IPv6:2a01:348:108:108:a00:20ff:feda:88b6]) by mx1.freebsd.org (Postfix) with ESMTP id 18A4A8FC20 for ; Tue, 2 Sep 2008 20:03:10 +0000 (UTC) (envelope-from stu@spacehopper.org) Received: by pyxis.spacehopper.org (Postfix, from userid 1000) id E2D83208A75; Tue, 2 Sep 2008 21:03:04 +0100 (BST) Date: Tue, 2 Sep 2008 21:03:04 +0100 From: Stuart Henderson To: "Michael K. Smith - Adhost" Message-ID: <20080902200304.GH32201@pyxis.spacehopper.org> Mail-Followup-To: "Michael K. Smith - Adhost" , pf@benzedrine.cx, pf@freebsd.org References: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> User-Agent: Mutt/1.5.18 (2008-05-17) X-MailScanner-ID: E2D83208A75.C07ED X-DMAT-MailScanner: Found to be clean X-DMAT-MailScanner-From: stu@spacehopper.org X-Spam-Status: No Cc: pf@freebsd.org, pf@benzedrine.cx Subject: Re: Crazy Question - IPv6 to IPv4 and vice versa 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, 02 Sep 2008 20:03:10 -0000 On 2008/09/02 10:06, Michael K. Smith - Adhost wrote: > I'm wondering if it would be possible to create a mapping between > an "outside" IPv6 address and an "inside" IPv4 NAT (or round-robin > group, to take it to the next logical step) or vice versa? This > would be on a FreeBSD 7.0 installation. As a second note, if it's > not supported now would it be possible to add this support? it's not possible in-kernel but on OpenBSD this is now supported in userland by relayd. There's an article about it on undeadly.org, http://undeadly.org/cgi?action=article&sid=20080724184757 however I don't know if PF on FreeBSD is at a level that can support this. From owner-freebsd-pf@FreeBSD.ORG Tue Sep 2 22:04:32 2008 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 386651065673 for ; Tue, 2 Sep 2008 22:04:32 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from charybdis.cts.cwu.edu (charybdis.cts.cwu.edu [198.104.67.152]) by mx1.freebsd.org (Postfix) with ESMTP id 18D7F8FC18 for ; Tue, 2 Sep 2008 22:04:31 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.CHARYBDIS.CTS.CWU.EDU by CHARYBDIS.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MZ37OBBSO0000CL4@CHARYBDIS.CTS.CWU.EDU> for freebsd-pf@freebsd.org; Tue, 02 Sep 2008 14:15:19 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by CHARYBDIS.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MZ37OB4JS4000D6M@CHARYBDIS.CTS.CWU.EDU> for freebsd-pf@freebsd.org; Tue, 02 Sep 2008 14:15:19 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Tue, 02 Sep 2008 14:15:18 -0700 Date: Tue, 02 Sep 2008 14:15:14 -0700 From: Gavin Spomer To: freebsd-pf@freebsd.org Message-id: <48BD4A72020000900001CC0D@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: PF is blocking inbound/outbound ssh, nothing else 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, 02 Sep 2008 22:04:32 -0000 I've recently had to leave my firewall off on my test server because when = I'm ssh-ed in and enable pf, I get "locked out". :( It was working fine = before and the only change that's happened recently is our university has = a new ip range, but I've changed that in my config. I also have a = production FreeBSD server of which I can ssh to (thankfully) with pf = enabled and it's pf.conf is virtually the same. My pf config relevant to this is:=20 #### LISTS/MACROS: ext_if =3D "bce0" #### TABLES: table const { campus ip range omitted } #### OPTIONS: set skip on lo0=20 #### NORMALIZATION: scrub in all=20 #### FILTERING: # default deny everything in and log=20 block in log on $ext_if all=20 block out log on $ext_if all=20 # activate spoofing antispoof log quick for $ext_if inet # ssh for pass in on $ext_if proto tcp from to $ext_if port 22 = flags S/SA keep state (other rules for other services/ports that are working go here) # let stuff out pass out on $ext_if proto { tcp, udp } from any to any keep state /var/log/messages shows entries like: Sep 2 10:02:27 myserver sshd[21000]: fatal: Write failed: Operation = not permitted tcpdump -n -e -ttt -r /var/log/pflog shows entries like: 32. 022410 rule 0/0(match): block in on bce0: mymacip.50186 > myserverip= .22: P 1:97(96) ack 0 win 65535 and: 2143. 098222 rule 1/0(match): block out on bce0: myserverip.22 > = mymacip.50542: P 3200122721 :3200122817(96) ack 2819997173 win 8326 = My Mac is within the defined in my tables section. Only ssh = is being blocked. Other things like port 80 for apache, port 3306 for = MySQL, port 8080 for Plone, etc. are all fine. I have searched the freebsd-pf list archives, but it only allows me one = page of search results for some reason. I have also Googled a bit and have = finally posted here. Very confused. Gavin Spomer Systems Programmer Brooks Library Central Washington University From owner-freebsd-pf@FreeBSD.ORG Tue Sep 2 22:34:24 2008 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE3CA1065685; Tue, 2 Sep 2008 22:34:24 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A5C778FC20; Tue, 2 Sep 2008 22:34:24 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m82MYO7q099100; Tue, 2 Sep 2008 22:34:24 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m82MYOi8099096; Tue, 2 Sep 2008 22:34:24 GMT (envelope-from linimon) Date: Tue, 2 Sep 2008 22:34:24 GMT Message-Id: <200809022234.m82MYOi8099096@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/127042: [pf] [patch] pf recursion panic if interface group is the same as the new interface name 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, 02 Sep 2008 22:34:24 -0000 Old Synopsis: [PATCH] pf recursion panic if interface group is the same as the new interface name New Synopsis: [pf] [patch] pf recursion panic if interface group is the same as the new interface name Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 2 22:34:07 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=127042 From owner-freebsd-pf@FreeBSD.ORG Tue Sep 2 23:23:19 2008 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 C73141065670 for ; Tue, 2 Sep 2008 23:23:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id AE6258FC0A for ; Tue, 2 Sep 2008 23:23:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id 9occ1a00A0QkzPwA5zPKyy; Tue, 02 Sep 2008 23:23:19 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id 9zPJ1a00H4v8bD78NzPJuK; Tue, 02 Sep 2008 23:23:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=8LDrtCTIhU0A:10 a=dTWVyYCy3F0A:10 a=QycZ5dHgAAAA:8 a=tLEX1HqRgUI75sGrchcA:9 a=nipifZYpyg5j5GGLMu4A:7 a=pdCD4BC4YhEzJJ70NO4z3MbUdTEA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 2F2A517B81A; Tue, 2 Sep 2008 16:23:18 -0700 (PDT) Date: Tue, 2 Sep 2008 16:23:18 -0700 From: Jeremy Chadwick To: Gavin Spomer Message-ID: <20080902232318.GA80242@icarus.home.lan> References: <48BD4A72020000900001CC0D@hermes.cwu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48BD4A72020000900001CC0D@hermes.cwu.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: PF is blocking inbound/outbound ssh, nothing else 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, 02 Sep 2008 23:23:19 -0000 On Tue, Sep 02, 2008 at 02:15:14PM -0700, Gavin Spomer wrote: > I've recently had to leave my firewall off on my test server because when I'm ssh-ed in and enable pf, I get "locked out". :( It was working fine before and the only change that's happened recently is our university has a new ip range, but I've changed that in my config. I also have a production FreeBSD server of which I can ssh to (thankfully) with pf enabled and it's pf.conf is virtually the same. > > My pf config relevant to this is: > > #### LISTS/MACROS: > ext_if = "bce0" > > #### TABLES: > table const { campus ip range omitted } > > #### OPTIONS: > set skip on lo0 > > #### NORMALIZATION: > scrub in all > > #### FILTERING: > # default deny everything in and log > block in log on $ext_if all > block out log on $ext_if all > > # activate spoofing > antispoof log quick for $ext_if inet > > # ssh for > pass in on $ext_if proto tcp from to $ext_if port 22 flags S/SA keep state > > (other rules for other services/ports that are working go here) > > # let stuff out > pass out on $ext_if proto { tcp, udp } from any to any keep state > > /var/log/messages shows entries like: > > Sep 2 10:02:27 myserver sshd[21000]: fatal: Write failed: Operation not permitted > > tcpdump -n -e -ttt -r /var/log/pflog shows entries like: > > 32. 022410 rule 0/0(match): block in on bce0: mymacip.50186 > myserverip.22: P 1:97(96) ack 0 win 65535 > > and: > > 2143. 098222 rule 1/0(match): block out on bce0: myserverip.22 > mymacip.50542: P 3200122721 :3200122817(96) ack 2819997173 win 8326 > > My Mac is within the defined in my tables section. Only ssh is being blocked. Other things like port 80 for apache, port 3306 for MySQL, port 8080 for Plone, etc. are all fine. > > I have searched the freebsd-pf list archives, but it only allows me one page of search results for some reason. I have also Googled a bit and have finally posted here. Very confused. The version of FreeBSD you're using is important here. What version? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 01:08:13 2008 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 3500710667FD for ; Wed, 3 Sep 2008 01:08:13 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from scylla.cts.cwu.edu (scylla.cts.cwu.edu [198.104.67.151]) by mx1.freebsd.org (Postfix) with ESMTP id 1CDC28FC16 for ; Wed, 3 Sep 2008 01:08:13 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.SCYLLA.CTS.CWU.EDU by SCYLLA.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MZ3FT1YSGW0004L8@SCYLLA.CTS.CWU.EDU> for freebsd-pf@freebsd.org; Tue, 02 Sep 2008 18:08:12 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by SCYLLA.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MZ3FT1MS5Y0004SH@SCYLLA.CTS.CWU.EDU> for freebsd-pf@freebsd.org; Tue, 02 Sep 2008 18:08:12 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Tue, 02 Sep 2008 18:08:11 -0700 Date: Tue, 02 Sep 2008 18:08:08 -0700 From: Gavin Spomer To: freebsd-pf@freebsd.org Message-id: <48BD8108020000900001CC4B@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: PF is blocking inbound/outbound ssh, nothing else 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, 03 Sep 2008 01:08:13 -0000 >>> Jeremy Chadwick 09/02/08 4:23 PM >>> > > The version of FreeBSD you're using is important here. What version? > >=20 > > --=20 > > | Jeremy Chadwick =20 Thanks Jeremy. It is 7.0-STABLE. How does the version make a difference? = I'd like to know; every bit of added learning is a plus for me. :) - Gavin From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 01:19:48 2008 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 3B6851066734 for ; Wed, 3 Sep 2008 01:19:48 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from donald.cts.cwu.edu (donald.cts.cwu.edu [198.104.67.147]) by mx1.freebsd.org (Postfix) with ESMTP id 2213F8FC13 for ; Wed, 3 Sep 2008 01:19:48 +0000 (UTC) (envelope-from spomerg@cwu.EDU) Received: from CONVERSION-CWU-DAEMON.DONALD.CTS.CWU.EDU by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) id <01MZ3G8E7LTS000G02@DONALD.CTS.CWU.EDU> for freebsd-pf@freebsd.org; Tue, 02 Sep 2008 18:19:47 -0700 (PDT) Received: from hermes.cwu.edu (hermes.cwu.edu [172.16.21.28]) by DONALD.CTS.CWU.EDU (PMDF V6.4 #31640) with ESMTP id <01MZ3G8DXJ80000G2H@DONALD.CTS.CWU.EDU> for freebsd-pf@freebsd.org; Tue, 02 Sep 2008 18:19:47 -0700 (PDT) Received: from cwugate1-MTA by hermes.cwu.edu with Novell_GroupWise; Tue, 02 Sep 2008 18:19:47 -0700 Date: Tue, 02 Sep 2008 18:19:43 -0700 From: Gavin Spomer To: freebsd-pf@freebsd.org Message-id: <48BD83BF020000900001CC53@hermes.cwu.edu> MIME-version: 1.0 X-Mailer: Novell GroupWise Internet Agent 7.0.3 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-disposition: inline Subject: Re: PF is blocking inbound/outbound ssh, nothing else 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, 03 Sep 2008 01:19:49 -0000 >>> Alex Trull 09/02/08 3:22 PM >>> > > Gavin, > >=20 > > Could mean you've maxed out your connection states pf=20 > >=20 > > if you've got a default amount of states, that means a 10k=20 > > state limit - check the output of the following for the=20 > > current states: > >=20 > > pfctl -s all | grep current > >=20 > > if it's at 10k or thereabouts, raise it :) Thanks Alex. It says current entries is 0. What does that mean? > > set limit { states 20000 } > >=20 > > obviously, 20000 may still be too small, see how it scales=20 > > once you've raised the limits. I tried setting it all the way to 100000. Still no change. > >=20 > > You may also have run out of source ports, but that is=20 > > another kettle of fish. What do you mean by that? If this part is not relevant to this list, could = you please email off-list, maybe point me in the right direction? If you = are referring to tcp/udp ports, I am running a LOT of stuff on this = server! > > -- > > Alex Obviously I'm still quite the newb to pf, so I'll look at some more = info... do my homework. The "pfctl -s all" is a great tip. Thanks. Looks = like lots of good info there, just need to figure out what it all means. = :) - Gavin From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 02:08:21 2008 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 2DF8D106566C for ; Wed, 3 Sep 2008 02:08:21 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.freebsd.org (Postfix) with ESMTP id B801D8FC1A for ; Wed, 3 Sep 2008 02:08:20 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-063-119.pools.arcor-ip.net [88.66.63.119]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1Kahn901TQ-0005Dc; Wed, 03 Sep 2008 04:08:19 +0200 Received: (qmail 69369 invoked from network); 3 Sep 2008 02:08:16 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 3 Sep 2008 02:08:16 -0000 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Wed, 3 Sep 2008 04:08:15 +0200 User-Agent: KMail/1.10.0 (FreeBSD/8.0-CURRENT; KDE/4.1.0; i386; ; ) References: <48BD4A72020000900001CC0D@hermes.cwu.edu> In-Reply-To: <48BD4A72020000900001CC0D@hermes.cwu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809030408.15840.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+fEm85kJPhLi8h1vqY46p2fGzaRkZQ3Mz5kbc k19E3gI51UlZZZa3/rDG3a7i26zXbClA06GhIfRzmu3vcFHz8d oNAuR6/UP0LsMztlGkWKQ== Cc: Subject: Re: PF is blocking inbound/outbound ssh, nothing else 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, 03 Sep 2008 02:08:21 -0000 On Tuesday 02 September 2008 23:15:14 Gavin Spomer wrote: > I've recently had to leave my firewall off on my test server because when > I'm ssh-ed in and enable pf, I get "locked out". :( It was working fine Are you saying that you can't connect to the box once you enable pf or that the session that was used to issue the "pfctl -e" command dies? The latter is a well-known and - I believe - well-documented problem which stems from the way how pf handles tcp-states. In short: You have an active tcp connection to your sshd, once you enable pf the packets for that connection will be dropped by pf as they 1) don't match an active state and 2) [since the connection is ongoing] don't match the "flags S/SA" setting on your rule either. Even if you remove the "flags S/SA" part you will get in trouble if you use window scaling. > before and the only change that's happened recently is our university has a > new ip range, but I've changed that in my config. I also have a production > FreeBSD server of which I can ssh to (thankfully) with pf enabled and it's > pf.conf is virtually the same. > > My pf config relevant to this is: > > #### LISTS/MACROS: > ext_if = "bce0" > > #### TABLES: > table const { campus ip range omitted } > > #### OPTIONS: > set skip on lo0 > > #### NORMALIZATION: > scrub in all > > #### FILTERING: > # default deny everything in and log > block in log on $ext_if all > block out log on $ext_if all > > # activate spoofing > antispoof log quick for $ext_if inet > > # ssh for > pass in on $ext_if proto tcp from to $ext_if port 22 > flags S/SA keep state > > (other rules for other services/ports that are working go here) > > # let stuff out > pass out on $ext_if proto { tcp, udp } from any to any keep state > > /var/log/messages shows entries like: > > Sep 2 10:02:27 myserver sshd[21000]: fatal: Write failed: Operation not > permitted > > tcpdump -n -e -ttt -r /var/log/pflog shows entries like: > > 32. 022410 rule 0/0(match): block in on bce0: mymacip.50186 > > myserverip.22: P 1:97(96) ack 0 win 65535 4199243883> > > and: > > 2143. 098222 rule 1/0(match): block out on bce0: myserverip.22 > > mymacip.50542: P 3200122721 :3200122817(96) ack 2819997173 win 8326 > > > My Mac is within the defined in my tables section. Only ssh > is being blocked. Other things like port 80 for apache, port 3306 for > MySQL, port 8080 for Plone, etc. are all fine. > > I have searched the freebsd-pf list archives, but it only allows me one > page of search results for some reason. I have also Googled a bit and have > finally posted here. Very confused. > > Gavin Spomer > Systems Programmer > Brooks Library > Central Washington University > > _______________________________________________ > 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" -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 02:27:46 2008 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 95EE9106566B for ; Wed, 3 Sep 2008 02:27:46 +0000 (UTC) (envelope-from lance@theouterdarkness.com) Received: from smtp-gw51.mailanyone.net (smtp-gw51.mailanyone.net [208.70.128.77]) by mx1.freebsd.org (Postfix) with ESMTP id 7485D8FC18 for ; Wed, 3 Sep 2008 02:27:46 +0000 (UTC) (envelope-from lance@theouterdarkness.com) Received: from mailanyone.net by smtp-gw51.mailanyone.net with esmtpa (MailAnyone extSMTP theouterdarkness.com_1591@nfsn.fuseplatform.com) id 1KahnZ-0004y0-Tp for freebsd-pf@freebsd.org; Tue, 02 Sep 2008 21:08:47 -0500 Date: Tue, 2 Sep 2008 19:08:43 -0700 From: Lance Murdock To: freebsd-pf@freebsd.org Message-ID: <20080903020843.GA70612@theouterdarkness.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: ALTQ & Multiple Connections 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, 03 Sep 2008 02:27:46 -0000 Hello, I have two Internet connections on my firewall, and a busy web server. They are both "burstable" connections, where the commit rate is much lower than the maximum connection speed. I pay a flat rate up to the commit rate, but If I go over, I get charged per mbit. One of the connections' overage rate is a lot cheaper than the other. So, what I would like to do is fill up the first connection right up to its commit rate and then dump all remaining traffic to the second connection, thus guaranteeing myself the cheapest bill at the end of the month. With ALTQ, I can see how to limit outgoing bandwidth by dropping packets, but I don't want to drop the packets, I want to force them out the other interface, as I might with pf's route-to. Is this possible with pf and ALTQ? Thanks, Lance From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 02:44:34 2008 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 80B7E106566B for ; Wed, 3 Sep 2008 02:44:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 15B638FC08 for ; Wed, 3 Sep 2008 02:44:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-063-119.pools.arcor-ip.net [88.66.63.119]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1KaiMC1I4Q-0000VW; Wed, 03 Sep 2008 04:44:33 +0200 Received: (qmail 69855 invoked from network); 3 Sep 2008 02:44:31 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 3 Sep 2008 02:44:31 -0000 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Wed, 3 Sep 2008 04:44:31 +0200 User-Agent: KMail/1.10.0 (FreeBSD/8.0-CURRENT; KDE/4.1.0; i386; ; ) References: <20080903020843.GA70612@theouterdarkness.com> In-Reply-To: <20080903020843.GA70612@theouterdarkness.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809030444.31690.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19H2tkMMR/AzU+ISiTX78flt+sgxH4xpIUFrXU IJUNrB7nErPq8fgeGi7sgAndiOkWg/AwSlO11VsF14IZJEz+DL H2WmJ8sr7n9ROXGcln5zQ== Cc: Subject: Re: ALTQ & Multiple Connections 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, 03 Sep 2008 02:44:34 -0000 On Wednesday 03 September 2008 04:08:43 Lance Murdock wrote: > I have two Internet connections on my firewall, and a busy web server. > They are both "burstable" connections, where the commit rate is much > lower than the maximum connection speed. I pay a flat rate > up to the commit rate, but If I go over, I get charged per mbit. > > One of the connections' overage rate is a lot cheaper than the other. > So, what I would like to do is fill up the first connection right up to > its commit rate and then dump all remaining traffic to the second > connection, thus guaranteeing myself the cheapest bill at the end of > the month. > > With ALTQ, I can see how to limit outgoing bandwidth by dropping packets, > but I don't want to drop the packets, I want to force them out the > other interface, as I might with pf's route-to. > > Is this possible with pf and ALTQ? No and I don't know of any software that would make that possible - probably because it's a horrible idea. You will run into all kinds of trouble with out of order packets. Let alone the issues you will have if any of your ISPs does source filtering, or with asymmetric return paths and possibly NAT. There really is no way to do what you have in mind. The only thing you can do is some level of *per-flow* round-robin (with weights) onto your outgoing connections - maybe adjusting the weights according to ALTQ usage stats. But that's a very rough estimate - but you can't do better than that, anyways. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 05:39:22 2008 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 690AE1065671 for ; Wed, 3 Sep 2008 05:39:22 +0000 (UTC) (envelope-from lance@theouterdarkness.com) Received: from smtp-gw31.mailanyone.net (smtp-gw31.mailanyone.net [208.70.128.57]) by mx1.freebsd.org (Postfix) with ESMTP id 2E1398FC2B for ; Wed, 3 Sep 2008 05:39:21 +0000 (UTC) (envelope-from lance@theouterdarkness.com) Received: from mailanyone.net by smtp-gw31.mailanyone.net with esmtpa (MailAnyone extSMTP theouterdarkness.com_1591@nfsn.fuseplatform.com) id 1Kal5M-0004OA-M4; Wed, 03 Sep 2008 00:39:20 -0500 Date: Tue, 2 Sep 2008 22:39:16 -0700 From: Lance Murdock To: Max Laier Message-ID: <20080903053916.GA81677@theouterdarkness.com> References: <20080903020843.GA70612@theouterdarkness.com> <200809030444.31690.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200809030444.31690.max@love2party.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-pf@freebsd.org Subject: Re: ALTQ & Multiple Connections 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, 03 Sep 2008 05:39:22 -0000 On Wed, Sep 03, 2008 at 04:44:31AM +0200, Max Laier wrote: > No and I don't know of any software that would make that > possible - probably because it's a horrible idea. I wouldn't say it is a horrible idea. It may have some implementation details, but the idea of maximally utilizing available resources at minimum cost is not fundamentally horrible. Also, this is for negotiation purposes as much as any technical reason. Our carriers feel there is no need to negotiate on price because they're going to get paid on the overages anyway. They figure the router and construction expenses of pulling in more fiber are pretty much a lock-in, and they're pretty much right. So I'd like to put a shot across their bow that not only do we have the power to control how much they get paid without scuttling our own site, but also we don't need to pull more fiber to do it. :-) > You will run into all kinds of trouble with out > of order packets. Let alone the issues you will have if any of > your ISPs does source filtering, or with asymmetric return paths > and possibly NAT. Source filtering and NAT are not in play here and the two endpoints are not identical but they are topologically very close so asymmetric routing impact should be minimal, especially for short-lived web connections. But yes, I can see that "sticky" behavior on a per-flow basis would be essential. Ideally we would let as much traffic as possible take its best path according to the route table and only shape the minimum necessary to meet our utilization objectives. But even I am confident I have crossed irretrievably into fantasyland at that point. I'm thinking of something along the lines of good old fashioned multilink PPP, which brought up more channels based on utilization. The only difference here is that we're not going to get protocol cooperation from the far end. > The only thing you can do is > some level of *per-flow* round-robin (with weights) onto your outgoing > connections - maybe adjusting the weights according to ALTQ usage stats. I'm sorry, I don't know enough about ALTQ to know if this is intended to be a practical suggestion. If so, where would I look for documentation? I've got the Reed book and it's been massively helpful but doesn't appear to cover the sort of crazy misuse that I have in mind. > But > that's a very rough estimate - but you can't do better than that, anyways. If we can get within, say, 10% that would be a great start. Since carrier standard is 95/5 billing, all we have to do is visibly clip the peaks on an MRTG graph to achieve our objective. Thanks, Lance From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 06:30:47 2008 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10F29106567F for ; Wed, 3 Sep 2008 06:30:47 +0000 (UTC) (envelope-from mohacsi@niif.hu) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by mx1.freebsd.org (Postfix) with ESMTP id 829B18FC13 for ; Wed, 3 Sep 2008 06:30:46 +0000 (UTC) (envelope-from mohacsi@niif.hu) Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id BFD4A84758; Wed, 3 Sep 2008 08:30:44 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ydnY4wda5xyC; Wed, 3 Sep 2008 08:30:39 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 6F7E4847A8; Wed, 3 Sep 2008 08:30:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 6E2538473E; Wed, 3 Sep 2008 08:30:39 +0200 (CEST) Date: Wed, 3 Sep 2008 08:30:39 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: "Michael K. Smith - Adhost" In-Reply-To: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> Message-ID: <20080903082619.U4624@mignon.ki.iif.hu> References: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pf@freebsd.org, pf@benzedrine.cx Subject: Re: Crazy Question - IPv6 to IPv4 and vice versa 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, 03 Sep 2008 06:30:47 -0000 On Tue, 2 Sep 2008, Michael K. Smith - Adhost wrote: > Hello All: > > I'm wondering if it would be possible to create a mapping between an > "outside" IPv6 address and an "inside" IPv4 NAT (or round-robin group, > to take it to the next logical step) or vice versa? This would be on a > FreeBSD 7.0 installation. As a second note, if it's not supported now > would it be possible to add this support? > > Regards, > > Mike use some kind of translator: 1. NAT-PT - however depracated - and not maintained the *BSD version anymore: http://mucc.mahidol.ac.th/~ccvvs/natpt-setup.html> 2. TRT - faithd(8) - TCP only 3. proxy - netcat, apache, squid etc. - might be specific to application Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > -- > Michael K. Smith - CISSP, GISP > Chief Technical Officer - Adhost Internet LLC > mksmith@adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 07:04:43 2008 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 280141065679 for ; Wed, 3 Sep 2008 07:04:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id C48DB8FC16 for ; Wed, 3 Sep 2008 07:04:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA01.westchester.pa.mail.comcast.net with comcast id A74G1a00H0cZkys5174h9z; Wed, 03 Sep 2008 07:04:41 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA10.westchester.pa.mail.comcast.net with comcast id A74g1a0044v8bD73W74gtZ; Wed, 03 Sep 2008 07:04:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=QycZ5dHgAAAA:8 a=22ESKCYL5MeWPcSjsXIA:9 a=w4ftKjcunCHXHVKsAHsA:7 a=qfs-5QRkfr3ihRJkfCDDwGsnSRAA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 18E8217B81A; Wed, 3 Sep 2008 00:04:40 -0700 (PDT) Date: Wed, 3 Sep 2008 00:04:40 -0700 From: Jeremy Chadwick To: Lance Murdock Message-ID: <20080903070440.GA28260@icarus.home.lan> References: <20080903020843.GA70612@theouterdarkness.com> <200809030444.31690.max@love2party.net> <20080903053916.GA81677@theouterdarkness.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080903053916.GA81677@theouterdarkness.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: ALTQ & Multiple Connections 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, 03 Sep 2008 07:04:43 -0000 On Tue, Sep 02, 2008 at 10:39:16PM -0700, Lance Murdock wrote: > On Wed, Sep 03, 2008 at 04:44:31AM +0200, Max Laier wrote: > > No and I don't know of any software that would make that > > possible - probably because it's a horrible idea. > > I wouldn't say it is a horrible idea. It may have some implementation > details, but the idea of maximally utilizing available resources at > minimum cost is not fundamentally horrible. > > Also, this is for negotiation purposes as much as any technical reason. > Our carriers feel there is no need to negotiate on price because they're > going to get paid on the overages anyway. They figure the router and > construction expenses of pulling in more fiber are pretty much a lock-in, > and they're pretty much right. So I'd like to put a shot across > their bow that not only do we have the power to control how much they > get paid without scuttling our own site, but also we don't need to pull > more fiber to do it. :-) If I understand your situation correctly, you pay for a connection to two different peering providers or LECs, and the bandwidth (likely 95th-percentile) that you're billed against is different per provider (e.g. Provider ABC gives you a gigE port with 4mbit/sec 95th-percentile for X dollars a month, while provider XYZ gives you a gigE port with 512kbit/sec 95th-percentile for X dollars a month). Is this correct? If so, I'm not even sure commercial routers (e.g. Junipers) can solve your predicament. Ideally you'd be better off with symmetric bandwidth amounts to both of your peers (e.g. you pay both Provider ABC and Provider XYZ for 4mbit/95th of traffic). In that situation, you might be able to used a "load-balanced" solution for packets, which *might* work and meet your needs. I say "might" because Internet routing does not guarantee you'll be using both connections 50/50. I'm not sure why people think that; it really doesn't work that way in practise. Assuming the two ISPs are different and you have different IPs per peer, you're screwed. BGP preferencing and route priority will ensure you probably will not utilise each connection equally. My comment applies to incoming traffic, not outbound. Outbound you can preference/balance at your leisure, as Max described. > Ideally we would let as much traffic as possible take its best path > according to the route table and only shape the minimum necessary > to meet our utilization objectives. But even I am confident I have > crossed irretrievably into fantasyland at that point. Like I said: why do you think the rest of the world will adhere to what your routing table prefers? This is one of the common caveats to BGP. Just because you preference a route through provider ABC doesn't mean some ISP in Malaysia is going to honour that preference. I deal with this situation at my day job on a daily basis. > I'm thinking of something along the lines of good old fashioned > multilink PPP, which brought up more channels based on utilization. > The only difference here is that we're not going to get protocol > cooperation from the far end. Okay, so multilink PPP implies that you're able to get at least some sort of common IP block assigned to you through both peers, and get both peers to comply with your routing policies? Let me know if you manage to do that, as I'd be interesting in knowing what providers are *that* flexible. > > The only thing you can do is > > some level of *per-flow* round-robin (with weights) onto your outgoing > > connections - maybe adjusting the weights according to ALTQ usage stats. > > I'm sorry, I don't know enough about ALTQ to know if this is intended to > be a practical suggestion. If so, where would I look for documentation? > I've got the Reed book and it's been massively helpful but doesn't > appear to cover the sort of crazy misuse that I have in mind. > > > But > > that's a very rough estimate - but you can't do better than that, anyways. > > If we can get within, say, 10% that would be a great start. Since carrier > standard is 95/5 billing, all we have to do is visibly clip the peaks on > an MRTG graph to achieve our objective. See above. I'm pretty sure I understand your predicament, and if I was in your shoes, I'd be dropping my contract with the provider who provides less bandwidth (or costs more) and urging the other provider to provide more reliable redundancy and peering. I've personally been in that situation, though with only one provider used at the time. We pulled our entire infrastructure out of their datacenter one we found out they had no form of switch or router failover/redundancy, and that despite being in California, they were using Telia (a Swedish ISP) to peer with large carriers like AT&T and MCI. Telia connection dies? No failover available, and Telia has no NOC in the US. "Hallo dis Telia NOC" "Talar du Engelska?" "Nej" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 11:28:53 2008 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 D5AEF1065676 for ; Wed, 3 Sep 2008 11:28:53 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.95.154.195]) by mx1.freebsd.org (Postfix) with ESMTP id 475CD8FC14 for ; Wed, 3 Sep 2008 11:28:53 +0000 (UTC) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id D63E242D821; Wed, 3 Sep 2008 13:09:43 +0200 (CEST) Date: Wed, 3 Sep 2008 13:09:43 +0200 From: Guido van Rooij To: freebsd-pf@freebsd.org Message-ID: <20080903110943.GA25396@gvr.gvr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: keeping state on outgoing connections 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, 03 Sep 2008 11:28:53 -0000 Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. ep0: 1.2.3.4/24 bge0: 10.0.0.1/24 ruleset (made as simple as possible): pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 block drop out log quick on ep0 all pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 and passes because of rule 1. Then the packet goes out via bge0, is passed via rule 3 and a satte entry is created. The return SYN/ACK comes in via bge0 and passes because of the state entry. Then the packet should be sent out via ep0, but it is blocked, as pflogd shows: 000000 rule 1/0(match): block out on ep0: 10.0.0.2.25 > 1.2.3.1.1040: S 3255603624:3255603624(0) ack 3600825196 win 65535 2. 955997 rule 1/0(match): block out on ep0: 10.0.0.2.25 > 1.2.3.1.1040: S 3255603624:3255603624(0) ack 3600825196 win 65535 2. 999812 rule 1/0(match): block out on ep0: 10.0.0.2.25 > 1.2.3.1.1040: S 3255603624:3255603624(0) ack 3600825196 win 65535 3. 009226 rule 1/0(match): block out on ep0: 10.0.0.2.25 > 1.2.3.1.1040: S 3255603624:3255603624(0) ack 3600825196 win 65535 5. 999234 rule 1/0(match): block out on ep0: 10.0.0.2.25 > 1.2.3.1.1040: S 3255603624:3255603624(0) ack 3600825196 win 65535 A tcpdump of the relevant packets (bad checksum because of chaecksum ofloading): 13:05:39.471200 IP (tos 0x0, ttl 127, id 195, offset 0, flags [DF], proto: TCP (6), length: 48, bad cksum 0 (->ed00)!) 1.2.3.1.1040 > 10.0.0.2.25: S, cksum 0x62e5 (correct), 3600825195:3600825195(0) win 64512 13:05:39.471378 IP (tos 0x0, ttl 64, id 37525, offset 0, flags [DF], proto: TCP (6), length: 48) 10.0.0.2.25 > 1.2.3.1.1040: S, cksum 0x0c21 (correct), 3255603624:3255603624(0) ack 3600825196 win 65535 13:05:42.427163 IP (tos 0x0, ttl 127, id 196, offset 0, flags [DF], proto: TCP (6), length: 48, bad cksum 0 (->ecff)!) 1.2.3.1.1040 > 10.0.0.2.25: S, cksum 0x62e5 (correct), 3600825195:3600825195(0) win 64512 13:05:42.427377 IP (tos 0x0, ttl 64, id 37593, offset 0, flags [none], proto: TCP (6), length: 48) 10.0.0.2.25 > 1.2.3.1.1040: S, cksum 0x0c21 (correct), 3255603624:3255603624(0) ack 3600825196 win 65535 13:05:45.427182 IP (tos 0x0, ttl 64, id 39074, offset 0, flags [none], proto: TCP (6), length: 48) 10.0.0.2.25 > 1.2.3.1.1040: S, cksum 0x0c21 (correct), 3255603624:3255603624(0) ack 3600825196 win 65535 13:05:48.436285 IP (tos 0x0, ttl 127, id 197, offset 0, flags [DF], proto: TCP (6), length: 48, bad cksum 0 (->ecfe)!) 1.2.3.1.1040 > 10.0.0.2.25: S, cksum 0x62e5 (correct), 3600825195:3600825195(0) win 64512 13:05:48.436418 IP (tos 0x0, ttl 64, id 45408, offset 0, flags [none], proto: TCP (6), length: 48) 10.0.0.2.25 > 1.2.3.1.1040: S, cksum 0x0c21 (correct), 3255603624:3255603624(0) ack 3600825196 win 65535 13:05:54.435645 IP (tos 0x0, ttl 64, id 48287, offset 0, flags [none], proto: TCP (6), length: 48) 10.0.0.2.25 > 1.2.3.1.1040: S, cksum 0x0c21 (correct), 3255603624:3255603624(0) ack 3600825196 win 65535 pfctl -si before telnetting: State Table Total Rate current entries 0 searches 0 0.0/s inserts 0 0.0/s removals 0 0.0/s Counters match 0 0.0/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s After telnetting: State Table Total Rate current entries 1 searches 44 1.8/s inserts 1 0.0/s removals 0 0.0/s Counters match 32 1.3/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s The state entry (pfctl -vvvs state): self tcp 1.2.3.1:1040 -> 10.0.0.2:25 ESTABLISHED:SYN_SENT [3600825196 + 65535] [3255603625 + 64512] age 00:00:22, expires in 00:00:23, 8:5 pkts, 424:240 bytes, rule 2 id: 48be58f800000009 creatorid: 89adbe9b pfctl -vvvvs rules before the telnet: @0 pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @1 block drop out log quick on ep0 all [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @2 pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] and after: @0 pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 [ Evaluations: 32 Packets: 3 Bytes: 144 States: 0 ] @1 block drop out log quick on ep0 all [ Evaluations: 5 Packets: 5 Bytes: 240 States: 0 ] @2 pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state [ Evaluations: 24 Packets: 13 Bytes: 664 States: 1 ] I would expect the packet to match the state entry, but somehow it does not. Setting the state-policy to if-bound or floating makes no difference. My question is why the packet does not match the state entry resulting to its blocking. -Guido From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 12:54:08 2008 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 8E944106567F for ; Wed, 3 Sep 2008 12:54:08 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.95.154.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE028FC21 for ; Wed, 3 Sep 2008 12:54:08 +0000 (UTC) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 60C9942D823; Wed, 3 Sep 2008 14:54:07 +0200 (CEST) Date: Wed, 3 Sep 2008 14:54:07 +0200 From: Guido van Rooij To: Jon Radel Message-ID: <20080903125407.GA27232@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48BE864C.6000006@radel.com> Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 12:54:08 -0000 On Wed, Sep 03, 2008 at 08:42:52AM -0400, Jon Radel wrote: > Guido van Rooij wrote: > > > > Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. > > > > ep0: 1.2.3.4/24 > > bge0: 10.0.0.1/24 > > > > ruleset (made as simple as possible): > > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 > > block drop out log quick on ep0 all > > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > > > When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 > > and passes because of rule 1. > > Then the packet goes out via bge0, is passed via rule 3 and a satte entry is > > created. > > > > The return SYN/ACK comes in via bge0 and passes because of the state entry. > > > > Then the packet should be sent out via ep0, but it is blocked, as pflogd shows: > > And does the problem go away when you put a "keep state" at the end of > line 1? > I don't know. Due to the nature of the setup, that is not an option (like I posted in the original mail, this is a very simplistic ruleset; the real life situation will be a 5-interface setup with a lot more complexity. Being able to set state on outgoing packets is crucial). I did test the folowing ruleset: pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state block drop out log quick on ep0 all pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 And there it works, but doesn't solve my problem unfrotunately. -Guido From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 13:25:25 2008 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 2D9D0106566C for ; Wed, 3 Sep 2008 13:25:25 +0000 (UTC) (envelope-from jon@radel.com) Received: from wave.radel.com (wave.radel.com [216.143.151.4]) by mx1.freebsd.org (Postfix) with ESMTP id CF2A48FC12 for ; Wed, 3 Sep 2008 13:25:24 +0000 (UTC) (envelope-from jon@radel.com) Received: by wave.radel.com (CommuniGate Pro PIPE 4.1.6) with PIPE id 7915580; Wed, 03 Sep 2008 09:25:24 -0400 Received: from [192.168.43.221] (account jon@radel.com HELO braeburn.local) by wave.radel.com (CommuniGate Pro SMTP 4.1.6) with ESMTP-TLS id 7915578; Wed, 03 Sep 2008 09:25:12 -0400 Message-ID: <48BE9038.8020303@radel.com> Date: Wed, 03 Sep 2008 09:25:12 -0400 From: Jon Radel User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Guido van Rooij References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> In-Reply-To: <20080903125407.GA27232@gvr.gvr.org> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060103070501030507060000" X-Radel.com-MailScanner-Information: Please contact Jon for more information X-Radel.com-MailScanner: Found to be clean X-Mailer: CommuniGate Pro CLI mailer Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 13:25:25 -0000 This is a cryptographically signed message in MIME format. --------------ms060103070501030507060000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Guido van Rooij wrote: > On Wed, Sep 03, 2008 at 08:42:52AM -0400, Jon Radel wrote: >> Guido van Rooij wrote: >>> Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. >>> >>> ep0: 1.2.3.4/24 >>> bge0: 10.0.0.1/24 >>> >>> ruleset (made as simple as possible): >>> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 >>> block drop out log quick on ep0 all >>> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state >>> >>> When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 >>> and passes because of rule 1. >>> Then the packet goes out via bge0, is passed via rule 3 and a satte entry is >>> created. >>> >>> The return SYN/ACK comes in via bge0 and passes because of the state entry. >>> >>> Then the packet should be sent out via ep0, but it is blocked, as pflogd shows: >> And does the problem go away when you put a "keep state" at the end of >> line 1? >> > > I don't know. Due to the nature of the setup, that is not an option (like > I posted in the original mail, this is a very simplistic ruleset; the > real life situation will be a 5-interface setup with a lot more > complexity. Being able to set state on outgoing packets is crucial). > > I did test the folowing ruleset: > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state > block drop out log quick on ep0 all > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 > > And there it works, but doesn't solve my problem unfrotunately. And why doesn't it solve your problem? You really are going to have to either keep state on ep0 or allow everything that's legal in "pass out on ep0" statements. For example: block all pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 pass out on ep0 inet from 10.0.0.2 to 1.2.3.1 pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state --Jon Radel --------------ms060103070501030507060000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJMTCC AvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTkyMVoX DTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9tYXMx GTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRlbC5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx87Rf 0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF9qJ9 z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGbhHVv eAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw1ujk Rlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezri+BN kgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRlbC5j b20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQIWYb 5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpqZ3iA /PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQpoZSZ jzCCAvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTky MVoXDTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9t YXMxGTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRl bC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx 87Rf0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF 9qJ9z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGb hHVveAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw 1ujkRlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezr i+BNkgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRl bC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQ IWYb5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpq Z3iA/PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQp oZSZjzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQq E88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEA AaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcN AQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNw PP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq72 6jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQbZOR8X/3dLH0sJ+2vLUPdjAJ BgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODA5MDMxMzI1MTJaMCMGCSqGSIb3DQEJBDEWBBTMu4bCr1ewJI6dK8kO+AJFUytMXzBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1 D3YwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEBBQAEggEAgi0e rFqZc4Ift+fGFZseLED3N0d21HfFGKL5KDexR/8R2SqkfGaAyKKHFNGlL7JoPE5ZxGninLqd L9rLPW377Fgl0/AKRLe/MdRS7IRstPvlluO6ioX9/sg4GNZi1FH2YEzZC8K1aMrk9Oghk5X1 DoXt+CAPNnYGfI/YNEZsTb9TlrgEF5dAPTq4puSE5GqaPwDbk8NXNc0SmaBgmWoJfWbTxI7O IP/o3LxIkQoXRQHO4boSVukbN8UAwHFKeOlogSSfDPMvZlF6j/kehMKr288yrZ0+hjFwzIT0 8mhEDmr4Zn3QnTM5S4iPoh3gBumbmuwCWwc/JQShssICEevlEAAAAAAAAA== --------------ms060103070501030507060000-- From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 13:43:10 2008 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 76F261065673 for ; Wed, 3 Sep 2008 13:43:10 +0000 (UTC) (envelope-from jon@radel.com) Received: from wave.radel.com (wave.radel.com [216.143.151.4]) by mx1.freebsd.org (Postfix) with ESMTP id 26C438FC14 for ; Wed, 3 Sep 2008 13:43:09 +0000 (UTC) (envelope-from jon@radel.com) Received: by wave.radel.com (CommuniGate Pro PIPE 4.1.6) with PIPE id 7915444; Wed, 03 Sep 2008 08:43:09 -0400 Received: from [192.168.43.221] (account jon@radel.com HELO braeburn.local) by wave.radel.com (CommuniGate Pro SMTP 4.1.6) with ESMTP-TLS id 7915440; Wed, 03 Sep 2008 08:42:52 -0400 Message-ID: <48BE864C.6000006@radel.com> Date: Wed, 03 Sep 2008 08:42:52 -0400 From: Jon Radel User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Guido van Rooij References: <20080903110943.GA25396@gvr.gvr.org> In-Reply-To: <20080903110943.GA25396@gvr.gvr.org> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080208090108080008010202" X-Radel.com-MailScanner-Information: Please contact Jon for more information X-Radel.com-MailScanner: Found to be clean X-Mailer: CommuniGate Pro CLI mailer Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 13:43:10 -0000 This is a cryptographically signed message in MIME format. --------------ms080208090108080008010202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Guido van Rooij wrote: > > Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. > > ep0: 1.2.3.4/24 > bge0: 10.0.0.1/24 > > ruleset (made as simple as possible): > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 > block drop out log quick on ep0 all > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 > and passes because of rule 1. > Then the packet goes out via bge0, is passed via rule 3 and a satte entry is > created. > > The return SYN/ACK comes in via bge0 and passes because of the state entry. > > Then the packet should be sent out via ep0, but it is blocked, as pflogd shows: And does the problem go away when you put a "keep state" at the end of line 1? --Jon Radel --------------ms080208090108080008010202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJMTCC AvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTkyMVoX DTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9tYXMx GTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRlbC5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx87Rf 0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF9qJ9 z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGbhHVv eAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw1ujk Rlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezri+BN kgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRlbC5j b20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQIWYb 5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpqZ3iA /PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQpoZSZ jzCCAvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTky MVoXDTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9t YXMxGTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRl bC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx 87Rf0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF 9qJ9z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGb hHVveAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw 1ujkRlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezr i+BNkgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRl bC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQ IWYb5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpq Z3iA/PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQp oZSZjzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQq E88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEA AaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcN AQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNw PP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq72 6jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQbZOR8X/3dLH0sJ+2vLUPdjAJ BgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODA5MDMxMjQyNTJaMCMGCSqGSIb3DQEJBDEWBBQPhmya4hbjEBOUnI21AUKg9ozehTBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1 D3YwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEBBQAEggEAm8Q3 f04CyeviSp3JZchKdb1byxHei3ZqkFfE3c5dojegAxkxmCFU6zJMt6eu7l3YTEMk4Aq2woet zACPJ/L6RILlYKPRAo70CsRx7x7svanQ6HLEdbwZb8L6L7egPKImh8Xk1oAvDnXV2K8V5EY8 gzKd3cDg0P5FxpztW6SJd2ELTnjLuL6HKBfumtIJqHtKKHQAvLmVwP19Mxxdk6tPEUDgYpv4 a8ZO3/JHCTscCOjw6k9K+DAop/MO2P3Mht5v4NU/imVJ5UkBSKYXNAd7RVMdPZFtXRzCD6YB sjGwsIHpAGUFTlm7qmDBp2tpgV2jJHB2muBLoragiR8x6WHeqAAAAAAAAA== --------------ms080208090108080008010202-- From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 13:52:05 2008 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 9A3C2106566C for ; Wed, 3 Sep 2008 13:52:05 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.95.154.195]) by mx1.freebsd.org (Postfix) with ESMTP id 5977E8FC13 for ; Wed, 3 Sep 2008 13:52:05 +0000 (UTC) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id B2C9342D83E; Wed, 3 Sep 2008 15:52:04 +0200 (CEST) Date: Wed, 3 Sep 2008 15:52:04 +0200 From: Guido van Rooij To: Jon Radel Message-ID: <20080903135204.GA28111@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48BE9038.8020303@radel.com> Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 13:52:05 -0000 On Wed, Sep 03, 2008 at 09:25:12AM -0400, Jon Radel wrote: > > > > I did test the folowing ruleset: > > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state > > block drop out log quick on ep0 all > > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 > > > > And there it works, but doesn't solve my problem unfrotunately. > > And why doesn't it solve your problem? > > You really are going to have to either keep state on ep0 or allow > everything that's legal in "pass out on ep0" statements. > > For example: > > block all > pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 > pass out on ep0 inet from 10.0.0.2 to 1.2.3.1 > pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > And why is that so? This bascially rules out keep state on outgouing packets on any router-type system. That seems like an unnecessary limitation. I have not yet heart any reason why this is the case. pf was modelled after ipf, so I wonder why this change in state handling was introduced. -Guido From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 14:13:25 2008 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 23B6C106567B for ; Wed, 3 Sep 2008 14:13:25 +0000 (UTC) (envelope-from jon@radel.com) Received: from wave.radel.com (wave.radel.com [216.143.151.4]) by mx1.freebsd.org (Postfix) with ESMTP id C674C8FC1D for ; Wed, 3 Sep 2008 14:13:24 +0000 (UTC) (envelope-from jon@radel.com) Received: by wave.radel.com (CommuniGate Pro PIPE 4.1.6) with PIPE id 7915722; Wed, 03 Sep 2008 10:13:24 -0400 Received: from [192.168.43.221] (account jon@radel.com HELO braeburn.local) by wave.radel.com (CommuniGate Pro SMTP 4.1.6) with ESMTP-TLS id 7915720; Wed, 03 Sep 2008 10:13:09 -0400 Message-ID: <48BE9B74.90404@radel.com> Date: Wed, 03 Sep 2008 10:13:08 -0400 From: Jon Radel User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Guido van Rooij References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> In-Reply-To: <20080903135204.GA28111@gvr.gvr.org> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060608060201000406050905" X-Radel.com-MailScanner-Information: Please contact Jon for more information X-Radel.com-MailScanner: Found to be clean X-Mailer: CommuniGate Pro CLI mailer Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 14:13:25 -0000 This is a cryptographically signed message in MIME format. --------------ms060608060201000406050905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Guido van Rooij wrote: > On Wed, Sep 03, 2008 at 09:25:12AM -0400, Jon Radel wrote: >>> I did test the folowing ruleset: >>> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state >>> block drop out log quick on ep0 all >>> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 >>> >>> And there it works, but doesn't solve my problem unfrotunately. >> And why doesn't it solve your problem? >> >> You really are going to have to either keep state on ep0 or allow >> everything that's legal in "pass out on ep0" statements. >> >> For example: >> >> block all >> pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 >> pass out on ep0 inet from 10.0.0.2 to 1.2.3.1 >> pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state >> > > And why is that so? This bascially rules out keep state on outgouing packets > on any router-type system. That seems like an unnecessary limitation. What? If you want state, turn it on: block all pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state should work fine also. Other things being equal (in other words, your mileage may vary....), that is both more secure and more efficient than the first rule set I offered as an example. I sent the first one only because you insisted that your real rule set for 5 interfaces would not allow you to maintain state on ep0 (or its equivalent). You still haven't given us any hints as to why the solution which maintains state on all interfaces is impossible for you. > > I have not yet heart any reason why this is the case. pf was modelled > after ipf, so I wonder why this change in state handling was introduced. This is probably the wrong list if you want to have people justify design decisions. --Jon Radel --------------ms060608060201000406050905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJMTCC AvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTkyMVoX DTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9tYXMx GTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRlbC5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx87Rf 0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF9qJ9 z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGbhHVv eAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw1ujk Rlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezri+BN kgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRlbC5j b20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQIWYb 5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpqZ3iA /PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQpoZSZ jzCCAvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTky MVoXDTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9t YXMxGTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRl bC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx 87Rf0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF 9qJ9z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGb hHVveAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw 1ujkRlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezr i+BNkgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRl bC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQ IWYb5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpq Z3iA/PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQp oZSZjzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQq E88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEA AaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcN AQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNw PP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq72 6jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQbZOR8X/3dLH0sJ+2vLUPdjAJ BgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODA5MDMxNDEzMDhaMCMGCSqGSIb3DQEJBDEWBBT8Lodn7L2jHSpMJ08Fux8HKl+mxjBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1 D3YwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEBBQAEggEAjfJk KJHCwYJxreHkntILnXR9Ws5QbisF4nFaln8EL3zP4xxm2Y7bm5HB4I9ycc3coge0CpgSRmN4 0oS4va3fXMfD9XwgOQFwAP52/WjHrZbgjOxOQzdZ7bgAsOoGDozRIlNx1sViTOp8G6iLGdx1 mtdJaWO93bdmGWu0aFA2rCVjIi8jm2tjrQKiDnsTYuldngEu0zriLbZx4p9DJxkl5ooN1pNr PI+JDfJ315ECxYS9Y0zs8ElIuYxgCXYsHv3hIAKUO/FpicN51Ju2u8wT8Wb2edbPYWz0XXgY aJyBxQYQ7q30/GCTdbGdGdLIOJPYnpxupu45kxvc6aIFHzCvMgAAAAAAAA== --------------ms060608060201000406050905-- From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 14:42:39 2008 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 93788106564A for ; Wed, 3 Sep 2008 14:42:39 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.95.154.195]) by mx1.freebsd.org (Postfix) with ESMTP id 50D708FC15 for ; Wed, 3 Sep 2008 14:42:39 +0000 (UTC) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id EA41C42D83E; Wed, 3 Sep 2008 16:42:37 +0200 (CEST) Date: Wed, 3 Sep 2008 16:42:37 +0200 From: Guido van Rooij To: Jon Radel Message-ID: <20080903144237.GA28697@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> <48BE9B74.90404@radel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48BE9B74.90404@radel.com> Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 14:42:39 -0000 On Wed, Sep 03, 2008 at 10:13:08AM -0400, Jon Radel wrote: > > And why is that so? This bascially rules out keep state on outgouing packets > > on any router-type system. That seems like an unnecessary limitation. > > What? If you want state, turn it on: > > block all > pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state > pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > should work fine also. Other things being equal (in other words, your > mileage may vary....), that is both more secure and more efficient than > the first rule set I offered as an example. I sent the first one only It's certianly not more efficient as one needs twice as many state entries. > because you insisted that your real rule set for 5 interfaces would not > allow you to maintain state on ep0 (or its equivalent). Suppose I want to limit traffic to 10.0.0.2 which is behind bge0. Then when solving this with keeping state on outgoing packets on bge0 means a single rule. With your suggestion, the amount of rules is five times as big because then I need to add keep state rules for incoming packets on the other interfaces as well. > > You still haven't given us any hints as to why the solution which > maintains state on all interfaces is impossible for you. Like with the ruleset you posted, a single keep state rule is sufficient. > > > > > I have not yet heart any reason why this is the case. pf was modelled > > after ipf, so I wonder why this change in state handling was introduced. > > This is probably the wrong list if you want to have people justify > design decisions. > I honestly don't think this was a design decison, but a bug in pf. Like I said, the state engine was modelled after ipf's (hack, the whole TCP-sepcifics came from a paper I wrote), which behaves exactly similar as pf, _except_ for this specific scenario. So it shure smells like a bug. Please try to undeerstand my question: the question is not: how do I work around a failing ruleset. The question is: why doesn't it work. -Guido From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 14:44:05 2008 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 805801065672 for ; Wed, 3 Sep 2008 14:44:05 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.95.154.195]) by mx1.freebsd.org (Postfix) with ESMTP id 401318FC08 for ; Wed, 3 Sep 2008 14:44:05 +0000 (UTC) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 61BEB42D840; Wed, 3 Sep 2008 16:44:04 +0200 (CEST) Date: Wed, 3 Sep 2008 16:44:04 +0200 From: Guido van Rooij To: Artis Caune Message-ID: <20080903144404.GB28697@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> <48BE9B74.90404@radel.com> <9e20d71e0809030732v2d202cc5x74a33977d8d9ac64@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9e20d71e0809030732v2d202cc5x74a33977d8d9ac64@mail.gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 14:44:05 -0000 On Wed, Sep 03, 2008 at 05:32:25PM +0300, Artis Caune wrote: > >>>> I did test the folowing ruleset: > >>>> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state > >>>> block drop out log quick on ep0 all > >>>> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 > > maybe "set skip on ep0" ? > Nope. There will be outgoing keep state rules on ep0. But not fro connections which are already in the state table. besides the skip would roll out all incoming rules as well. -Guido From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 14:54:00 2008 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 383141065671 for ; Wed, 3 Sep 2008 14:54:00 +0000 (UTC) (envelope-from lance@theouterdarkness.com) Received: from smtp-gw47.mailanyone.net (smtp-gw47.mailanyone.net [208.70.128.73]) by mx1.freebsd.org (Postfix) with ESMTP id 0D0728FC14 for ; Wed, 3 Sep 2008 14:53:59 +0000 (UTC) (envelope-from lance@theouterdarkness.com) Received: from mailanyone.net by smtp-gw47.mailanyone.net with esmtpa (MailAnyone extSMTP theouterdarkness.com_1591@nfsn.fuseplatform.com) id 1Katk6-0006M9-Sp; Wed, 03 Sep 2008 09:53:59 -0500 Date: Wed, 3 Sep 2008 07:53:57 -0700 From: Lance Murdock To: Jeremy Chadwick Message-ID: <20080903145357.GA90983@theouterdarkness.com> References: <20080903020843.GA70612@theouterdarkness.com> <200809030444.31690.max@love2party.net> <20080903053916.GA81677@theouterdarkness.com> <20080903070440.GA28260@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080903070440.GA28260@icarus.home.lan> User-Agent: Mutt/1.4.2.3i Cc: freebsd-pf@freebsd.org Subject: Re: ALTQ & Multiple Connections 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, 03 Sep 2008 14:54:00 -0000 On Wed, Sep 03, 2008 at 12:04:40AM -0700, Jeremy Chadwick wrote: > My comment applies to incoming traffic, not outbound. We have a web site. We're not even a little bit interested in shaping inbound traffic. It's 1/10th of outbound, if that, and can be entirely disregarded, as we're happy to let that traffic always take the BGP-chosen path. > Outbound you can > preference/balance at your leisure, as Max described. Right, and that's all we're trying to figure out how to do. Lance From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 14:55:49 2008 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 224EB1065692 for ; Wed, 3 Sep 2008 14:55:49 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id C2D648FC1C for ; Wed, 3 Sep 2008 14:55:48 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: by an-out-0708.google.com with SMTP id b33so450979ana.13 for ; Wed, 03 Sep 2008 07:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=zXLDHCVq8/egofP7TdevbYEW288L6dkhU3EDt8brAS4=; b=YVYQl885fsaXPpTLyuzm9VrAYfaQ0IID3qhJQjiUjLUtvRUh1vwr/p4WSKfVJ9CXoW GhhiC9yurK/SeQfhsQIpdt3zoZjvTLjvsMYgBap9henRHtQtg7UF9JTi6l617HZRo+5P KQryhYzQMUY7GFgBsN++0+9RpUgbObY1GCTLk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=XP6QipeOd4G87Hobj7bddJ3lXTgRSj5ad58pLPLXvWoaStvcDIVEkz3DAJmhTvsCUg +vy7FZ3oJ/cwAUYzHLd6NJg93va0+03jd3BmMFmneVe1Iyu0qqqKSmWQEfe7SnjPPo9i fvEDYxcIj3HEMt8SvxDTkOhBE1odW5VZ/5SHE= Received: by 10.100.247.14 with SMTP id u14mr9068586anh.92.1220452345577; Wed, 03 Sep 2008 07:32:25 -0700 (PDT) Received: by 10.100.253.17 with HTTP; Wed, 3 Sep 2008 07:32:25 -0700 (PDT) Message-ID: <9e20d71e0809030732v2d202cc5x74a33977d8d9ac64@mail.gmail.com> Date: Wed, 3 Sep 2008 17:32:25 +0300 From: "Artis Caune" To: "Guido van Rooij" In-Reply-To: <48BE9B74.90404@radel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> <48BE9B74.90404@radel.com> Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 14:55:49 -0000 >>>> I did test the folowing ruleset: >>>> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state >>>> block drop out log quick on ep0 all >>>> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 maybe "set skip on ep0" ? -- regards, Artis Caune <----. CCNA <----|==================== <----' didii FreeBSD From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 15:08:25 2008 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 47270106564A for ; Wed, 3 Sep 2008 15:08:25 +0000 (UTC) (envelope-from jon@radel.com) Received: from wave.radel.com (wave.radel.com [216.143.151.4]) by mx1.freebsd.org (Postfix) with ESMTP id E94688FC0A for ; Wed, 3 Sep 2008 15:08:24 +0000 (UTC) (envelope-from jon@radel.com) Received: by wave.radel.com (CommuniGate Pro PIPE 4.1.6) with PIPE id 7915884; Wed, 03 Sep 2008 11:08:24 -0400 Received: from [192.168.43.221] (account jon@radel.com HELO braeburn.local) by wave.radel.com (CommuniGate Pro SMTP 4.1.6) with ESMTP-TLS id 7915882; Wed, 03 Sep 2008 11:08:17 -0400 Message-ID: <48BEA861.5050601@radel.com> Date: Wed, 03 Sep 2008 11:08:17 -0400 From: Jon Radel User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Guido van Rooij References: <20080903110943.GA25396@gvr.gvr.org> <48BE864C.6000006@radel.com> <20080903125407.GA27232@gvr.gvr.org> <48BE9038.8020303@radel.com> <20080903135204.GA28111@gvr.gvr.org> <48BE9B74.90404@radel.com> <20080903144237.GA28697@gvr.gvr.org> In-Reply-To: <20080903144237.GA28697@gvr.gvr.org> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050704000606010208090805" X-Radel.com-MailScanner-Information: Please contact Jon for more information X-Radel.com-MailScanner: Found to be clean X-Mailer: CommuniGate Pro CLI mailer Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 15:08:25 -0000 This is a cryptographically signed message in MIME format. --------------ms050704000606010208090805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Guido van Rooij wrote: > On Wed, Sep 03, 2008 at 10:13:08AM -0400, Jon Radel wrote: >>> And why is that so? This bascially rules out keep state on outgouing packets >>> on any router-type system. That seems like an unnecessary limitation. >> What? If you want state, turn it on: >> >> block all >> pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state >> pass out on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state >> >> should work fine also. Other things being equal (in other words, your >> mileage may vary....), that is both more secure and more efficient than >> the first rule set I offered as an example. I sent the first one only > > It's certianly not more efficient as one needs twice as many state entries. I say apples are better than oranges. You come along and say, "No, fool, pears are not better than oranges." I wish you luck with your problems. You might be happier using something other that PF. --Jon Radel --------------ms050704000606010208090805 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJMTCC AvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTkyMVoX DTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9tYXMx GTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRlbC5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx87Rf 0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF9qJ9 z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGbhHVv eAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw1ujk Rlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezri+BN kgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRlbC5j b20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQIWYb 5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpqZ3iA /PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQpoZSZ jzCCAvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTky MVoXDTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9t YXMxGTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRl bC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx 87Rf0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF 9qJ9z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGb hHVveAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw 1ujkRlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezr i+BNkgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRl bC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQ IWYb5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpq Z3iA/PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQp oZSZjzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQq E88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEA AaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcN AQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNw PP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq72 6jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQbZOR8X/3dLH0sJ+2vLUPdjAJ BgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODA5MDMxNTA4MTdaMCMGCSqGSIb3DQEJBDEWBBThgjmJ4PTDQBqE8kF79k6+F2HFRTBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1 D3YwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEBBQAEggEALgRf IcrjqIyMSrZ3lwSAKuRdQWMBjDF3Xxp+vzLHFD0sfRwNVZqMG7L+N9C7987RV/5zukgak6GB o9OLFWWXP6eoYAAvSN/eTW91LODba/BowWPu+8z8YgxjC8fO6Ra7C92/K/ypEHb2qtCITJMb dC6bpBvf9JC5LbszDSewNOAwR2O9vK3aGl3uDNUOMv+46zojdcv35Oz9Q6WrPWUwBn5uvs20 wbQ8sxsuK9UAHse5+4eIlSxARyqCNiSMqUoztq2JZ7MvSBnmSd7BE0BlCRjl5QnKHeyp7m0X nPiRZOR7l2iW5Z6EK8GHlzthoikJD20idvK3DVXiH+mOAAHivwAAAAAAAA== --------------ms050704000606010208090805-- From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 15:26:34 2008 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 8BC6D10656A0 for ; Wed, 3 Sep 2008 15:26:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 6EBA38FC1A for ; Wed, 3 Sep 2008 15:26:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id AB6N1a00B1GXsucA2FSaJ6; Wed, 03 Sep 2008 15:26:34 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id AFSY1a00M4v8bD78TFSYAG; Wed, 03 Sep 2008 15:26:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=hYA3pLoxE-MA:10 a=dPb6Kvwrd20A:10 a=QycZ5dHgAAAA:8 a=9WvCueDUggQvahGai5MA:9 a=tbCxmJ9JOCzs2GnbCSsA:7 a=7rPECo8Jk5cEcmYwOWBQ6mgAabYA:4 a=5Fr7JOagwDgA:10 a=oIWDkQLH8BMA:10 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 6039A17B822; Wed, 3 Sep 2008 08:26:32 -0700 (PDT) Date: Wed, 3 Sep 2008 08:26:32 -0700 From: Jeremy Chadwick To: Guido van Rooij Message-ID: <20080903152632.GA89687@icarus.home.lan> References: <20080903110943.GA25396@gvr.gvr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080903110943.GA25396@gvr.gvr.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 15:26:34 -0000 On Wed, Sep 03, 2008 at 01:09:43PM +0200, Guido van Rooij wrote: > > Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. > > ep0: 1.2.3.4/24 > bge0: 10.0.0.1/24 > > ruleset (made as simple as possible): > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 > block drop out log quick on ep0 all > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state First and foremost, I'm sorry I didn't reply to this sooner -- I've been fighting with Comcast for the past ~9 hours over a "single report of me sending spam" resulting in them blocking my ability to send mail via smtp.comcast.net:25... Yeah... anyway... I'm a bit confused by these rules and your network configuration. Rule #3 is keeping state incorrectly. You need to keep state only on the initial TCP SYN. You are using RELENG_6, which means you need to specify "flags S/SA", otherwise "keep state" is going to match against all TCP packets regardless of bits (FIN, ACK, PSH, etc.), which is probably not what you want. This may be the source of your problem. Rule #1 allows any packet with a source address of 1.2.3.1, arriving on the ep0 interface, destined to 10.0.0.2. How exactly are packets arriving on ep0 (which is bound to 1.2.3.0/24) with a destination of 10.0.0.2 in the first place? That seems strange. Is your gateway on your network blindly forwarding packets between networks or something? Or is this FreeBSD box acting *as* a gateway? Rule #3 allows any outbound packet from 1.2.3.1 (which isn't even an IP address bound to bge0), arriving on the bge0 interface, destined to 1.0.0.2. I wonder if this rule is backwards (IPs in from/to should be reversed). If none of this helps, others will have to assist, as I'm out of ideas other than the above. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 16:31:32 2008 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 7549B106700A; Wed, 3 Sep 2008 16:31:32 +0000 (UTC) (envelope-from SRS0=O4f9=ZN=googlemail.com=peter.wullinger@srs.kundenserver.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id E16758FC36; Wed, 3 Sep 2008 16:31:31 +0000 (UTC) (envelope-from SRS0=O4f9=ZN=googlemail.com=peter.wullinger@srs.kundenserver.de) Received: from kaliope.home (nrbg-4dbf7eb7.pool.einsundeins.de [77.191.126.183]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1Kav3T056M-0007Dn; Wed, 03 Sep 2008 18:18:03 +0200 Received: by kaliope.home (Postfix, from userid 1001) id 81DB745069; Wed, 3 Sep 2008 18:17:59 +0200 (CEST) Date: Wed, 3 Sep 2008 18:17:59 +0200 From: Peter Wullinger To: Jeremy Chadwick Message-ID: <20080903161759.GA2761@kaliope.home> References: <20080903110943.GA25396@gvr.gvr.org> <20080903152632.GA89687@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080903152632.GA89687@icarus.home.lan> User-Agent: Mutt/1.5.18 (2008-05-17) X-Provags-ID: V01U2FsdGVkX18q4sPCO1d3ShgmriAJDYpurDHFkZEww6FrJ+g NYiBwaahcWZNmGSojGd6AANxui6bypRJ3SIx4HHOwBwU2ubcDa bW3twPlWXylGNdqOWUmbVwtfkLKqktc Cc: Guido van Rooij , freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 16:31:32 -0000 I'll reply to Jeremy, since his answer somehow confused me. In epistula a Jeremy Chadwick, die horaque Wed Sep 3 17:26:32 2008: > On Wed, Sep 03, 2008 at 01:09:43PM +0200, Guido van Rooij wrote: > > > > Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. > > > > ep0: 1.2.3.4/24 > > bge0: 10.0.0.1/24 > > > > ruleset (made as simple as possible): > > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 > > block drop out log quick on ep0 all > > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state At little bit of guessing led me to the (possible, I have not tested this) culprit: Is your state-policy set to "floating" or "if-bound"? >From a casual look at the log entries and traffic snapshots you have sent, this seems to be pf working in "if-bound" mode. In this case, the created state table entry matches incoming on bge0, but not on outgoing on ep0 any more (packets pass through pf twice, as expected). This still maybe a bug, but it's common to rule out all possible culprits before spreading blame. In epistula a Jeremy Chadwick, die horaque Wed Sep 3 17:26:32 2008: > I'm a bit confused by these rules and your network configuration. > Rule #1 allows any packet with a source address of 1.2.3.1, arriving on > the ep0 interface, destined to 10.0.0.2. How exactly are packets > arriving on ep0 (which is bound to 1.2.3.0/24) with a destination of > 10.0.0.2 in the first place? That seems strange. Is your gateway on > your network blindly forwarding packets between networks or something? > Or is this FreeBSD box acting *as* a gateway? It seems to be a gateway, forwarding packets. What exactly do you find strange? Have I missed something? Peter -- Listening was an art, he had developed over the years. Because if you listened long and hard enough, people would tell you more, they thought they knew. -- Terry Pratchett, Thief Of Time From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 16:38:49 2008 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 B36A910692DC for ; Wed, 3 Sep 2008 16:38:49 +0000 (UTC) (envelope-from mail_list@realcomputerguy.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 6EFC58FC0A for ; Wed, 3 Sep 2008 16:38:49 +0000 (UTC) (envelope-from mail_list@realcomputerguy.com) Received: by an-out-0708.google.com with SMTP id b33so459181ana.13 for ; Wed, 03 Sep 2008 09:38:48 -0700 (PDT) Received: by 10.100.122.12 with SMTP id u12mr9224889anc.109.1220458365271; Wed, 03 Sep 2008 09:12:45 -0700 (PDT) Received: from davinci.realcomputerguy.soho ( [68.61.77.153]) by mx.google.com with ESMTPS id b18sm17115001ana.5.2008.09.03.09.12.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Sep 2008 09:12:44 -0700 (PDT) From: Chris Smith To: freebsd-pf@freebsd.org Date: Wed, 3 Sep 2008 12:12:41 -0400 References: <20080903110943.GA25396@gvr.gvr.org> <20080903152632.GA89687@icarus.home.lan> In-Reply-To: <20080903152632.GA89687@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809031212.41979.pf_free@chrissmith.org> Sender: Chris Smith Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 16:38:49 -0000 On Wednesday 03 September 2008 11:26:32 am Jeremy Chadwick wrote: > I've been > fighting with Comcast for the past ~9 hours over a "single report of me > sending spam" resulting in them blocking my ability to send mail via > smtp.comcast.net:25... Been there, done that (several times). They just make this shit up - really they must. As the last time they shut off my port 25 all of my mail was being sent via gmail on port 587 with my openBSD firewall blocking port 25. I hadn't used port 25 or their smtp servers for months - and I never use my comcast email address (it only receives the email they send me and forwards it to my google run account). They are totally clueless. From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 18:23:03 2008 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 4B9C51065924 for ; Wed, 3 Sep 2008 18:23:03 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.95.154.195]) by mx1.freebsd.org (Postfix) with ESMTP id 059AE8FC19 for ; Wed, 3 Sep 2008 18:23:02 +0000 (UTC) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id EA5CB42D821; Wed, 3 Sep 2008 20:23:01 +0200 (CEST) Date: Wed, 3 Sep 2008 20:23:01 +0200 From: Guido van Rooij To: Peter Wullinger Message-ID: <20080903182301.GA31792@gvr.gvr.org> References: <20080903110943.GA25396@gvr.gvr.org> <20080903152632.GA89687@icarus.home.lan> <20080903161759.GA2761@kaliope.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080903161759.GA2761@kaliope.home> Cc: Jeremy Chadwick , freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 18:23:03 -0000 On Wed, Sep 03, 2008 at 06:17:59PM +0200, Peter Wullinger wrote: > > At little bit of guessing led me to the (possible, I have not tested > this) culprit: Is your state-policy set to "floating" or "if-bound"? I tyried both, but there is no difference. > > >From a casual look at the log entries and traffic snapshots you have sent, > this seems to be pf working in "if-bound" mode. In this case, the > created state table entry matches incoming on bge0, but not on > outgoing on ep0 any more (packets pass through pf twice, as expected). > > This still maybe a bug, but it's common to rule out all possible > culprits before spreading blame. > True, but as state is created on the outbound interface for the first packet (bge), there is no corresponding incoming interface yet. At least with ipf, the return packet would first match the recorded outgoing interface (bge). Then it follows the gateway's internal routing. When it then goes out and passes through the firewall-code, it notices it does not yet know the interface (ep0) and records it in the state entry and passes it. This makes perfect sense: when the original packet would have arrived at a different interface than bge0, there must have been some kind of spoofing and should have been blocked in the first place. -Guido From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 18:25:13 2008 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 D4BCA1065BEE for ; Wed, 3 Sep 2008 18:25:13 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id 673BC8FC23 for ; Wed, 3 Sep 2008 18:25:13 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-063-119.pools.arcor-ip.net [88.66.63.119]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1Kax2W2DG6-0001ja; Wed, 03 Sep 2008 20:25:12 +0200 Received: (qmail 81390 invoked from network); 3 Sep 2008 18:25:12 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 3 Sep 2008 18:25:12 -0000 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Wed, 3 Sep 2008 20:25:11 +0200 User-Agent: KMail/1.10.0 (FreeBSD/8.0-CURRENT; KDE/4.1.0; i386; ; ) References: <20080903110943.GA25396@gvr.gvr.org> In-Reply-To: <20080903110943.GA25396@gvr.gvr.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809032025.11619.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+ADsqNld5sWFG1NmtKex09WH1+8nRFSfx8zg0 HqJnKYSvMHmqvmMQs/srPvLF/btUNTAtxfTujb4kqiKl66GiGj bK9HBqE3w7eYzNE+t3IZg== Cc: Guido van Rooij Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 18:25:13 -0000 On Wednesday 03 September 2008 13:09:43 Guido van Rooij wrote: > Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. > > ep0: 1.2.3.4/24 > bge0: 10.0.0.1/24 > > ruleset (made as simple as possible): > pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 > block drop out log quick on ep0 all > pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 > and passes because of rule 1. > Then the packet goes out via bge0, is passed via rule 3 and a satte entry > is created. > > The return SYN/ACK comes in via bge0 and passes because of the state entry. > > Then the packet should be sent out via ep0, but it is blocked, as pflogd > shows: 000000 rule 1/0(match): block out on ep0: 10.0.0.2.25 > There is no state entry and no rule that would allow traffic to be sent out via ep0. You either have to create state on ep0 or you must allow traffic on ep0 in both directions. I think the ruleset you are looking for is something along the lines of: block drop all pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state flags S/SA pass out on bge0 inet from 1.2.3.1 to 10.0.0.2 keep state flags S/SA -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 18:42:25 2008 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 56FA21065674 for ; Wed, 3 Sep 2008 18:42:25 +0000 (UTC) (envelope-from jon@radel.com) Received: from wave.radel.com (wave.radel.com [216.143.151.4]) by mx1.freebsd.org (Postfix) with ESMTP id 098578FC27 for ; Wed, 3 Sep 2008 18:42:24 +0000 (UTC) (envelope-from jon@radel.com) Received: by wave.radel.com (CommuniGate Pro PIPE 4.1.6) with PIPE id 7916475; Wed, 03 Sep 2008 14:42:24 -0400 Received: from [192.168.43.221] (account jon@radel.com HELO braeburn.local) by wave.radel.com (CommuniGate Pro SMTP 4.1.6) with ESMTP-TLS id 7916473; Wed, 03 Sep 2008 14:42:12 -0400 Message-ID: <48BEDA83.80600@radel.com> Date: Wed, 03 Sep 2008 14:42:11 -0400 From: Jon Radel User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Max Laier References: <20080903110943.GA25396@gvr.gvr.org> <200809032025.11619.max@love2party.net> In-Reply-To: <200809032025.11619.max@love2party.net> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050501060602040605070407" X-Radel.com-MailScanner-Information: Please contact Jon for more information X-Radel.com-MailScanner: Found to be clean X-Mailer: CommuniGate Pro CLI mailer Cc: Guido van Rooij , freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 18:42:25 -0000 This is a cryptographically signed message in MIME format. --------------ms050501060602040605070407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Max Laier wrote: > On Wednesday 03 September 2008 13:09:43 Guido van Rooij wrote: >> Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. >> >> ep0: 1.2.3.4/24 >> bge0: 10.0.0.1/24 >> >> ruleset (made as simple as possible): >> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 >> block drop out log quick on ep0 all >> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state >> >> When I telnet from 1.2.3.1 to 10.0.0.2, the packet comes in via ep0 >> and passes because of rule 1. >> Then the packet goes out via bge0, is passed via rule 3 and a satte entry >> is created. >> >> The return SYN/ACK comes in via bge0 and passes because of the state entry. >> >> Then the packet should be sent out via ep0, but it is blocked, as pflogd >> shows: 000000 rule 1/0(match): block out on ep0: 10.0.0.2.25 > > > There is no state entry and no rule that would allow traffic to be sent out > via ep0. You either have to create state on ep0 or you must allow traffic on > ep0 in both directions. I think the ruleset you are looking for is something > along the lines of: > > block drop all > > pass in on ep0 inet from 1.2.3.1 to 10.0.0.2 keep state flags S/SA > pass out on bge0 inet from 1.2.3.1 to 10.0.0.2 keep state flags S/SA > The OP didn't like that answer when I gave it to him. Maybe you've managed to provide a more felicitous wording. ;-) --Jon Radel --------------ms050501060602040605070407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJMTCC AvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTkyMVoX DTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9tYXMx GTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRlbC5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx87Rf 0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF9qJ9 z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGbhHVv eAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw1ujk Rlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezri+BN kgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRlbC5j b20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQIWYb 5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpqZ3iA /PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQpoZSZ jzCCAvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTky MVoXDTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9t YXMxGTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRl bC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx 87Rf0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF 9qJ9z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGb hHVveAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw 1ujkRlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezr i+BNkgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRl bC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQ IWYb5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpq Z3iA/PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQp oZSZjzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQq E88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEA AaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcN AQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNw PP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq72 6jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQbZOR8X/3dLH0sJ+2vLUPdjAJ BgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODA5MDMxODQyMTFaMCMGCSqGSIb3DQEJBDEWBBRMwbr2J9kqNOEAgKbmdEoKziJcIDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1 D3YwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEBBQAEggEAomD+ KyWG6x6ZhDnR2UAZcScq7eOJN/tzEdyFm0FeQlXpdLErds4S4o5gcOZluzEQw+9481wJ79hl 51D5MfanLFLLz1Wgign34Mx3RwidS9AaadrPKyMSfGnu2QBMOBY4duQ/TDgqJ7GM6Ekw8n9+ pjJql+HjGcNkePuSjbBt9/Pweo5X4nbGwM54O7nWC2ssBAzvn8lrZ5cyg9sqBhTEKwwir3Ss rQsUuD1Z8Hi3GjEaaWcpdPFHaS8WTKhFuTahUqs30hmEtsay5p2+9P+vfLwNnizinycCQQWC S7SzbKhCUDUO+2q9lvWK3/CHfowqImwW38rKwsqWTOa5l5q2YQAAAAAAAA== --------------ms050501060602040605070407-- From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 18:49:39 2008 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 E2FF51065673 for ; Wed, 3 Sep 2008 18:49:39 +0000 (UTC) (envelope-from jon@radel.com) Received: from wave.radel.com (wave.radel.com [216.143.151.4]) by mx1.freebsd.org (Postfix) with ESMTP id 94A9A8FC0A for ; Wed, 3 Sep 2008 18:49:39 +0000 (UTC) (envelope-from jon@radel.com) Received: by wave.radel.com (CommuniGate Pro PIPE 4.1.6) with PIPE id 7916499; Wed, 03 Sep 2008 14:49:39 -0400 Received: from [192.168.43.221] (account jon@radel.com HELO braeburn.local) by wave.radel.com (CommuniGate Pro SMTP 4.1.6) with ESMTP-TLS id 7916497; Wed, 03 Sep 2008 14:49:25 -0400 Message-ID: <48BEDC35.3050802@radel.com> Date: Wed, 03 Sep 2008 14:49:25 -0400 From: Jon Radel User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Peter Wullinger References: <20080903110943.GA25396@gvr.gvr.org> <20080903152632.GA89687@icarus.home.lan> <20080903161759.GA2761@kaliope.home> In-Reply-To: <20080903161759.GA2761@kaliope.home> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020909070803010108080104" X-Radel.com-MailScanner-Information: Please contact Jon for more information X-Radel.com-MailScanner: Found to be clean X-Mailer: CommuniGate Pro CLI mailer Cc: Guido van Rooij , freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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, 03 Sep 2008 18:49:40 -0000 This is a cryptographically signed message in MIME format. --------------ms020909070803010108080104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Wullinger wrote: > I'll reply to Jeremy, since his answer somehow confused me. > > In epistula a Jeremy Chadwick, die horaque Wed Sep 3 17:26:32 2008: >> On Wed, Sep 03, 2008 at 01:09:43PM +0200, Guido van Rooij wrote: >>> Setup: FreeBSD 6.3 system with 2 interfaces: ep0 and bge0. >>> >>> ep0: 1.2.3.4/24 >>> bge0: 10.0.0.1/24 >>> >>> ruleset (made as simple as possible): >>> pass in quick on ep0 inet from 1.2.3.1 to 10.0.0.2 >>> block drop out log quick on ep0 all >>> pass out quick on bge0 inet proto tcp from 1.2.3.1 to 10.0.0.2 keep state > > At little bit of guessing led me to the (possible, I have not tested > this) culprit: Is your state-policy set to "floating" or "if-bound"? > > From a casual look at the log entries and traffic snapshots you have sent, > this seems to be pf working in "if-bound" mode. In this case, the > created state table entry matches incoming on bge0, but not on > outgoing on ep0 any more (packets pass through pf twice, as expected). > > This still maybe a bug, but it's common to rule out all possible > culprits before spreading blame. > My understanding is that "if-bound" would have an effect on this scenario if the OP, for example, had two interfaces on the same "side" of the firewall, say bge0 and bge1, and packets for a connection that was originally established by a packet outbound on bge0 might cross on either bge0 or bge1 traveling in the same direction with respect to the FreeBSD router with the configuration. In this case we're talking about packets that are traveling in one direction with respect to the router on bge0 and the other direction on ep0, so you'd need separate state entries no matter what you've done with if-bound. --Jon Radel --------------ms020909070803010108080104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJMTCC AvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTkyMVoX DTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9tYXMx GTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRlbC5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx87Rf 0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF9qJ9 z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGbhHVv eAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw1ujk Rlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezri+BN kgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRlbC5j b20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQIWYb 5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpqZ3iA /PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQpoZSZ jzCCAvMwggJcoAMCAQICEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEFBQAwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMyNDE2NTky MVoXDTA5MDMyNDE2NTkyMVowXjEOMAwGA1UEBBMFUmFkZWwxEzARBgNVBCoTCkpvbiBUaG9t YXMxGTAXBgNVBAMTEEpvbiBUaG9tYXMgUmFkZWwxHDAaBgkqhkiG9w0BCQEWDWpvbkByYWRl bC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPdCxQufreHHDAI9YN2axx 87Rf0TK1PYFMlJHi4y1ebdAMPqR6M44bz+3m8YnKn1bmIf7dWyisWyAIQYCOhW/2r66o4MdF 9qJ9z5uhMy+28zaJP/Glg64C3WPM0VfveCgvu+ApEyf2JDbjc/hUomw8KpppgOcn1wX6PZGb hHVveAvDTWJ0ugqo08Ny6GR0bsGvePmxdWSQq+0aGTHqA1I2EozJBZ8W5xlUtKe22j56i1Uw 1ujkRlosdu2PTs8QOY1OUHuLPnEV9EWtYF7g6bXDUDsJxypXZy9qTipPplYXjdWgkLVRvezr i+BNkgin8UKhKLQ99vS25zrMFKu80g31AgMBAAGjKjAoMBgGA1UdEQQRMA+BDWpvbkByYWRl bC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAR4u9o4CFvztyo0sZb3tCQ IWYb5U4jW9da3goVwWIkMz+qeCb2kiTQfsSmOdF9YJ8VTRdYW0l0fQbqL5JikVhaYeX85cpq Z3iA/PPJpfPtJw8g5jJOAROVAvxydMZXQYxyIBMV4HNG3qir44YnyfmJXkBtRFYWdxBc7bQp oZSZjzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me 7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQq E88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEA AaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcN AQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNw PP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq72 6jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQbZOR8X/3dLH0sJ+2vLUPdjAJ BgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODA5MDMxODQ5MjVaMCMGCSqGSIb3DQEJBDEWBBTIlOrBrZh/gA9e7C4sGXIq+qG0JjBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1 D3YwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEG2TkfF/93Sx9LCftry1D3YwDQYJKoZIhvcNAQEBBQAEggEAZ8m7 ktW+nG50CRxGkBGSBZXueJCq8VXwZBqYZCFwxW+8xeDOlsdABuybB7679UYvc2lyi3pccb7c IbmAoKiTtB/A/SCFLEWSUPFEGyHEYKIareTBhhKIV9R9E0JaR5aY1hZ6O6c300Ugv7wJL02Q 0PdNy7ai855Zh96krE4L46W/ztSx5cRoe4509JZx/cWe78vXR70IHhCLAZgQKGVyCsCnlKOQ PBH0Mzlf5iZjwGVZ2Fh6FDUcUPvs6vDCPywZPBPmfa5eY5nUel5hkljtbVt2Z2x0UJDBoink d3xrgRu1z0mX+SlQMcR/Ku98uuYWjsdNlcRHvOBQwUIjNa6xmwAAAAAAAA== --------------ms020909070803010108080104-- From owner-freebsd-pf@FreeBSD.ORG Wed Sep 3 19:30:25 2008 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B354106566B for ; Wed, 3 Sep 2008 19:30:25 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id B6FAC8FC15 for ; Wed, 3 Sep 2008 19:30:24 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by postfix2-g20.free.fr (Postfix) with ESMTP id 99D0029CCE6C for ; Wed, 3 Sep 2008 19:05:00 +0200 (CEST) Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id 4726932A7A0; Wed, 3 Sep 2008 21:05:18 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp8-g19.free.fr (Postfix) with ESMTP id 9145E32A848; Wed, 3 Sep 2008 21:05:17 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 5A5529B497; Wed, 3 Sep 2008 18:57:57 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 4C3584089; Wed, 3 Sep 2008 20:57:57 +0200 (CEST) Date: Wed, 3 Sep 2008 20:57:57 +0200 From: Jeremie Le Hen To: Mohacsi Janos Message-ID: <20080903185757.GE72107@obiwan.tataz.chchile.org> References: <17838240D9A5544AAA5FF95F8D520316049038B6@ad-exh01.adhost.lan> <20080903082619.U4624@mignon.ki.iif.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080903082619.U4624@mignon.ki.iif.hu> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: pf@benzedrine.cx, pf@freebsd.org Subject: Re: NAT-PT (was: Crazy Question - IPv6 to IPv4 and vice versa) 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, 03 Sep 2008 19:30:25 -0000 Hi, On Wed, Sep 03, 2008 at 08:30:39AM +0200, Mohacsi Janos wrote: > 1. NAT-PT - however depracated - and not maintained the *BSD version > anymore: http://mucc.mahidol.ac.th/~ccvvs/natpt-setup.html> By the way, I've always wondered what it had been deprecated. It was quite hackish but could be very useful. It used to be implemented in KAME snapshot but has never made its path to one of the BSD. I'm sure there are good reasons for this and I'd be happy if someone could point them. Thank you. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-pf@FreeBSD.ORG Thu Sep 4 06:10:56 2008 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 C64731065674 for ; Thu, 4 Sep 2008 06:10:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id AB0498FC1C for ; Thu, 4 Sep 2008 06:10:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id AW1U1a0050b6N64AAWAvX9; Thu, 04 Sep 2008 06:10:55 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id AWAu1a00F4v8bD78PWAvdb; Thu, 04 Sep 2008 06:10:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=hYA3pLoxE-MA:10 a=dPb6Kvwrd20A:10 a=QycZ5dHgAAAA:8 a=rf6r4eEY-zWWq147M4gA:9 a=7CJgO_96kWgWPXI0FEgTCH0SWn0A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id C187F17B81A; Wed, 3 Sep 2008 23:10:54 -0700 (PDT) Date: Wed, 3 Sep 2008 23:10:54 -0700 From: Jeremy Chadwick To: Peter Wullinger Message-ID: <20080904061054.GA4131@icarus.home.lan> References: <20080903110943.GA25396@gvr.gvr.org> <20080903152632.GA89687@icarus.home.lan> <20080903161759.GA2761@kaliope.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080903161759.GA2761@kaliope.home> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Guido van Rooij , freebsd-pf@freebsd.org Subject: Re: keeping state on outgoing connections 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: Thu, 04 Sep 2008 06:10:56 -0000 On Wed, Sep 03, 2008 at 06:17:59PM +0200, Peter Wullinger wrote: > I'll reply to Jeremy, since his answer somehow confused me. > > In epistula a Jeremy Chadwick, die horaque Wed Sep 3 17:26:32 2008: > > I'm a bit confused by these rules and your network configuration. > > Rule #1 allows any packet with a source address of 1.2.3.1, arriving on > > the ep0 interface, destined to 10.0.0.2. How exactly are packets > > arriving on ep0 (which is bound to 1.2.3.0/24) with a destination of > > 10.0.0.2 in the first place? That seems strange. Is your gateway on > > your network blindly forwarding packets between networks or something? > > Or is this FreeBSD box acting *as* a gateway? > > It seems to be a gateway, forwarding packets. What exactly do you find > strange? Have I missed something? Sorry for confusing you -- if it's a gateway, the OP needed to state such. I can't assume it's a gateway, because in this day and age people try to do crazy things with networks, especially with bridging. If it's a gateway, there's nothing strange about it. If it isn't a gateway, I can't see how any of the above would work. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Thu Sep 4 18:30:23 2008 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 1CF321065676 for ; Thu, 4 Sep 2008 18:30:23 +0000 (UTC) (envelope-from schaman@sch.bme.hu) Received: from balu.sch.bme.hu (balu.sch.bme.hu [152.66.208.40]) by mx1.freebsd.org (Postfix) with ESMTP id CEBCE8FC19 for ; Thu, 4 Sep 2008 18:30:22 +0000 (UTC) (envelope-from schaman@sch.bme.hu) Received: from sch.bme.hu ([152.66.208.35]) by balu.sch.bme.hu (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0K6O0055KLXX2G80@balu.sch.bme.hu> for freebsd-pf@freebsd.org; Thu, 04 Sep 2008 19:29:57 +0200 (CEST) Received: from [212.24.177.100] by messenger.sch.bme.hu (mshttpd); Thu, 04 Sep 2008 19:29:57 +0200 Date: Thu, 04 Sep 2008 19:29:57 +0200 From: =?iso-8859-2?Q?=22Kiss_Zolt=E1n=22?= To: freebsd-pf@freebsd.org Message-id: <770fd2282951.48c03735@sch.bme.hu> MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-7.05 (built Sep 5 2006) Content-type: text/plain; charset=windows-1252 Content-language: hu Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: hu Priority: normal Subject: pf fails to create state entries to OpenVPN-initiated sessions 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: Thu, 04 Sep 2008 18:30:23 -0000 Hi=2C My company has a strange problem with OpenVPN under FreeBSD 7=2E0=2E The= configuration is the following=3A Our central NAT firewall/VPN endpoint has two physical interfaces=2C one= for the public Internet (called ext)=2C and one for our intranet (int=2C= 192=2E168=2E1=2E0/24)=2E On ext there are IPSec tunnels to remote offic= es through gif interfaces=2C and int is bridged to tap0=2C which is used= by OpenVPN=2E Users can seamlessly login=2C and access the central subn= et=2C but there are strange effects when someone wants to access branch = office networks=2E Note=2C that pf has =93set skip=94 options on all gif= interface=2C on the bridge0 if and on tap0=2C to avoid on this side=2E = So as I mentioned=2C OpenVPN users can access the 192=2E168=2E1=2E0/24 n= etwork=2C but when they send a packet to a remote subnet (e=2Eg=2E 192=2E= 168=2E2=2E0/24)=2C sometimes the firewall isn=92t create a state entry=2C= and so TCP sessions cannot be established=2E See this example=3A 2008-09-03 19=3A03=3A35=2E919390 rule 41/0(match)=3A pass out on int=3A = 192=2E168=2E1=2E100=2E55754 =3E 192=2E168=2E1=2E1=2E53=3A 61937+=5B=7Cdo= main=5D 2008-09-03 19=3A03=3A36=2E147102 rule 0/0(match)=3A block out on int=3A = 192=2E168=2E2=2E1=2E3389 =3E 192=2E168=2E1=2E100=2E38289=3A S 1952258627= =3A1952258627(0) ack 479606554 win 16384 =3Cmss 1460=2Cnop=2Cwscale 0=2C= nop=2Cnop=2Ctimestamp=5B=7Ctcp=5D=3E 2008-09-03 19=3A03=3A38=2E682145 rule 0/0(match)=3A block out on int=3A = 192=2E168=2E2=2E1=2E3389 =3E 192=2E168=2E1=2E100=2E38289=3A S 1952258627= =3A1952258627(0) ack 479606554 win 16384 =3Cmss 1460=2Cnop=2Cwscale 0=2C= nop=2Cnop=2Ctimestamp=5B=7Ctcp=5D=3E =2E1=2E100 is an OpenVPN client=2C as you see it passes pf to central su= bnet=2E But on next two row=2C where =2E2=2E1 is a terminal server=2C yo= u can see only answer packets to TCP session initiation=2C which are blo= cked in the lack of state entry=2E But what=92s more strange=2C when I w= ant to start an RDP session again to the same server 2 minutes later=2C = it works properly! =3A 2008-09-03 19=3A05=3A28=2E237872 rule 7/0(match)=3A pass in on int=3A 19= 2=2E168=2E1=2E100=2E38293 =3E 192=2E168=2E2=2E1=2E3389=3A S 2231405925=3A= 2231405925(0) win 5840 =3Cmss 1336=2CsackOK=2Ctimestamp 236974897=5B=7Ct= cp=5D=3E And I didn=92t make any change on the firewall in this 2 minute! And thi= s happens quite randomly=2C so I=92m quite confused why it happens=2E Th= e related firewall rules=3A =407 pass in log on int inet from 192=2E168=2E1=2E0/24 to any flags S/SA= keep state =4041 pass out log on inet inet from 192=2E168=2E1=2E0/24 to any flags S= /SA keep state =4042 pass in log on int inet from any to 192=2E168=2E16=2E0/24 flags S/= SA keep state I tried to let it as permissive as possible=2E There isn=92t any dynamic= routing on this intranet=2C and inside the physical networks of our off= ices anybody can access anybody without any problem=2E My expectation=2C= that if a packet comes from VPN client=2C it goes through tap0=2C bridg= e0=2C where it=92s not filtered=2C pass in on int=2C and create a state = entry=2C but somehow it doesn=92t happens always=2E Do you have any idea= how can I investigate this problem=3F Any suggestions are welcomed=2E Regards=2C Zolt=E1n=2C Kiss From owner-freebsd-pf@FreeBSD.ORG Fri Sep 5 22:35:25 2008 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88887106564A; Fri, 5 Sep 2008 22:35:25 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5AFEA8FC19; Fri, 5 Sep 2008 22:35:25 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m85MZP9X028481; Fri, 5 Sep 2008 22:35:25 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m85MZPPa028477; Fri, 5 Sep 2008 22:35:25 GMT (envelope-from remko) Date: Fri, 5 Sep 2008 22:35:25 GMT Message-Id: <200809052235.m85MZPPa028477@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/127121: pf incorrect log priority 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: Fri, 05 Sep 2008 22:35:25 -0000 Synopsis: pf incorrect log priority Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: remko Responsible-Changed-When: Fri Sep 5 22:35:05 UTC 2008 Responsible-Changed-Why: reassign to pf team http://www.freebsd.org/cgi/query-pr.cgi?pr=127121 From owner-freebsd-pf@FreeBSD.ORG Sat Sep 6 13:35:41 2008 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 0395A106564A for ; Sat, 6 Sep 2008 13:35:41 +0000 (UTC) (envelope-from secucatcher@free.fr) Received: from wmproxy1-g27.free.fr (wmproxy1-g27.free.fr [212.27.42.91]) by mx1.freebsd.org (Postfix) with ESMTP id C8EA18FC1A for ; Sat, 6 Sep 2008 13:35:40 +0000 (UTC) (envelope-from secucatcher@free.fr) Received: from imp12-g21.priv.proxad.net (imp12-g21.priv.proxad.net [172.20.243.60]) by wmproxy1-g27.free.fr (Postfix) with ESMTP id C13362B178 for ; Sat, 6 Sep 2008 15:41:16 +0200 (CEST) Received: by imp12-g21.priv.proxad.net (Postfix, from userid 33) id E53021DE2; Sat, 6 Sep 2008 15:10:18 +0200 (CEST) Received: from ([88.186.56.129]) by imp.free.fr (IMP) with HTTP for ; Sat, 06 Sep 2008 15:10:18 +0200 Message-ID: <1220706618.48c2813ab9cc6@imp.free.fr> Date: Sat, 06 Sep 2008 15:10:18 +0200 From: secucatcher@free.fr To: freebsd-pf@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-Originating-IP: Cc: Subject: (no subject) 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: Sat, 06 Sep 2008 13:35:41 -0000 hi everybody, my work now is to change a linux firewall with iptables to freebsd/pf/carp i migrate 6500 lines of iptables with no problem in ten day there is 400 servers to filter and maybe more in the new datacenter (1400/1700) the firewall do nat ! they have something like this: iptables -t nat -I PREROUTING -d -j DNAT --to the idea behind is that two server on the same lan behind the firewall could be seen each other like they are on internet in different place, they use webservices and they already deal with that. the first contact the second not on the lan but through the firewall with public address. the firewall must be in production next week, they just told me this new thing they want this morning (and it was not in the first part i migrate) and i finish the last three hours i must do on this project. if i didn't win ;) they stay with iptables. i try some idea http://www.openbsd.org/faq/pf/rdr.html but most of what i do for the server is binat and not rdr. i can't deal with netcat for such a project , pftpx is already a bit dirty for them instead of conntrack thank you for your help From owner-freebsd-pf@FreeBSD.ORG Sat Sep 6 18:40:44 2008 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 EB1B3106564A for ; Sat, 6 Sep 2008 18:40:44 +0000 (UTC) (envelope-from secucatcher@free.fr) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.freebsd.org (Postfix) with ESMTP id B68398FC0A for ; Sat, 6 Sep 2008 18:40:44 +0000 (UTC) (envelope-from secucatcher@free.fr) Received: from smtp6-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp6-g19.free.fr (Postfix) with ESMTP id 5BE0A17261 for ; Sat, 6 Sep 2008 20:40:43 +0200 (CEST) Received: from desktop (abv73-1-88-186-56-129.fbx.proxad.net [88.186.56.129]) by smtp6-g19.free.fr (Postfix) with ESMTP id 29914197A8 for ; Sat, 6 Sep 2008 20:40:42 +0200 (CEST) Date: Sat, 6 Sep 2008 20:40:42 +0200 From: Message-ID: <20080906204042.16491860@desktop> In-Reply-To: <1220706618.48c2813ab9cc6@imp.free.fr> References: <1220706618.48c2813ab9cc6@imp.free.fr> X-Mailer: Claws Mail 2.6.1 (GTK+ 2.10.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-pf@FreeBSD.org Subject: Re: (no subject) 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: Sat, 06 Sep 2008 18:40:45 -0000 sorry for the disturbing time i find: rdr on $if_ext proto tcp from $int_net to port 80 -> \ nat on $if_int inet from to any -> i nat on the internal interface and it is just working From owner-freebsd-pf@FreeBSD.ORG Sat Sep 6 19:14:13 2008 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 7C79F1065672 for ; Sat, 6 Sep 2008 19:14:13 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay2-bcrtfl2.verio.net (relay2-bcrtfl2.verio.net [131.103.218.177]) by mx1.freebsd.org (Postfix) with ESMTP id 693158FC14 for ; Sat, 6 Sep 2008 19:14:12 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay2-bcrtfl2.verio.net (Postfix) with ESMTP id 0D2161FF009F for ; Sat, 6 Sep 2008 15:14:11 -0400 (EDT) thread-index: AckQVL3YnNxitoftQHiDUPiTOht3aQ== Received: from limbo.int.dllstx01.us.it.verio.net ([10.10.10.11]) by iad-wprd-xchw01.corp.verio.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Sep 2008 15:14:10 -0400 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 908AB8E29B; Sat, 6 Sep 2008 14:14:04 -0500 (CDT) Date: Sat, 6 Sep 2008 14:14:04 -0500 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Message-ID: <20080906191403.GJ1949@verio.net> Content-Class: urn:content-classes:message Mail-Followup-To: freebsd-pf@freebsd.org Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 References: <1220706618.48c2813ab9cc6@imp.free.fr> <20080906204042.16491860@desktop> MIME-Version: 1.0 Content-Type: text/plain; x-action=pgp-signed; charset="us-ascii" Content-Disposition: inline In-reply-to: <20080906204042.16491860@desktop> Precedence: bulk User-Agent: Mutt/1.5.9i X-OriginalArrivalTime: 06 Sep 2008 19:14:10.0437 (UTC) FILETIME=[BDCC9B50:01C91054] Subject: Re: bidirectional NAT in PF? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 06 Sep 2008 19:14:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 secucatcher@free.fr wrote: > > sorry for the disturbing time > i find: > rdr on $if_ext proto tcp from $int_net to port 80 -> \ > > > nat on $if_int inet from to any -> > > i nat on the internal interface and it is just working Is this true, that PF supports bidirectional NAT? That is, NAT of both the source and the destination IP in a connection, at the same time? I had attempted this in the past but I could not find a rule syntax that would accomplish it. Looking at the above, it appears that this may be possible because PF processes the rulebase twice for forwarded traffic; once on input, and again on output. If the inbound packet matched a "rdr" rule, and the outbound matched a "nat" rule, this would accomplish bidirectional NAT? Interesting technique, if it works. - -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIwtZ7FSrKRjX5eCoRAgMIAJ9x6RUt1XwvKs67moiSKa+e1FMt2wCfYPJ2 GdSU08YZvJWvjFOw3zd8kpI= =92NZ -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-pf@FreeBSD.ORG Sat Sep 6 19:41:58 2008 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 A65B61065673 for ; Sat, 6 Sep 2008 19:41:58 +0000 (UTC) (envelope-from secucatcher@free.fr) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.freebsd.org (Postfix) with ESMTP id 709EC8FC14 for ; Sat, 6 Sep 2008 19:41:58 +0000 (UTC) (envelope-from secucatcher@free.fr) Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id E08E23EA0EB; Sat, 6 Sep 2008 21:41:56 +0200 (CEST) Received: from desktop (abv73-1-88-186-56-129.fbx.proxad.net [88.186.56.129]) by smtp4-g19.free.fr (Postfix) with ESMTP id 7EE673EA10C; Sat, 6 Sep 2008 21:41:56 +0200 (CEST) Date: Sat, 6 Sep 2008 21:41:55 +0200 From: To: "David DeSimone" Message-ID: <20080906214155.52c6f2e7@desktop> In-Reply-To: <20080906191403.GJ1949@verio.net> References: <1220706618.48c2813ab9cc6@imp.free.fr> <20080906204042.16491860@desktop> <20080906191403.GJ1949@verio.net> X-Mailer: Claws Mail 2.6.1 (GTK+ 2.10.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: bidirectional NAT in PF? 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: Sat, 06 Sep 2008 19:41:58 -0000 > Is this true, that PF supports bidirectional NAT? That is, NAT of > both the source and the destination IP in a connection, at the same > time? > > I had attempted this in the past but I could not find a rule syntax > that would accomplish it. Looking at the above, it appears that this > may be possible because PF processes the rulebase twice for forwarded > traffic; once on input, and again on output. If the inbound packet > matched a "rdr" rule, and the outbound matched a "nat" rule, this > would accomplish bidirectional NAT? > > Interesting technique, if it works. "binat" was not working for u ? binat on $ifext from private-ip to any -> public-ip From owner-freebsd-pf@FreeBSD.ORG Sat Sep 6 19:56:09 2008 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 A54D51065680 for ; Sat, 6 Sep 2008 19:56:09 +0000 (UTC) (envelope-from secucatcher@free.fr) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.freebsd.org (Postfix) with ESMTP id 71B628FC08 for ; Sat, 6 Sep 2008 19:56:09 +0000 (UTC) (envelope-from secucatcher@free.fr) Received: from smtp2-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp2-g19.free.fr (Postfix) with ESMTP id 1CD4512B712; Sat, 6 Sep 2008 21:56:08 +0200 (CEST) Received: from desktop (abv73-1-88-186-56-129.fbx.proxad.net [88.186.56.129]) by smtp2-g19.free.fr (Postfix) with ESMTP id D782512B6C6; Sat, 6 Sep 2008 21:56:07 +0200 (CEST) Date: Sat, 6 Sep 2008 21:56:07 +0200 From: To: "David DeSimone" Message-ID: <20080906215607.60b235f9@desktop> In-Reply-To: <20080906191403.GJ1949@verio.net> References: <1220706618.48c2813ab9cc6@imp.free.fr> <20080906204042.16491860@desktop> <20080906191403.GJ1949@verio.net> X-Mailer: Claws Mail 2.6.1 (GTK+ 2.10.11; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: bidirectional NAT in PF? 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: Sat, 06 Sep 2008 19:56:09 -0000 Le Sat, 6 Sep 2008 14:14:04 -0500 "David DeSimone" a pris sa plume: > rdr on $if_ext proto tcp from $int_net to port 80 -> \ > > > > > > nat on $if_int inet from to any -> > > > > i nat on the internal interface and it is just working to be more clear the priv ip and pub ip on the tww line are different and are own by the two server than must connect like they are on the net From owner-freebsd-pf@FreeBSD.ORG Sat Sep 6 22:31:15 2008 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 B5279106566B for ; Sat, 6 Sep 2008 22:31:15 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay2-bcrtfl2.verio.net (relay2-bcrtfl2.verio.net [131.103.218.177]) by mx1.freebsd.org (Postfix) with ESMTP id 6ACE38FC17 for ; Sat, 6 Sep 2008 22:31:15 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay2-bcrtfl2.verio.net (Postfix) with ESMTP id 709BD1FF0098 for ; Sat, 6 Sep 2008 18:31:14 -0400 (EDT) thread-index: AckQcEL7L4bKHPOBRwuUp8gjutmk7w== Received: from limbo.int.dllstx01.us.it.verio.net ([10.10.10.11]) by iad-wprd-xchw01.corp.verio.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 6 Sep 2008 18:31:10 -0400 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 83A488E29B; Sat, 6 Sep 2008 17:31:04 -0500 (CDT) Date: Sat, 6 Sep 2008 17:31:04 -0500 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Message-ID: <20080906223103.GK1949@verio.net> Content-Class: urn:content-classes:message Mail-Followup-To: freebsd-pf@freebsd.org Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 References: <1220706618.48c2813ab9cc6@imp.free.fr> <20080906204042.16491860@desktop> <20080906191403.GJ1949@verio.net> <20080906214155.52c6f2e7@desktop> MIME-Version: 1.0 Content-Type: text/plain; x-action=pgp-signed; charset="us-ascii" Content-Disposition: inline In-reply-to: <20080906214155.52c6f2e7@desktop> Precedence: bulk User-Agent: Mutt/1.5.9i X-OriginalArrivalTime: 06 Sep 2008 22:31:10.0233 (UTC) FILETIME=[42F25890:01C91070] Subject: Re: bidirectional NAT in PF? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 06 Sep 2008 22:31:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 secucatcher@free.fr wrote: > > > Is this true, that PF supports bidirectional NAT? That is, NAT of > > both the source and the destination IP in a connection, at the same > > time? > > "binat" was not working for u ? > binat on $ifext from private-ip to any -> public-ip I think I am using the wrong terminology. I should probably call it "double NAT" to differentiate it. "binat" works fine but it still only changes ONE of the IP's being translated (the source IP). In PF, you can use "nat" to translate the source IP, and "redir" to change the dest IP, but what if you want to change both? There is no direct way to do this, so I am wondering if two different rules could be matched at different times during the packet's transit through the gateway. - -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIwwSnFSrKRjX5eCoRAsVtAJ97T8ALAm7SnrAx362biLvFNK+4zwCfRblb l1wrXShJas2NfmKJYXpz/iE= =RNSP -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you.