From owner-freebsd-pf@FreeBSD.ORG Mon Jul 10 00:23:22 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7C8016A4DD for ; Mon, 10 Jul 2006 00:23:22 +0000 (UTC) (envelope-from fayerwall@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D48B43D45 for ; Mon, 10 Jul 2006 00:23:22 +0000 (GMT) (envelope-from fayerwall@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so1410973uge for ; Sun, 09 Jul 2006 17:23:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=GrQ6uVl4FsCii/8e4AkTjxc4f924axVZngj3KVs6f0aFzNZahjuAqlWYV3OlTZOnMOK+uqNLsLY+YRgdnJRHi/2AZObZMT0U1El32wnWoJ3GNLyP5qt8zLxoD2MHBZq2L/V8sYCl82G8BPpN1EEo1ZDapowBBLGjqOTQ3R0c6VA= Received: by 10.78.117.10 with SMTP id p10mr1466299huc; Sun, 09 Jul 2006 17:23:21 -0700 (PDT) Received: by 10.78.156.3 with HTTP; Sun, 9 Jul 2006 17:23:21 -0700 (PDT) Message-ID: Date: Sun, 9 Jul 2006 17:23:21 -0700 From: "Fire walls" To: freebsd-pf@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Sync command from IPF to 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: Mon, 10 Jul 2006 00:23:22 -0000 Hi people. I start working with pf, my first firewall is running ipf, my doubt is, we have the flag "y" on ipf, on pf we dont need any more that setting?, because before every time i connect to my isp i run the ppp.linkup with the command !bg /sbin/ipf -y, how pf handle that? Thanks all for your time, greetings!!! -- :-) From owner-freebsd-pf@FreeBSD.ORG Mon Jul 10 00:31:41 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCA1B16A4E0 for ; Mon, 10 Jul 2006 00:31:41 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1375943D53 for ; Mon, 10 Jul 2006 00:31:41 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.181.175] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1FzjgZ1BKM-0008NK; Mon, 10 Jul 2006 02:31:39 +0200 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Mon, 10 Jul 2006 02:31:32 +0200 User-Agent: KMail/1.9.1 References: In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5554175.jZQEkvaLVj"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200607100231.37891.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: Sync command from IPF to 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: Mon, 10 Jul 2006 00:31:41 -0000 --nextPart5554175.jZQEkvaLVj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 10 July 2006 02:23, Fire walls wrote: > I start working with pf, my first firewall is running ipf, my doubt > is, we have the flag "y" on ipf, on pf we dont need any more that > setting?, because before every time i connect to my isp i run the > ppp.linkup with the command !bg /sbin/ipf -y, how pf handle that? With pf a simple "pfctl -f config.file" will do the same in 99% of the time= =20 unless you have tables predefined in the config file that were changed late= r=20 on - in that case you will lose the changes. As a better alternative, pf has the "(interfacename)" syntax. Whereever yo= u=20 want to say "addresses on tun0" you can say "(tun0)". For instance you wou= ld=20 want to write things like: nat on $ext_if inet from ($int_if:network) to any -> ($ext_if) this - in contrast to: nat on $ext_if inet from $int_if:network to any -> $ext_if will track changes of the interface address automatically. See pf.conf(5) = for=20 more details on this. Make sure that you use the "()" syntax everywhere to avoid surprises. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart5554175.jZQEkvaLVj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEsZ/pXyyEoT62BG0RAm3bAJ9tIKlp4w1PV5TJNSmmDrh6y15CQgCfaXwq dgavJ3/h/O4x2sKqVdw9x1c= =x8iv -----END PGP SIGNATURE----- --nextPart5554175.jZQEkvaLVj-- From owner-freebsd-pf@FreeBSD.ORG Mon Jul 10 02:10:20 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29B2A16A4DD for ; Mon, 10 Jul 2006 02:10:20 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 746F843D4C for ; Mon, 10 Jul 2006 02:10:17 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id B34B14CDD8 for ; Mon, 10 Jul 2006 02:10:19 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 05FC04CDD7 for ; Mon, 10 Jul 2006 02:10:19 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id 0160E8A061 for ; Mon, 10 Jul 2006 12:10:15 +1000 (EST) Received: from [192.168.46.102] (unknown [192.168.46.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id F20B98A01F for ; Mon, 10 Jul 2006 12:10:14 +1000 (EST) Message-ID: <44B1B706.2030406@thebeastie.org> Date: Mon, 10 Jul 2006 12:10:14 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060404 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP Subject: PF firewall rules 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, 10 Jul 2006 02:10:20 -0000 Hi all, I have some questions about pf rules, and just want to get some things clear in my mind about how PF works, no doubt some of the answers will be obvious to some. I wanted to create some pf rules for TCP that can withstand loosing state but still utilizing the advantage of single line firewall rules. I might remove these in the future but just want to at least do some testing on a firewall setup for many reasons such as it has 2 separate links and want to try changing between the links/routes without affecting state. Take this rule for example pass out on fxp0 proto { tcp, udp, icmp } from any to any modulate state. What TCP flags rules are being used when you use "modulate state" for the TCP protocol? is it the same kind of rules as UDP as in as it largely ignores flags (as UDP has none) and if any TCP packets are going out then it just tracks that state? or is it working on the most popular Flags option rule such as "flags S/SA" If its just any flag this would mean I could just /etc/rc.d/pf restart (over resync) on the firewall gateway and the users aren't likely to notice anything as the TCP protocol would probably just resend its last sent packet believing the last one was dropped. I haven't tested but I would assume if some one was playing a UDP based game like counter-strike I could do pf restarts and they would probably not notice or have just a little pause in the game since it would only take a split second for the client side of the game to send out a UDP packet reinstating the UDP outgoing state rule, so this should be easy enough to do on TCP with lean flags (if modulate state doesn't do it). I was thinking a minimal interference keep state firewall rule would be based on any flags going out except for the R (reset) flag, is this correct? Also when I used to use IPfilter you could place firewall rules on the external interface for internal NAT IPs, I would use this to filter packets for internal IPs but place the rules on the external interface. pass out on $ext_if proto { tcp, udp, icmp } from 192.168.1.5 to any modulate state. Unlike IPFilter these rules never work with PF and it appears that any rules creating for the $ext_if interface are ignored. As I understand it translation occurs /before/ filtering, if I have NAT set on my external interface, internal IP packet filter rules on the external interface never work since the external interface Never saw any internal IPs reach it, is the correct way to see it? Given that if I used the example firewall rule listed at the bottom on this URL with NAT. http://www.openbsd.org/faq/pf/filter.html What is the recommended way to place restrictive rules on internal IPs? does any one have some examples as there are none on the OpenBSD PF guide. To me it just fits better inside my head to place these rules on the external interface in a keep state manner, while having stateless rules on the internal IPs interface just as this example ruleset has done on that web site. pass in on $int_if from $lan_net to any pass out on $int_if from any to $lan_net Thank you, Mike From owner-freebsd-pf@FreeBSD.ORG Mon Jul 10 04:46:11 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC29516A4DA for ; Mon, 10 Jul 2006 04:46:11 +0000 (UTC) (envelope-from dimas@dataart.com) Received: from relay1.dataart.com (fobos.marketsite.ru [62.152.84.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A3B343D46 for ; Mon, 10 Jul 2006 04:46:10 +0000 (GMT) (envelope-from dimas@dataart.com) Received: from e1.universe.dart.spb ([192.168.10.44]) by relay1.dataart.com with esmtp (Exim 4.62) (envelope-from ) id 1Fznei-0008nf-AA; Mon, 10 Jul 2006 08:46:00 +0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jul 2006 08:43:15 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PF firewall rules Thread-Index: AcajxcVtx58eSnXcTDG0lOSmj5CJhQAE0qVQ From: "Dmitry Andrianov" To: "Michael Vince" , Cc: Subject: RE: PF firewall rules 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, 10 Jul 2006 04:46:11 -0000 Hello. =20 > I might remove these in the future but just want to at least=20 > do some testing on a firewall setup for many reasons such as=20 > it has 2 separate links and want to try changing between the=20 > links/routes without affecting state. I'm not sure how this should work. If you change outgoing NAT address (what else "switching the link means"?), everything WILL break. With both UDP and TCP any stateful firewall on server side will reject "stream" where address changes in the middle. Even if there is no stateful firewall on their side, TCP implementation on the server will not accept these packets. > Take this rule for example > pass out on fxp0 proto { tcp, udp, icmp } from any to any=20 > modulate state. > What TCP flags rules are being used when you use "modulate=20 > state" for the TCP protocol? is it the same kind of rules as=20 > UDP as in as it largely ignores flags (as UDP has none) and=20 > if any TCP packets are going out then it just tracks that=20 > state? or is it working on the most popular Flags option rule=20 > such as "flags S/SA" AFAIK, it does not check flags. > If its just any flag this would mean I could just=20 > /etc/rc.d/pf restart (over resync) on the firewall gateway=20 > and the users aren't likely to notice anything as the TCP=20 > protocol would probably just resend its last sent packet=20 > believing the last one was dropped. Yes, if you restart pf with such a rules, the next _outgoing_ packet (what has a rule in your firewall) should restore the state. But keep in mind that a packet in opposite direction will not restore the state (because it has no separate rule for it and used to match on state only). So such a packet will be blocked. Btw, I'm not sure why you need restarting pf at all. If you need it to reload the rules, use pf -F rules -f /etc/rc.pf It will flush all rules and load new from file while keeping all the states. > What is the recommended way to place restrictive rules on=20 > internal IPs?=20 Why can't you filter incoming packets as they come on internal interface? IMHO it is more natural because you stop unwanted traffic early.. Regards, Dmitry Andrianov From owner-freebsd-pf@FreeBSD.ORG Mon Jul 10 11:03:14 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AFAA16A500 for ; Mon, 10 Jul 2006 11:03:14 +0000 (UTC) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65B6A43D49 for ; Mon, 10 Jul 2006 11:03:13 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k6AB3CGu055717 for ; Mon, 10 Jul 2006 11:03:12 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k6AB3Bju055713 for freebsd-pf@freebsd.org; Mon, 10 Jul 2006 11:03:11 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 10 Jul 2006 11:03:11 GMT Message-Id: <200607101103.k6AB3Bju055713@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 10 Jul 2006 11:03:14 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/06/15] kern/82271 pf [pf] cbq scheduler cause bad latency f [2005/09/13] kern/86072 pf [pf] Packet Filter rule not working prope o [2006/02/07] kern/92949 pf [pf] PF + ALTQ problems with latency o [2006/02/18] sparc64/93530pf Incorrect checksums when using pf's route 4 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/05/15] conf/81042 pf [pf] [patch] /etc/pf.os doesn't match Fre o [2006/02/25] kern/93825 pf [pf] pf reply-to doesn't work o [2006/03/27] kern/94992 pf [pf] [patch] pfctl complains about ALTQ m o [2006/04/21] bin/96150 pf pfctl(8) -k non-functional 4 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Jul 10 13:27:30 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16B2316A5DE for ; Mon, 10 Jul 2006 13:27:30 +0000 (UTC) (envelope-from linux@giboia.org) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id B511443D5F for ; Mon, 10 Jul 2006 13:27:27 +0000 (GMT) (envelope-from linux@giboia.org) Received: by py-out-1112.google.com with SMTP id i75so1136692pye for ; Mon, 10 Jul 2006 06:26:52 -0700 (PDT) Received: by 10.35.129.19 with SMTP id g19mr5025764pyn; Mon, 10 Jul 2006 06:26:52 -0700 (PDT) Received: by 10.35.57.19 with HTTP; Mon, 10 Jul 2006 06:26:51 -0700 (PDT) Message-ID: <6e6841490607100626n2e2bf7e0o84058e30bfc6dcb9@mail.gmail.com> Date: Mon, 10 Jul 2006 10:26:51 -0300 From: "Gilberto Villani Brito" To: "FreeBSD (PF)" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Snortsam. 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, 10 Jul 2006 13:27:30 -0000 Hi, How can I compile snortsam for PF??? I compile in my server, but without PF plugin: SnortSam, v 2.50. Copyright (c) 2001-2006 Frank Knobbe . All rights reserved. Plugin 'fwsam': v 2.4, by Frank Knobbe Plugin 'fwexec': v 2.4, by Frank Knobbe Plugin 'pix': v 2.8, by Frank Knobbe Plugin 'ciscoacl': v 2.10, by Ali Basel Plugin 'cisconullroute': v 2.2, by Frank Knobbe Plugin 'netscreen': v 2.8, by Frank Knobbe Plugin 'ipf': v 2.11, by Erik Sneep Plugin 'ipfw2': v 2.3, by Robert Rolfe Plugin 'watchguard': v 2.5, by Thomas Maier Plugin 'email': v 2.10, by Frank Knobbe Plugin 'email-blocks-only': v 2.10, by Frank Knobbe Plugin 'snmpinterfacedown': v 2.1, by Ali BASEL Plugin 'forward': v 2.1, by Frank Knobbe Gilberto From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 05:41:05 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEBA916A4DD for ; Tue, 11 Jul 2006 05:41:04 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7593043D45 for ; Tue, 11 Jul 2006 05:40:59 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 372AF4CE05 for ; Tue, 11 Jul 2006 05:40:50 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 963894CDFF for ; Tue, 11 Jul 2006 05:40:45 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id D5BD68A061; Tue, 11 Jul 2006 15:40:38 +1000 (EST) Received: from [192.168.46.102] (unknown [192.168.46.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id D22248A01F; Tue, 11 Jul 2006 15:40:38 +1000 (EST) Message-ID: <44B339D6.7090401@thebeastie.org> Date: Tue, 11 Jul 2006 15:40:38 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060404 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dmitry Andrianov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules 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, 11 Jul 2006 05:41:05 -0000 Dmitry Andrianov wrote: >Hello. > > > >>I might remove these in the future but just want to at least >>do some testing on a firewall setup for many reasons such as >>it has 2 separate links and want to try changing between the >>links/routes without affecting state. >> >> > >I'm not sure how this should work. If you change outgoing NAT address >(what else "switching the link means"?), everything WILL break. With >both UDP and TCP any stateful firewall on server side will reject >"stream" where address changes in the middle. Even if there is no >stateful firewall on their side, TCP implementation on the server will >not accept these packets. > > > >>Take this rule for example >>pass out on fxp0 proto { tcp, udp, icmp } from any to any >>modulate state. >>What TCP flags rules are being used when you use "modulate >>state" for the TCP protocol? is it the same kind of rules as >>UDP as in as it largely ignores flags (as UDP has none) and >>if any TCP packets are going out then it just tracks that >>state? or is it working on the most popular Flags option rule >>such as "flags S/SA" >> >> > >AFAIK, it does not check flags. > > That still doesn't really answer my question and I also am looking for a flags example of what would guarantee to provide the desired behavior. > > >>If its just any flag this would mean I could just >>/etc/rc.d/pf restart (over resync) on the firewall gateway >>and the users aren't likely to notice anything as the TCP >>protocol would probably just resend its last sent packet >>believing the last one was dropped. >> >> > >Yes, if you restart pf with such a rules, the next _outgoing_ packet >(what has a rule in your firewall) should restore the state. But keep in >mind that a packet in opposite direction will not restore the state >(because it has no separate rule for it and used to match on state >only). So such a packet will be blocked. > >Btw, I'm not sure why you need restarting pf at all. If you need it to >reload the rules, use > >pf -F rules -f /etc/rc.pf > >It will flush all rules and load new from file while keeping all the >states. > > As I said above I am testing, I said restart over any kind of resync, Its far easier and less error prone to just use the built in "/etc/rc.d/pf resync" command to keep state while loading in new rules, compared to typing all that out manually. pf_resync() { $pf_program -f "$pf_rules" $pf_flags } > > >>What is the recommended way to place restrictive rules on >>internal IPs? >> >> > >Why can't you filter incoming packets as they come on internal >interface? IMHO it is more natural because you stop unwanted traffic >early.. > > So your saying that to stop packets going *out* its more "natural" to type up a *block in* firewall rule to achieve the desired result, I think its is a hard point of view to argue, and this was something that was never needed with IPFilter and is probably one of its better remaining features over PF. So to block to block IP 192.168.1.17 from connecting *out* to anything on the internet I have to use a "block in" statement and there is no other way of doing this rule? block in quick on $int_if proto { tcp, udp, icmp } from 192.168.1.17 to any Mike From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 06:22:57 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37B9316A4E5 for ; Tue, 11 Jul 2006 06:22:57 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72FA443D7D for ; Tue, 11 Jul 2006 06:22:45 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id k6B6MTql008639 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 11 Jul 2006 08:22:30 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k6B6MTn5002100; Tue, 11 Jul 2006 08:22:29 +0200 (MEST) Date: Tue, 11 Jul 2006 08:22:29 +0200 From: Daniel Hartmeier To: Michael Vince Message-ID: <20060711062229.GG27312@insomnia.benzedrine.cx> References: <44B339D6.7090401@thebeastie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B339D6.7090401@thebeastie.org> User-Agent: Mutt/1.5.10i Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules 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, 11 Jul 2006 06:22:57 -0000 On Tue, Jul 11, 2006 at 03:40:38PM +1000, Michael Vince wrote: > That still doesn't really answer my question and I also am looking for a > flags example of what would guarantee to provide the desired behavior. If you don't specify a 'flags' option, the rule will match any flags combination. Don't use 'modulate state' in this case. If you remove the state, and create a second state from another packet of the ongoing connection, 'modulate state' will pick a random (most certainly different) sequence number modulator, and the connection will immediately stall when the endpoints see the new and completely out-of-bounds sequence numbers. You can only use 'modulate state' when you create state on the initial SYN of a connection ('flags S/SA' is recommended there) and preserve that state entry for the duration of the connection. If you lose the state entry, the connection will stall. So, use 'keep state' instead. But that won't work, in general, either. Nowadays many hosts enable TCP window scaling and use >0 scaling factors. For pf to support that properly, it must also create state on the initial SYN. Creating a state from any packet later than the SYN will eventually stall the connection. If you know TCP window scaling isn't used, you can create state on any packet, but in general you should use 'flags S/SA' on state creating rules. In short, don't lightly flush your states. There's no reason to flush states in normal operation (like, when reloading the ruleset). If you don't want to have to reestablish connections when the firewall must be rebooted, there's pfsync to synchronize states to a backup firewall and carp to do automatic failover. > So your saying that to stop packets going *out* its more "natural" to > type up a *block in* firewall rule to achieve the desired result, I > think its is a hard point of view to argue, and this was something that > was never needed with IPFilter and is probably one of its better > remaining features over PF. Maybe you can argue what seems more intuitive to you, but technically, it's more straight-forward to block packets as early as possible (for forwarded packets that is on the input path). What's the point of allowing a packet in on the internal interface, have the stack do a route lookup and try forward the packet out through the external interface, just to then block it there? Waste of CPU cycles and network buffers. If for some technical reasons you want to filter on the external interface based on source address lost due to NAT translation, you can try tagging on the internal interface and distinguish based on tags on the external interface. But if you'd just prefer to not have "translation occur before filtering", I guess you're way too late to suggest that. It was a deliberate design choice, and people grew to appreciate and rely on this order. Daniel From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 06:48:47 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76FE016A4DD for ; Tue, 11 Jul 2006 06:48:47 +0000 (UTC) (envelope-from kian.mohageri@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD2AE43D46 for ; Tue, 11 Jul 2006 06:48:46 +0000 (GMT) (envelope-from kian.mohageri@gmail.com) Received: by ug-out-1314.google.com with SMTP id e2so1043265ugf for ; Mon, 10 Jul 2006 23:48:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hR/EAjUYwMDl20AlmFTrJ5npK/akIIDgdqHQHuc14VvJBmWUJf8VBTMm/rNdZ9lUecIWLAbZ4BIAJ342JxY6fnoA232HPgYvuLIrZIVE2WpzykEpljmN0GGhiSD3LRIWdfXBkghdjvezlFmKrNcFviQ2dxDsB8qkNhfH/HIBgDs= Received: by 10.78.140.17 with SMTP id n17mr2033986hud; Mon, 10 Jul 2006 23:48:45 -0700 (PDT) Received: by 10.78.40.1 with HTTP; Mon, 10 Jul 2006 23:48:45 -0700 (PDT) Message-ID: Date: Mon, 10 Jul 2006 23:48:45 -0700 From: "Kian Mohageri" To: "Michael Vince" In-Reply-To: <44B339D6.7090401@thebeastie.org> MIME-Version: 1.0 References: <44B339D6.7090401@thebeastie.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules 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, 11 Jul 2006 06:48:47 -0000 On 7/10/06, Michael Vince wrote: > > Dmitry Andrianov wrote: > So to block to block IP 192.168.1.17 from connecting *out* to anything > on the internet I have to use a "block in" statement and there is no > other way of doing this rule? > block in quick on $int_if proto { tcp, udp, icmp } from 192.168.1.17 to > any I'm not sure if I'm understanding you correctly, but if having the direction in the rule is confusing to you, you can leave it out: block quick on $int_If proto { tcp, udp, icmp } from 192.168.1.17 to any From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 08:17:05 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 684EB16A4DA for ; Tue, 11 Jul 2006 08:17:05 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2CA343D4C for ; Tue, 11 Jul 2006 08:17:04 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 7426B4CE05 for ; Tue, 11 Jul 2006 08:17:09 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 73AEE4CDFF for ; Tue, 11 Jul 2006 08:17:08 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id DC02A8A06F; Tue, 11 Jul 2006 18:17:01 +1000 (EST) Received: from [192.168.46.102] (unknown [192.168.46.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id CADAE8A06D; Tue, 11 Jul 2006 18:17:01 +1000 (EST) Message-ID: <44B35E7D.5010107@thebeastie.org> Date: Tue, 11 Jul 2006 18:17:01 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060404 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Hartmeier References: <44B339D6.7090401@thebeastie.org> <20060711062229.GG27312@insomnia.benzedrine.cx> In-Reply-To: <20060711062229.GG27312@insomnia.benzedrine.cx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules 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, 11 Jul 2006 08:17:05 -0000 Daniel Hartmeier wrote: >On Tue, Jul 11, 2006 at 03:40:38PM +1000, Michael Vince wrote: > > > >>That still doesn't really answer my question and I also am looking for a >>flags example of what would guarantee to provide the desired behavior. >> >> > >If you don't specify a 'flags' option, the rule will match any flags >combination. > >Don't use 'modulate state' in this case. If you remove the state, and >create a second state from another packet of the ongoing connection, >'modulate state' will pick a random (most certainly different) sequence >number modulator, and the connection will immediately stall when the >endpoints see the new and completely out-of-bounds sequence numbers. > >You can only use 'modulate state' when you create state on the initial >SYN of a connection ('flags S/SA' is recommended there) and preserve >that state entry for the duration of the connection. If you lose the >state entry, the connection will stall. So, use 'keep state' instead. > >But that won't work, in general, either. Nowadays many hosts enable TCP >window scaling and use >0 scaling factors. For pf to support that >properly, it must also create state on the initial SYN. Creating a state >from any packet later than the SYN will eventually stall the connection. >If you know TCP window scaling isn't used, you can create state on any >packet, but in general you should use 'flags S/SA' on state creating >rules. > > >In short, don't lightly flush your states. There's no reason to flush >states in normal operation (like, when reloading the ruleset). If you >don't want to have to reestablish connections when the firewall must be >rebooted, there's pfsync to synchronize states to a backup firewall and >carp to do automatic failover. > > So ultimately what your saying is PF is too clever now and can never be simplified like UDP state modes for single line firewall rules using rough careless flags options on a firewall rules where everything is just going out keep state and otherwise blocking all in. This is fair enough, I just had to ask. To me it just seemed a bit unreasonable to bit so stricted about TCP while being so lean and easy going and in one sense clever with UDP and ICMP. While the inherited TCP flags give you the ability to be more strict about it all I just would of thought if I want to have a easy/non strict going firewall I would be able to configure it like that with no problems. While I don't understand the TCP protocol as well as you guys, I do tent to see as protocol racism, making it all easy for the white UDP people and being tough on the TCP black people (if it was a firewall/country of largely white population in the 50s) > > >>So your saying that to stop packets going *out* its more "natural" to >>type up a *block in* firewall rule to achieve the desired result, I >>think its is a hard point of view to argue, and this was something that >>was never needed with IPFilter and is probably one of its better >>remaining features over PF. >> >> > >Maybe you can argue what seems more intuitive to you, but technically, >it's more straight-forward to block packets as early as possible (for >forwarded packets that is on the input path). What's the point of >allowing a packet in on the internal interface, have the stack do a >route lookup and try forward the packet out through the external >interface, just to then block it there? Waste of CPU cycles and network >buffers. > >If for some technical reasons you want to filter on the external >interface based on source address lost due to NAT translation, you can >try tagging on the internal interface and distinguish based on tags on >the external interface. > >But if you'd just prefer to not have "translation occur before >filtering", I guess you're way too late to suggest that. It was a >deliberate design choice, and people grew to appreciate and rely on this >order. > > Darn, I had wondered about this for a bit now, so all IPFilter users have to readapt their mind frame for PF, I don't know why but I have had a little bit of a hard time with this, I guess the reasons I liked IPFilter and also PF has been because its its very english language like syntax and mind frame. One way to kind of add onto the syntax but still keep the "out" word in there would be to place the keyword "kernel" to help let the user know which direction the packet is going in and out of the internal interface. I don't know if it is the best solution but I do get to keep my "out" word even if its a bit selfish. block out quick on $int_if kernel proto { tcp, udp, icmp } from 192.168.1.17 to any Yes, one of the issues I had against blocking so early on the internal interface is it ruins the ability to run services on internal NAT ip servers using RDR for internal IPs but providing a single IP to all users behind the firewall and for those over the Internet. If I want to block some IPs from reaching the Internet but still be able to use the web server behind NAT firewall I have to allow extra firewall rules for those IPs before they hit the firewall rule above that blocks everything going out on the internal interface. Considering the above firewall rule depending on how it was implemented might not work another syntax/feature that could allow packets going in to the external interface from the kernel side of things block in quick on $ext_if kernel proto { tcp, udp, icmp } from 192.168.1.17 to any While I am back to square 1 with the "in" statement it would still me from having to have special rules allowing stuff back in to internal redirected services. Mike From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 08:32:14 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BA1216A549 for ; Tue, 11 Jul 2006 08:32:14 +0000 (UTC) (envelope-from dimas@dataart.com) Received: from relay1.dataart.com (fobos.marketsite.ru [62.152.84.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51AF243DE6 for ; Tue, 11 Jul 2006 08:32:10 +0000 (GMT) (envelope-from dimas@dataart.com) Received: from e1.universe.dart.spb ([192.168.10.44]) by relay1.dataart.com with esmtp (Exim 4.62) (envelope-from ) id 1G0Df2-000I4n-5V; Tue, 11 Jul 2006 12:32:04 +0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jul 2006 12:29:17 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PF firewall rules Thread-Index: Acakr9GeGxEvjJQRSveC5+xjjJy5SgAExwCQ From: "Dmitry Andrianov" To: "Michael Vince" Cc: freebsd-pf@freebsd.org Subject: RE: PF firewall rules 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, 11 Jul 2006 08:32:14 -0000 Hi. > >Why can't you filter incoming packets as they come on internal > >interface? IMHO it is more natural because you stop unwanted traffic > >early.. > > =20 > > > So your saying that to stop packets going *out* its more "natural" to=20 > type up a *block in* firewall rule to achieve the desired result, I=20 > think its is a hard point of view to argue, and this was=20 > something that=20 > was never needed with IPFilter and is probably one of its better=20 > remaining features over PF. It only depends on your personal preferences - I used IPFilter for about 4 years before switching to pf and I was using exactly the same approach there - the "pass out ... keep state" used to allow all outbound traffic while routed was making its decisions solely on inbound packets. > So to block to block IP 192.168.1.17 from connecting *out* to=20 > anything=20 > on the internet I have to use a "block in" statement and there is no=20 > other way of doing this rule? > block in quick on $int_if proto { tcp, udp, icmp } from=20 > 192.168.1.17 to any Even block in quick on $int_if from 192.168.1.17 to any Why not? If you need allow this host connecting to gateway itself, you may use "pass in quick" rules before that one. Or vice versa - you can use block in on $int_if from 192.168.1.17 to any (without "quick") and then allow only some destinations/protocols. And finally you can tag your packets and then decide whenever to pass that packet on not based on tags. Regards, Dmitry Andrianov From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 10:02:29 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEC5016A4DF for ; Tue, 11 Jul 2006 10:02:29 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 450C043D45 for ; Tue, 11 Jul 2006 10:02:29 +0000 (GMT) (envelope-from Greg.Hennessy@nviz.net) Received: from gw2.local.net (unknown [62.3.210.251]) by smtp.nildram.co.uk (Postfix) with ESMTP id F188A2375F1 for ; Tue, 11 Jul 2006 11:02:24 +0100 (BST) From: "Greg Hennessy" To: "'Michael Vince'" , "'Daniel Hartmeier'" Date: Tue, 11 Jul 2006 11:02:25 +0100 Message-ID: <000c01c6a4d1$1c37b1d0$0a00a8c0@thebeast> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44B35E7D.5010107@thebeastie.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcakxFTO5xUkxWATRQq2hkW/XcSnXQAArArg X-OriginalArrivalTime: 11 Jul 2006 10:02:25.0517 (UTC) FILETIME=[1C37B1D0:01C6A4D1] Cc: freebsd-pf@freebsd.org Subject: RE: PF firewall rules 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, 11 Jul 2006 10:02:29 -0000 > > So ultimately what your saying is PF is too clever now and > can never be simplified like UDP state modes for single line The notion of UDP keeping state is overstated. Basic layer 3 'keep state' for UDP is nothing more than a watchdog timer tracking how long it was since the last packet for the reverse flow arrived. > firewall rules using rough careless flags options on a > firewall rules where everything is just going out keep state One cannot 'keep state' for TCP in any meaningful fashion without tracking the flags + sequencing. If you want a primitive packet filtered ACL from point a to b for TCP. pass out on int inet proto tcp from a to b pass in on int inet proto tcp from b to a will match all packets and allow that flow. > and otherwise blocking all in. > > This is fair enough, I just had to ask. To me it just seemed > a bit unreasonable to bit so stricted about TCP while being > so lean and easy going and in one sense clever with UDP and ICMP. At layer 3 there is nothing to track in UDP to keep state except the quad in the header. UDP by its very nature is connectionless. > While the inherited TCP flags give you the ability to be more > strict about it all I just would of thought if I want to have > a easy/non strict going firewall I would be able to configure > it like that with no problems. > While I don't understand the TCP protocol as well as you > guys, I do tent to see as protocol racism, making it all easy > for the white UDP people and being tough on the TCP black > people (if it was a firewall/country of largely white > population in the 50s) Oh puhleeze. Get some of idea of the fundamental difference between TCP and UDP before making such a ridiculous statement. In particular I recommend reading TCP Illustrated by W Richard Stevens. > >But if you'd just prefer to not have "translation occur before > >filtering", I guess you're way too late to suggest that. It was a > >deliberate design choice, and people grew to appreciate and rely on > >this order. > > > > > Darn, I had wondered about this for a bit now, so all > IPFilter users have to readapt their mind frame for PF, We all had to do it, you will find once you get used to it, that the equivalent PF policy is about half the size of the IPF one as a consequence. > One way to kind of add onto the syntax but still keep the > "out" word in there would be to place the keyword "kernel" to > help let the user know which direction the packet is going in > and out of the internal interface. Err, that's what matching against direction in the rule base does. > I don't know if it is the > best solution but I do get to keep my "out" word even if its > a bit selfish. That's what tags are for. > > block out quick on $int_if kernel proto { tcp, udp, icmp } from > 192.168.1.17 to any > > Yes, one of the issues I had against blocking so early on the > internal interface is it ruins the ability to run services on > internal NAT ip servers using RDR for internal IPs but > providing a single IP to all users behind the firewall and > for those over the Internet. Are you saying that you cannot do a transparent redirect on the inside interface of the form ? rdr pass on inside $TCP from -> $PublicVIP port something -> $DMZ-RFC-ADDRESS port something > If I want to block some IPs from reaching the Internet but > still be able to use the web server behind NAT firewall I > have to allow extra firewall rules for those IPs before they > hit the firewall rule above that blocks everything going out > on the internal interface. If the service sits on the LAN rather than on a DMZ interface, this is most likely going to pear shaped unless you start disabling ICMP redirects everywhere. >From a design perspective hosting any external facing service directly on the most trusted part of the network is *not* a good idea. Greg From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 10:22:33 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 972A816A4E1 for ; Tue, 11 Jul 2006 10:22:33 +0000 (UTC) (envelope-from rmaglasang@infoweapons.com) Received: from ws2.infoweapons.com (ws2.infoweapons.com [58.71.34.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0310343D5A for ; Tue, 11 Jul 2006 10:22:31 +0000 (GMT) (envelope-from rmaglasang@infoweapons.com) Received: from [10.3.1.41] ([10.3.1.41] RDNS failed) by ws2.infoweapons.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 18:22:20 +0800 Message-ID: <44B37BA0.7030405@infoweapons.com> Date: Tue, 11 Jul 2006 18:21:20 +0800 From: "Ronnel P. Maglasang" User-Agent: Thunderbird 1.5 (X11/20060613) MIME-Version: 1.0 To: Greg Hennessy References: <000c01c6a4d1$1c37b1d0$0a00a8c0@thebeast> In-Reply-To: <000c01c6a4d1$1c37b1d0$0a00a8c0@thebeast> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2006 10:22:20.0882 (UTC) FILETIME=[E4B5EB20:01C6A4D3] Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules 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, 11 Jul 2006 10:22:33 -0000 Greg Hennessy wrote: > The notion of UDP keeping state is overstated. > > Basic layer 3 'keep state' for UDP is nothing more than a watchdog timer > tracking how long it was since the last packet for the reverse flow arrived. > > is it safe to say to just remove the "keep state" behavior for udp and other connectionless packets? i really think this is a vulnerability. please note the pf always creates states for outgoing packets, even its udp. >> firewall rules using rough careless flags options on a >> firewall rules where everything is just going out keep state >> > > One cannot 'keep state' for TCP in any meaningful fashion without tracking > the flags + sequencing. > > If you want a primitive packet filtered ACL from point a to b for TCP. > > pass out on int inet proto tcp from a to b > pass in on int inet proto tcp from b to a > > will match all packets and allow that flow. > > >> and otherwise blocking all in. >> >> This is fair enough, I just had to ask. To me it just seemed >> a bit unreasonable to bit so stricted about TCP while being >> so lean and easy going and in one sense clever with UDP and ICMP. >> > > At layer 3 there is nothing to track in UDP to keep state except the quad in > the header. > > UDP by its very nature is connectionless. > > >> While the inherited TCP flags give you the ability to be more >> strict about it all I just would of thought if I want to have >> a easy/non strict going firewall I would be able to configure >> it like that with no problems. >> While I don't understand the TCP protocol as well as you >> guys, I do tent to see as protocol racism, making it all easy >> for the white UDP people and being tough on the TCP black >> people (if it was a firewall/country of largely white >> population in the 50s) >> > > Oh puhleeze. Get some of idea of the fundamental difference between TCP and > UDP before making such a ridiculous statement. > > In particular I recommend reading TCP Illustrated by W Richard Stevens. > > >>> But if you'd just prefer to not have "translation occur before >>> filtering", I guess you're way too late to suggest that. It was a >>> deliberate design choice, and people grew to appreciate and rely on >>> this order. >>> >>> >>> >> Darn, I had wondered about this for a bit now, so all >> IPFilter users have to readapt their mind frame for PF, >> > > We all had to do it, you will find once you get used to it, that the > equivalent PF policy is about half the size of the IPF one as a consequence. > > > >> One way to kind of add onto the syntax but still keep the >> "out" word in there would be to place the keyword "kernel" to >> help let the user know which direction the packet is going in >> and out of the internal interface. >> > > Err, that's what matching against direction in the rule base does. > > >> I don't know if it is the >> best solution but I do get to keep my "out" word even if its >> a bit selfish. >> > > That's what tags are for. > > >> block out quick on $int_if kernel proto { tcp, udp, icmp } from >> 192.168.1.17 to any >> >> Yes, one of the issues I had against blocking so early on the >> internal interface is it ruins the ability to run services on >> internal NAT ip servers using RDR for internal IPs but >> providing a single IP to all users behind the firewall and >> for those over the Internet. >> > > > Are you saying that you cannot do a transparent redirect on the inside > interface of the form ? > > rdr pass on inside $TCP from -> $PublicVIP port something -> > $DMZ-RFC-ADDRESS port something > > > >> If I want to block some IPs from reaching the Internet but >> still be able to use the web server behind NAT firewall I >> have to allow extra firewall rules for those IPs before they >> hit the firewall rule above that blocks everything going out >> on the internal interface. >> > > If the service sits on the LAN rather than on a DMZ interface, this is most > likely going to pear shaped unless you start disabling ICMP redirects > everywhere. > > >From a design perspective hosting any external facing service directly on > the most trusted part of the network is *not* a good idea. > > > Greg > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 10:39:35 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF0B416A4E1 for ; Tue, 11 Jul 2006 10:39:35 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8066443D49 for ; Tue, 11 Jul 2006 10:39:35 +0000 (GMT) (envelope-from Greg.Hennessy@nviz.net) Received: from gw2.local.net (unknown [62.3.210.251]) by smtp.nildram.co.uk (Postfix) with ESMTP id DBBD7236B9E for ; Tue, 11 Jul 2006 11:39:31 +0100 (BST) From: "Greg Hennessy" To: "'Ronnel P. Maglasang'" Date: Tue, 11 Jul 2006 11:39:27 +0100 Keywords: freebsd-pf Message-ID: <000301c6a4d6$48d7b2d0$0a00a8c0@thebeast> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44B37BA0.7030405@infoweapons.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acak1RjvTQASZIGST6aMkQsOakVCuAAALokg X-OriginalArrivalTime: 11 Jul 2006 10:39:27.0869 (UTC) FILETIME=[48D7B2D0:01C6A4D6] Cc: freebsd-pf@freebsd.org Subject: RE: PF firewall rules 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, 11 Jul 2006 10:39:36 -0000 > > > > > is it safe to say to just remove the "keep state" behavior > for udp and other connectionless packets? No. Anything but. If you don't keep state, you would have to specifically code wide open ingress packet filtering rules for reply traffic. Greg From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 11:59:52 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FF1C16A4E6 for ; Tue, 11 Jul 2006 11:59:52 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BBA143D4C for ; Tue, 11 Jul 2006 11:59:50 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 13310 invoked from network); 11 Jul 2006 11:59:48 -0000 Received: from unknown (HELO localhost) (775067@[217.50.148.2]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 11 Jul 2006 11:59:48 -0000 Date: Tue, 11 Jul 2006 13:59:32 +0200 From: Fabian Keil To: freebsd-pf@freebsd.org Message-ID: <20060711135932.39a04e72@localhost> In-Reply-To: <20060708131225.51feb8f3@localhost> References: <44AF5C34.8000801@bitparts.org> <20060708090249.GB32262@insomnia.benzedrine.cx> <20060708131225.51feb8f3@localhost> X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; i386-portbld-freebsd6.1) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2006-08-19.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_LrTd5SOP_K_vbNtSrnVytUY; protocol="application/pgp-signature"; micalg=PGP-SHA1 Subject: Re: pfstat 2.2 and FreeBSD 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, 11 Jul 2006 11:59:52 -0000 --Sig_LrTd5SOP_K_vbNtSrnVytUY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Daniel Hartmeier wrote: > > http://www.benzedrine.cx/pfstat.html > >=20 > > (make sure to grab pfstat-2.2.tar.gz, older versions didn't fetch > > queue stats, either) >=20 > Yesterday I installed pfstat 2.2 on FreeBSD RELENG_6. It compiled > cleanly, but fetching the statistics failed with "ioctl > DIOCIGETIFACES not supported by device" (not the exact wording). >=20 > To get it running I used: > > (update for sysutils/pfstat from 1.7 to 2.2) I forgot to mention that the patch was incomplete and did not install pfstatd.8 and pfstatd, it does now. Additionally the default configuration is read from ${PREFIX}/etc/pfstat.conf instead of /etc/pfstat.conf. =20 > Could someone with FreeBSD PF foo please check patch-pf.c > for correctness? I added two testing queues and as the graphs[1] match the output of pfctl, I assume the patch is correct. [1] http://tor.fabiankeil.de/pf-stats/ Fabian --=20 http://www.fabiankeil.de/ --Sig_LrTd5SOP_K_vbNtSrnVytUY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEs5KyjV8GA4rMKUQRApP+AJ0b6xtDPs+eVUXTF+27O6GZDyzG4wCdEQoH a+3RtSOKvZqn19kKqbRcdS4= =wl8l -----END PGP SIGNATURE----- --Sig_LrTd5SOP_K_vbNtSrnVytUY-- From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 12:17:30 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50EDC16A4DA for ; Tue, 11 Jul 2006 12:17:30 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8110A43D6E for ; Tue, 11 Jul 2006 12:17:18 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 633074CDFD for ; Tue, 11 Jul 2006 12:17:14 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 3B9014CDD8 for ; Tue, 11 Jul 2006 12:17:13 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id 5E9D48A065; Tue, 11 Jul 2006 22:17:06 +1000 (EST) Received: from [192.168.0.4] (ppp157-158.static.internode.on.net [150.101.157.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id 117768A01F; Tue, 11 Jul 2006 22:17:06 +1000 (EST) Message-ID: <44B396C3.90205@thebeastie.org> Date: Tue, 11 Jul 2006 22:17:07 +1000 From: Michael VInce User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Greg Hennessy References: <000c01c6a4d1$1c37b1d0$0a00a8c0@thebeast> In-Reply-To: <000c01c6a4d1$1c37b1d0$0a00a8c0@thebeast> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules 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, 11 Jul 2006 12:17:30 -0000 Greg Hennessy wrote: > > > >> So ultimately what your saying is PF is too clever now and >> can never be simplified like UDP state modes for single line >> > > The notion of UDP keeping state is overstated. > > Basic layer 3 'keep state' for UDP is nothing more than a watchdog timer > tracking how long it was since the last packet for the reverse flow arrived. > > >> firewall rules using rough careless flags options on a >> firewall rules where everything is just going out keep state >> > > One cannot 'keep state' for TCP in any meaningful fashion without tracking > the flags + sequencing. > > If you want a primitive packet filtered ACL from point a to b for TCP. > > pass out on int inet proto tcp from a to b > pass in on int inet proto tcp from b to a > > will match all packets and allow that flow. > While a lot of people are telling me things I already know, its nice to be refreshed, on the other side I have seen a few ideas for PF now to make maybe slightly cleaner firewall rule set, thanks for this. I did mention it a few times but I suppose I wasn't clear about it, but I really do want to use "single line firewall rules", and the only way to do this is to keep state, if there are other ways/rules to have really flexible firewall but still with stateful inspection with a small amount of rules I would like to see them. Using double line firewall rules (stateless) is going way past even my goal of testing out a less strict (easy going) firewall setup. My goal has been to have a really simple firewall rule set, strictly single line rules per access rule (for the basic stuff), I aimed to have all out going connections have only firewall rules that had the keyword "out" for any out going connections or blocks with no "in" rules for what I would normally see the other way around, and every thing else blocked. Also to have the TCP keep state rules lean to the point their behavior was similar to UDP as in to really pay no attention to flags so I could continue with my "testing" and reset the state table as much as I like even if I can use the /etc/rc.d/pf resync or the other methods to reload rules but still keep the state table. If you follow these rules very strictly enough they can not be done with PF but are a fair bit easier to do with IPFilter. I thought PF being a new firewall technology that it could do everything IPFilter could do in the exact same fashion and more, but it can't and I am glad I asked. Realistically everyone is right to point out that there are plenty of compromises such as block "in" on the internal interface etc, I just wasn't sure these were the only options and I just once again had to ask. Some other people might be wondering the same things as me, you never know. I really was hoping that I could create the rules exactly as how I would imagine them to be, but I am ready to make some compromises and I am actually have a good feeling I will be more happy with my new rules setup then before simply because I know more about my options and limitations. Just like most people I don't see it any other way then the fact that single line firewall rules are great, and I never have and never will be making any compromises on this. I just don't know if I agree on what appears to be overly strict behavior on TCP in regards to its state activity and how it could be done for some firewall scenarios like a home firewall, but again people can just point out I can just keep my state table and reload my rules while using stick keep state methods, I just want to test the alternative limits for situations I don't want to have to go into, isn't what flexible firewalling technology is about? As for UDP being stateless I still do see the big benefit of using the stateful rules for what they are worth as a more sure way of tracking those packets of "who" is initiating those connections, if I go back to the true old school ways and have 2 firewall rules for every rule over what could be done with a single stateful rule I would still taking a step back as I can't be sure some ones loading up some of the old classic back door UDP trojans into my network by 'initiating' connections into my network. Mike From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 12:26:52 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3C3516A4DA for ; Tue, 11 Jul 2006 12:26:52 +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 BF66D43D68 for ; Tue, 11 Jul 2006 12:26:50 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.178.212] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1G0HKA1UHn-0001NW; Tue, 11 Jul 2006 14:26:46 +0200 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Tue, 11 Jul 2006 14:26:39 +0200 User-Agent: KMail/1.9.1 References: <44AF5C34.8000801@bitparts.org> <20060708131225.51feb8f3@localhost> <20060711135932.39a04e72@localhost> In-Reply-To: <20060711135932.39a04e72@localhost> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1256990.XEG3ILCyMK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200607111426.45541.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Subject: Re: pfstat 2.2 and FreeBSD 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, 11 Jul 2006 12:26:52 -0000 --nextPart1256990.XEG3ILCyMK Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 11 July 2006 13:59, Fabian Keil wrote: > Fabian Keil wrote: > > Daniel Hartmeier wrote: > > > http://www.benzedrine.cx/pfstat.html > > > > > > (make sure to grab pfstat-2.2.tar.gz, older versions didn't fetch > > > queue stats, either) > > > > Yesterday I installed pfstat 2.2 on FreeBSD RELENG_6. It compiled > > cleanly, but fetching the statistics failed with "ioctl > > DIOCIGETIFACES not supported by device" (not the exact wording). > > > > To get it running I used: > > > > (update for sysutils/pfstat from 1.7 to 2.2) > > I forgot to mention that the patch was incomplete > and did not install pfstatd.8 and pfstatd, it does now. > Additionally the default configuration is read from > ${PREFIX}/etc/pfstat.conf instead of /etc/pfstat.conf. > > > Could someone with FreeBSD PF foo please check patch-pf.c > > for correctness? > > I added two testing queues and as the graphs[1] match > the output of pfctl, I assume the patch is correct. Looks good. I will commit it later unless somebody screams "no". Thanks f= or=20 the good work! > [1] http://tor.fabiankeil.de/pf-stats/ Neat. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1256990.XEG3ILCyMK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEs5kFXyyEoT62BG0RAnQ9AJ9Cv3F8D1+h1GJEk5jzrMwWMZ4vAgCdE6X8 Tu71+GhTg2SjQ5EnMUuQTNU= =pY+w -----END PGP SIGNATURE----- --nextPart1256990.XEG3ILCyMK-- From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 12:54:49 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79C9C16A4DA for ; Tue, 11 Jul 2006 12:54:49 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2DC743D5C for ; Tue, 11 Jul 2006 12:54:48 +0000 (GMT) (envelope-from Greg.Hennessy@nviz.net) Received: from gw2.local.net (unknown [62.3.210.251]) by smtp.nildram.co.uk (Postfix) with ESMTP id 3921D2377B3 for ; Tue, 11 Jul 2006 13:54:44 +0100 (BST) From: "Greg Hennessy" To: "'Michael VInce'" Date: Tue, 11 Jul 2006 13:54:45 +0100 Keywords: freebsd-pf Message-ID: <001801c6a4e9$2f8bbca0$0a00a8c0@thebeast> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acak5dx40VxxuNPTSHCdmB7RjPjOrgAATUxA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44B396C3.90205@thebeastie.org> X-OriginalArrivalTime: 11 Jul 2006 12:54:45.0866 (UTC) FILETIME=[2F8BBCA0:01C6A4E9] Cc: freebsd-pf@freebsd.org Subject: RE: PF firewall rules 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, 11 Jul 2006 12:54:49 -0000 > > I did mention it a few times but I suppose I wasn't clear > about it, but I really do want to use "single line firewall > rules", and the only way to do this is to keep state, if > there are other ways/rules to have really flexible firewall > but still with stateful inspection with a small amount of > rules I would like to see them. Yes, RTFMP on tag and tagged. Create generic egress rules on all the filtered interfaces with 'tagged' E.g pass out on {int1,int2,int3} $TCP to any tagged through $KSF use tag on ingress rules as appropriate. E.g pass in on int1 $TCP from a to b tag through $KSF Or.. in an environment with no nat, use interface classes on bidirectional rules combined with anti spoofing. Greg From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 23:56:07 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5747816A4DD for ; Tue, 11 Jul 2006 23:56:07 +0000 (UTC) (envelope-from solinym@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 951BB43D45 for ; Tue, 11 Jul 2006 23:56:06 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by py-out-1112.google.com with SMTP id c63so31474pyc for ; Tue, 11 Jul 2006 16:55:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pM/y9HxGE+iIZfWhvtNRxMm7ii0MSVW2kHVd7UeDjq+/0tHJNaWLEls81wr5cpLj6zAPiTXtwNTFFx10OlfqzsT17+8O2Kh5VDmte0AyKscik5+WvWkRZRrk024pJL+Z4qPHV/VN/Nb9zb+wICrgrBnBHk8LpwmADmd6K4/Orm8= Received: by 10.35.129.19 with SMTP id g19mr154627pyn; Tue, 11 Jul 2006 16:55:32 -0700 (PDT) Received: by 10.35.34.3 with HTTP; Tue, 11 Jul 2006 16:55:32 -0700 (PDT) Message-ID: Date: Tue, 11 Jul 2006 18:55:32 -0500 From: "Travis H." To: "Kian Mohageri" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44B339D6.7090401@thebeastie.org> Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules 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, 11 Jul 2006 23:56:07 -0000 On 7/11/06, Kian Mohageri wrote: > I'm not sure if I'm understanding you correctly, but if having the direction > in the rule is confusing to you, you can leave it out: > > block quick on $int_If proto { tcp, udp, icmp } from 192.168.1.17 to any Better yet, drop the "on $int_if", since if the 192.168/16 block is allocated to LAN hosts, you probably don't want to allow it in on any other interface, either. And why enumerate TCP, UDP, ICMP? Are you trying to allow IGMP from this host? What you don't know can hurt you! I say drop the protocol specification too. This simplfies your rule to: block quick from 192.168.1.17 to any See? Using lists causes several rules to be created, so as well as being simpler, this is more efficient too. -- Resolve is what distinguishes a person who has failed from a failure. Unix "guru" for sale or rent - http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 From owner-freebsd-pf@FreeBSD.ORG Wed Jul 12 06:14:36 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC2DB16A4DD for ; Wed, 12 Jul 2006 06:14:36 +0000 (UTC) (envelope-from adam.clark@ngv.vic.gov.au) Received: from monet2.ngv.vic.gov.au (monet2.ngv.vic.gov.au [203.18.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E3F43D46 for ; Wed, 12 Jul 2006 06:14:35 +0000 (GMT) (envelope-from adam.clark@ngv.vic.gov.au) Received: from monet2.ngv.vic.gov.au (monet2.ngv.vic.gov.au [127.0.0.1]) by localhost.ngv.vic.gov.au (Postfix) with ESMTP id 120393400D for ; Wed, 12 Jul 2006 16:14:34 +1000 (EST) Received: from ngv.vic.gov.au (titian.boh.ngv.local [172.16.22.25]) by monet2.ngv.vic.gov.au (Postfix) with ESMTP id 07BFC34002 for ; Wed, 12 Jul 2006 16:14:34 +1000 (EST) Received: from mail pickup service by ngv.vic.gov.au with Microsoft SMTPSVC; Wed, 12 Jul 2006 16:14:33 +1000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jul 2006 16:14:32 +1000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ALTQ on a process on the router thread-index: AcalenH0atsbt/fASaCayE4HLSQmWw== From: "Adam Clark" To: X-OriginalArrivalTime: 12 Jul 2006 06:14:33.0916 (UTC) FILETIME=[71B8AFC0:01C6A57A] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.52.1006-14562.001 X-TM-AS-Result: No--0.500000-5.000000-1 Subject: ALTQ on a process on the router 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, 12 Jul 2006 06:14:36 -0000 Hi, I am trying to perform ALTQ on a process running on the router itself. I have bound the application to to internal IP address (10.10.10.254), that which is bound to the internal interface. When I log-all packets passing out this interface, I cannot see any data going to 10.10.10.254, just other hosts on my network. This is bound to be how it is meant to be, but its not healping my situation. Is there anyway to make the kernel put frames destined for itself on the appropriate interface? Cheers Adam Clark Network Administrator National Gallery of Victoria PO Box 7259 St Kilda Road Vic 8004 Telephone: +61 3 8620 2369=20 Fax: +61 3 8620 2565 www.ngv.vic.gov.au Keep informed of the latest NGV exhibitions, special events and programs = at The Ian Potter Centre: NGV Australia and NGV International by = subscribing to NGV@RT, the NGV's free e-newsletter. DISCLAIMER: This email and any files transmitted with it are = confidential and intended solely for freebsd-pf@freebsd.org. If you are = not the named addressee you should not disseminate, copy or alter this = email. WARNING: Although National Gallery of Victoria has taken = reasonable precautions to ensure no viruses are present in this email, = the organisation cannot accept responsibility for any loss or damage = arising from the use of this email or attachment. From owner-freebsd-pf@FreeBSD.ORG Wed Jul 12 09:57:28 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 239CF16A4DD for ; Wed, 12 Jul 2006 09:57:28 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5BCF43D5A for ; Wed, 12 Jul 2006 09:57:25 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 24F014CD84; Wed, 12 Jul 2006 09:57:27 +0000 (GMT) Received: from [192.168.0.6] (ppp157-158.static.internode.on.net [150.101.157.158]) by p4.roq.com (Postfix) with ESMTP id 4357C4CD73; Wed, 12 Jul 2006 09:57:26 +0000 (GMT) Message-ID: <44B4C782.2@thebeastie.org> Date: Wed, 12 Jul 2006 19:57:22 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20060526 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Hennessy References: <001801c6a4e9$2f8bbca0$0a00a8c0@thebeast> In-Reply-To: <001801c6a4e9$2f8bbca0$0a00a8c0@thebeast> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules 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, 12 Jul 2006 09:57:28 -0000 Greg Hennessy wrote: > > > >>I did mention it a few times but I suppose I wasn't clear >>about it, but I really do want to use "single line firewall >>rules", and the only way to do this is to keep state, if >>there are other ways/rules to have really flexible firewall >>but still with stateful inspection with a small amount of >>rules I would like to see them. >> >> > >Yes, RTFMP on tag and tagged. > > > While I can give you the benefit of the doubt that in some way you are trying to help I would prefer it if you just didn't respond to me. Your your comments are really abrasive,over the top and lacking of useful nature. This is a mailing list on PF for help and information exchange not a place to say RTFMP, and there is no argument that man pages are really just aimed for reference use for these who already familiar with what they need to do. Mike From owner-freebsd-pf@FreeBSD.ORG Wed Jul 12 13:13:38 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ED8D16A4DE for ; Wed, 12 Jul 2006 13:13:38 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06F5C43D4C for ; Wed, 12 Jul 2006 13:13:37 +0000 (GMT) (envelope-from Greg.Hennessy@nviz.net) Received: from gw2.local.net (unknown [62.3.210.251]) by smtp.nildram.co.uk (Postfix) with ESMTP id ABEAD236D36 for ; Wed, 12 Jul 2006 14:13:33 +0100 (BST) From: "Greg Hennessy" To: Date: Wed, 12 Jul 2006 14:13:31 +0100 Keywords: freebsd-pf Message-ID: <000001c6a5b4$f8b055c0$0a00a8c0@thebeast> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44B4C782.2@thebeastie.org> Thread-Index: AcalmhmeWbqBt81sQ8OTZrviPZh/JwADjNig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 12 Jul 2006 13:13:31.0164 (UTC) FILETIME=[F8B055C0:01C6A5B4] Subject: RE: PF firewall rules 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, 12 Jul 2006 13:13:38 -0000 > > > While I can give you the benefit of the doubt that in some > way you are trying to help I would prefer it if you just didn't respond to me. > Your your comments are really abrasive,over the top and lacking of > useful nature. I am sorry, I cannot leave this go unchallenged, one's posting record on this and other pf mailing lists & freebsdforums.org http://www.freebsdforums.org/forums/search.php?searchid=155847 speaks for itself. It's not the fault of the audience when someone refuses to take advice on board, ignores the reference material, demonstrates a lack of basic networking knowledge and then continues to slate the implementation of something they clearly do not understand. > This is a mailing list on PF for help and information exchange not a > place to say RTFMP, and there is no argument that man pages > are really just aimed for reference use for these who already familiar with what > they need to do. Oh puhleeze, reading the man page on pf is *precisely* what you need to do. The pf.conf page covers the subject matter in detail. In particular relating to the use of tagging, the pf.conf man page provides a very easily understood explanation tag Packets matching this rule will be tagged with the specified string. The tag acts as an internal marker that can be used to identify these packets later on. This can be used, for example, to provide trust between interfaces and to determine if packets have been processed by translation rules. Tags are "sticky", meaning that the packet will be tagged even if the rule is not the last matching rule. Further matching rules can replace the tag with a new one but will not remove a previously applied tag. A packet is only ever assigned one tag at a time. pass rules that use the tag keyword must also use keep state, modulate state or synproxy state. Packet tagging can be done during nat, rdr, or binat rules in addi- tion to filter rules. Tags take the same macros as labels (see above). tagged Used with filter or translation rules to specify that packets must already be tagged with the given tag in order to match the rule. Inverse tag matching can also be done by specifying the ! operator before the tagged keyword. and a sample implementation. # Packet Tagging # three interfaces: $int_if, $ext_if, and $wifi_if (wireless). NAT is # being done on $ext_if for all outgoing packets. tag packets in on # $int_if and pass those tagged packets out on $ext_if. all other # outgoing packets (i.e., packets from the wireless network) are only # permitted to access port 80. pass in on $int_if from any to any tag INTNET keep state pass in on $wifi_if from any to any keep state block out on $ext_if from any to any pass out quick on $ext_if tagged INTNET keep state pass out on $ext_if proto tcp from any to any port 80 keep state # tag incoming packets as they are redirected to spamd(8). use the tag # to pass those packets through the packet filter. rdr on $ext_if inet proto tcp from to port smtp \ tag SPAMD -> 127.0.0.1 port spamd block in on $ext_if pass in on $ext_if inet proto tcp tagged SPAMD keep state As does PF Users Guide on http://www.openbsd.org/faq/pf/tagging.html You asked specifically how to minimise the ruleset, in particular implementing effectively one filtering rule per flow. I point you at the documentation & then go onto detail not one but *two* mechanisms for doing so, and the thanks I get is to be accused of being unhelpful. Sheesh. PF != IPF. It doesn't necessarily make it any worse, it doesn't necessarily make it any better. Both have their place in the world. It's not the fault of the product when someone has obvious difficulties getting their head around simple differences in implementation detail. That's my final word on the matter. From owner-freebsd-pf@FreeBSD.ORG Wed Jul 12 18:33:52 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4F3716A53F for ; Wed, 12 Jul 2006 18:33:52 +0000 (UTC) (envelope-from solinym@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED56143D5F for ; Wed, 12 Jul 2006 18:33:51 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so364096pyc for ; Wed, 12 Jul 2006 11:33:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dkqRMyrtoXYioi2n2G8uJAfzuWaFRLYKqY688TAg+OkcFuxgN/Dz1NM0Alkc0DA/0qduCTFnyuu72VuZ4VNiwjb1JhEcSfViawCqSWVDUYADckm6pgFZD7xpcPJzd0Cn+m/NRcWDWsLp4ko4VFuutM1pAXN5qI+Kj+9/RAwzbrk= Received: by 10.35.121.9 with SMTP id y9mr1195468pym; Wed, 12 Jul 2006 11:33:51 -0700 (PDT) Received: by 10.35.34.3 with HTTP; Wed, 12 Jul 2006 11:33:51 -0700 (PDT) Message-ID: Date: Wed, 12 Jul 2006 13:33:51 -0500 From: "Travis H." To: "Adam Clark" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-pf@freebsd.org Subject: Re: ALTQ on a process on the router 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, 12 Jul 2006 18:33:52 -0000 On 7/12/06, Adam Clark wrote: > Hi, > I am trying to perform ALTQ on a process running on the router itself. > > I have bound the application to to internal IP address (10.10.10.254), > that which is bound to the internal interface. > > When I log-all packets passing out this interface, I cannot see any data > going to 10.10.10.254, just other hosts on my network. This is bound to > be how it is meant to be, but its not healping my situation. Is there > anyway to make the kernel put frames destined for itself on the > appropriate interface? No; the Unix kernel short-circuits any packets destined for any of its interfaces and puts them on the loopback interface. Perhaps you should be looking there? Why would you want to queue stuff that the router is sending to itself? It's not like you're bandwidth-limited, because it never goes over a communications link. It's CPU-limited, and it gets processed as soon as it "appears" on lo0. -- Resolve is what distinguishes a person who has failed from a failure. Unix "guru" for sale or rent - http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 From owner-freebsd-pf@FreeBSD.ORG Wed Jul 12 19:32:28 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CEBA16A4DA for ; Wed, 12 Jul 2006 19:32:28 +0000 (UTC) (envelope-from solinym@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76A6B43D49 for ; Wed, 12 Jul 2006 19:32:27 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so383972pyc for ; Wed, 12 Jul 2006 12:32:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hc7DoTJkd9TJvVDoIqJ6CmafVdrv7ltVlGduyGD/4K9DRKDb2IYYTDcEYmqkwkEXnER7kGLdsB9gAGw/VhHKwhfvDqxe/CaV1b4AMNTClq9BDItYwelcWUH2tIK7WrbI66N5ougwb/S4o+rqvdLlWSVHKAq/187EglI2X9FK6e8= Received: by 10.35.20.14 with SMTP id x14mr1311796pyi; Wed, 12 Jul 2006 12:32:26 -0700 (PDT) Received: by 10.35.34.3 with HTTP; Wed, 12 Jul 2006 12:32:26 -0700 (PDT) Message-ID: Date: Wed, 12 Jul 2006 14:32:26 -0500 From: "Travis H." To: "Greg Hennessy" In-Reply-To: <000001c6a5b4$f8b055c0$0a00a8c0@thebeast> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44B4C782.2@thebeastie.org> <000001c6a5b4$f8b055c0$0a00a8c0@thebeast> Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules 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, 12 Jul 2006 19:32:28 -0000 On 7/12/06, Greg Hennessy wrote: > It's not the fault of the audience when someone refuses to take advice on > board, ignores the reference material, demonstrates a lack of basic > networking knowledge and then continues to slate the implementation of > something they clearly do not understand. Seconded. His comparison of pf's treatment of TCP as "protocol racism" was over the top (although I found it amusing). With regard to that, TCP has some neat features that allow us to implement some small degree of security based on the flags and sequence numbers. UDP doesn't have anything of the sort at that layer. In fact, the way we do stateful filtering at the UDP level technically breaks DNS, because domain name servers aren't guaranteed to respond on the same interface/IP as the request came in, because some servers bind to the wildcard address and the socket interface doesn't tell the server what IP the data came in on. Fortunately this doesn't matter in practice. Trying to make a decent firewall which allows it to come up with established TCP connections won't work correctly 100% of the time, ever. That's why we have carp and pfsync. If you can't be bothered to type out or alias pfctl -f ruleset -F state, we aren't required to make /etc/init.d/pf resync do what you want. You have aptly demonstrated you're capable of using a shell function to do it, so feel free to add that to /root/.profile, and use it in lieu of the former. If you know the answers, I don't see the point of asking the questions. It appears you're asking them in some kind of Socratic irony sort of way, in an attempt to get the FreeBSDers to change the course of pf development, but you don't appear to understand the issues well enough to be guiding its development (and I'm not even sure FreeBSD has forked the code, or wants to diverge significantly from the OpenBSD version). For example, the "kernel" keyword you suggested is unnecessary and misleading. Every packet we deal with is being handled by the kernel. Tagging and policy-based routing can do what you want, and more. Just get over ipfilter; pf has a lot more to offer. I don't mean this to sound unnecessarily harsh; I just want you to understand how things look to us. I'm done with this thread too, barring a particularly interesting question. -- Resolve is what distinguishes a person who has failed from a failure. Unix "guru" for sale or rent - http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 From owner-freebsd-pf@FreeBSD.ORG Wed Jul 12 22:47:36 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEDD516A4DA for ; Wed, 12 Jul 2006 22:47:36 +0000 (UTC) (envelope-from adam.clark@ngv.vic.gov.au) Received: from monet2.ngv.vic.gov.au (monet2.ngv.vic.gov.au [203.18.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F6FE43D4C for ; Wed, 12 Jul 2006 22:47:35 +0000 (GMT) (envelope-from adam.clark@ngv.vic.gov.au) Received: from monet2.ngv.vic.gov.au (monet2.ngv.vic.gov.au [127.0.0.1]) by localhost.ngv.vic.gov.au (Postfix) with ESMTP id 2D8C63400E for ; Thu, 13 Jul 2006 08:47:32 +1000 (EST) Received: from ngv.vic.gov.au (titian.boh.ngv.local [172.16.22.25]) by monet2.ngv.vic.gov.au (Postfix) with ESMTP id 2390334002 for ; Thu, 13 Jul 2006 08:47:32 +1000 (EST) Received: from mail pickup service by ngv.vic.gov.au with Microsoft SMTPSVC; Thu, 13 Jul 2006 08:47:32 +1000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jul 2006 08:47:30 +1000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ALTQ on a process on the router thread-index: Acal4brPxFZ3q+LxQh6SHjoiiJWcaAAIyKtQ From: "Adam Clark" To: "Travis H." X-OriginalArrivalTime: 12 Jul 2006 22:47:32.0042 (UTC) FILETIME=[290D42A0:01C6A605] X-TM-AS-Product-Ver: SMEX-7.0.0.1345-3.52.1006-14564.000 X-TM-AS-Result: No--10.889000-5.000000-1 Cc: freebsd-pf@freebsd.org Subject: RE: ALTQ on a process on the router 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, 12 Jul 2006 22:47:37 -0000 Basically I have bittorrent running on the firewall/router. I am trying to lessen the impact on our 128/512k DSL line. Currently it hogs everything and makes web traffic annoyingly slow. I want to make bittorrent lowest priority traffic. It's a shame that you cant do inbound queuing, to implement rate limiting there. Adam=20 >=20 Adam Clark Network Administrator National Gallery of Victoria PO Box 7259 St Kilda Road Vic 8004 Telephone: +61 3 8620 2369=20 Fax: +61 3 8620 2565 www.ngv.vic.gov.au Keep informed of the latest NGV exhibitions, special events and programs = at The Ian Potter Centre: NGV Australia and NGV International by = subscribing to NGV@RT, the NGV's free e-newsletter. DISCLAIMER: This email and any files transmitted with it are = confidential and intended solely for = solinym@gmail.com,freebsd-pf@freebsd.org. If you are not the named = addressee you should not disseminate, copy or alter this email. WARNING: = Although National Gallery of Victoria has taken reasonable precautions = to ensure no viruses are present in this email, the organisation cannot = accept responsibility for any loss or damage arising from the use of = this email or attachment.-----Original Message----- > From: Travis H. [mailto:solinym@gmail.com]=20 > Sent: Thursday, 13 July 2006 4:34 AM > To: Adam Clark > Cc: freebsd-pf@freebsd.org > Subject: Re: ALTQ on a process on the router >=20 > On 7/12/06, Adam Clark wrote: > > Hi, > > I am trying to perform ALTQ on a process running on the=20 > router itself. > > > > I have bound the application to to internal IP address=20 > (10.10.10.254),=20 > > that which is bound to the internal interface. > > > > When I log-all packets passing out this interface, I cannot see any=20 > > data going to 10.10.10.254, just other hosts on my network.=20 > This is=20 > > bound to be how it is meant to be, but its not healping my=20 > situation.=20 > > Is there anyway to make the kernel put frames destined for=20 > itself on=20 > > the appropriate interface? >=20 > No; the Unix kernel short-circuits any packets destined for=20 > any of its interfaces and puts them on the loopback=20 > interface. Perhaps you should be looking there? >=20 > Why would you want to queue stuff that the router is sending=20 > to itself? It's not like you're bandwidth-limited, because=20 > it never goes over a communications link. It's CPU-limited,=20 > and it gets processed as soon as it "appears" on lo0. > -- > Resolve is what distinguishes a person who has failed from a failure. > Unix "guru" for sale or rent -=20 > http://www.lightconsulting.com/~travis/ -><- GPG fingerprint:=20 > 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 >=20 From owner-freebsd-pf@FreeBSD.ORG Wed Jul 12 23:19:01 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82CDC16A4DD for ; Wed, 12 Jul 2006 23:19:01 +0000 (UTC) (envelope-from solinym@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31FDC43D5C for ; Wed, 12 Jul 2006 23:18:59 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by py-out-1112.google.com with SMTP id t32so31137pyc for ; Wed, 12 Jul 2006 16:18:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dS82LmCwC1M5aJBFuBlLNCH4zMDKozHDrA/Q2+cwBuf7JZhWjdnekn7W5osdoQvoiEcEn6qfNZkTVs2pMJk6he7Vwfr1v1xGaqT6rOrCj8wH8WeeWD1y4MPAwCf+wbbDnLjJhy4TrakczUSdltQohcAatReAYye2q7LBz9ipqcU= Received: by 10.35.21.1 with SMTP id y1mr63252pyi; Wed, 12 Jul 2006 16:18:58 -0700 (PDT) Received: by 10.35.34.3 with HTTP; Wed, 12 Jul 2006 16:18:58 -0700 (PDT) Message-ID: Date: Wed, 12 Jul 2006 18:18:58 -0500 From: "Travis H." To: "Adam Clark" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-pf@freebsd.org Subject: Re: ALTQ on a process on the router 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, 12 Jul 2006 23:19:01 -0000 On 7/12/06, Adam Clark wrote: > I want to make bittorrent lowest priority traffic. > > It's a shame that you cant do inbound queuing, to implement rate > limiting there. Deja vu. While I didn't think about TCP window size modulation, the canonical answer to this is that there are no queues on inbound packets because the processor processes them immediately. Certainly with UDP traffic, which bittorrent now uses, there's virtually no point. Dropping the inbound packets will not help keep your WAN link from saturating, because they've already passed through it, and apart maybe from ICMP source quench, there's no mechanism for rate limiting the remote peers. -- Resolve is what distinguishes a person who has failed from a failure. Unix "guru" for sale or rent - http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 08:48:08 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BC9616A4DD for ; Fri, 14 Jul 2006 08:48:08 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from illusion.skoberne.net (illusion.skoberne.net [84.255.205.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 780C943D45 for ; Fri, 14 Jul 2006 08:48:07 +0000 (GMT) (envelope-from nejc@skoberne.net) Received: from localhost (localhost [127.0.0.1]) by illusion.skoberne.net (Postfix) with ESMTP id C5735B879 for ; Fri, 14 Jul 2006 10:48:06 +0200 (CEST) Received: from illusion.skoberne.net ([127.0.0.1]) by localhost (Illusion.skoberne.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59624-04 for ; Fri, 14 Jul 2006 10:48:06 +0200 (CEST) Received: from [192.168.1.202] (stinker.skoberne.net [84.255.205.234]) by illusion.skoberne.net (Postfix) with ESMTP id 4B58FB870 for ; Fri, 14 Jul 2006 10:48:06 +0200 (CEST) Message-ID: <44B75A3D.5060108@skoberne.net> Date: Fri, 14 Jul 2006 10:47:57 +0200 From: Nejc Skoberne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: multipart/mixed; boundary="------------050303090108010304000102" X-Virus-Scanned: amavisd-new at skoberne.net X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Multihoming with route-to 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, 14 Jul 2006 08:48:08 -0000 This is a multi-part message in MIME format. --------------050303090108010304000102 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Hello, I have a FreeBSD 5.3 server with 2 Internet connections: - ADSL, ($UntrustInterface): A.B.C.D, $NextHop1: a.b.c.d - VDSL, ($UntrustInterface2): E.F.G.H, $NextHop2: e.f.g.h I would like to be able to access server's services via both connections independently. ADSL connection is more like a "primary" connection, so its $NextHop1 (a.b.c.d) is also set as default route. Obviously, when I try to ping the E.F.G.H from the internet, the answer gets routed via a.b.c.d which is not what I want. So I need pf's route-to. I have this in my pf.conf: pass out on $UntrustInterface proto tcp all flags S/SA modulate state pass out on $UntrustInterface proto { udp, icmp } all keep state pass out on $UntrustInterface2 proto tcp all flags S/SA modulate state pass out on $UntrustInterface2 proto { udp, icmp } all pass out on $UntrustInterface route-to ($UntrustInterface2 $NextHop2) from $UntrustInterface2 to any keep state pass out on $UntrustInterface2 route-to ($UntrustInterface $NextHop1) from $UntrustInterface to any keep state I thought this would do the following: if I ping E.F.G.H from w.x.y.z (somewhere on the Internet), the packet goes in through $UntrustInterface2, kernel crafts the ping-reply packet and sends it out to default route via the $UntrustInterface - but since there is a route-to rule, the packet should get routed to $UntrustInterface2 and $NextHop2 instead. Is this reasoning correct? However, this does not work for me. If I ping the E.F.G.H and watch the traffic on both interfaces with tcpdump, the packet is sent to $NextHop1 via the $UntrustInterface, so it looks like the route-to rule is just ignored. How could I debug this situation properly? You can find the full pf.conf here: http://nejc.skoberne.net/pf.conf Thanks for your help. Best regards, Nejc Skoberne --------------050303090108010304000102-- From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 10:26:49 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF32916A4DD for ; Fri, 14 Jul 2006 10:26:49 +0000 (UTC) (envelope-from ari@suutari.iki.fi) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 214D043D49 for ; Fri, 14 Jul 2006 10:26:45 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57]) by espresso2.syncrontech.com (8.13.1/8.13.1) with ESMTP id k6EAQhS0031050 for ; Fri, 14 Jul 2006 13:26:44 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Received: from [127.0.0.1] (coffee.syncrontech.com [192.168.5.102]) by guinness.syncrontech.com (8.13.4/8.13.4) with ESMTP id k6EAQgii094566 for ; Fri, 14 Jul 2006 13:26:43 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <44B7715E.8050906@suutari.iki.fi> Date: Fri, 14 Jul 2006 13:26:38 +0300 From: Ari Suutari User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? 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, 14 Jul 2006 10:26:50 -0000 Hi, Does anyone know if there are any plans to bring pf boot-time protection (ie. /etc/rc.d/pf_boot and related config files) from NetBSD to FreeBSD ? This would close small (but as far as I understand existing) window during boot where firewall is fully open (if using only pf). Ari S. From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 11:13:08 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4F8B16A4DD for ; Fri, 14 Jul 2006 11:13:08 +0000 (UTC) (envelope-from vladgalu@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id F25C443D46 for ; Fri, 14 Jul 2006 11:13:07 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by nf-out-0910.google.com with SMTP id n28so87635nfc for ; Fri, 14 Jul 2006 04:13:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fkSmJJPM+kde1Y8XeNSPXAYrSukwfktv8iL4FNAlD1IibkeV6MukeOQp5vRlnW+xzuccYqK1kO0POAJ5ZVnjBkG3VRIkMSm30bIzJxlEouBBsL5tNfEIFypccB7M7RXIUhPt8IByGdzagHhBTkM1gFgwNJGVm3jupwFKQQXy/ME= Received: by 10.49.41.18 with SMTP id t18mr1822227nfj; Fri, 14 Jul 2006 04:13:06 -0700 (PDT) Received: by 10.48.239.9 with HTTP; Fri, 14 Jul 2006 04:13:06 -0700 (PDT) Message-ID: <79722fad0607140413i10a2f5d9pfa0cc4b757e928a8@mail.gmail.com> Date: Fri, 14 Jul 2006 14:13:06 +0300 From: "Vlad GALU" To: freebsd-pf@freebsd.org In-Reply-To: <44B7715E.8050906@suutari.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44B7715E.8050906@suutari.iki.fi> Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? 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, 14 Jul 2006 11:13:08 -0000 On 7/14/06, Ari Suutari wrote: > Hi, > > Does anyone know if there are any plans to bring > pf boot-time protection (ie. /etc/rc.d/pf_boot and > related config files) from NetBSD to FreeBSD ? > > This would close small (but as far as I understand existing) > window during boot where firewall is fully open (if using only > pf). > See the mac_ifoff(4) manpage. You can disable your interfaces until the system is fully booted. > Ari S. > > _______________________________________________ > 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" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 11:49:22 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3193716A4DA for ; Fri, 14 Jul 2006 11:49:22 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6C0643D46 for ; Fri, 14 Jul 2006 11:49:21 +0000 (GMT) (envelope-from Greg.Hennessy@nviz.net) Received: from gw2.local.net (unknown [62.3.210.251]) by smtp.nildram.co.uk (Postfix) with ESMTP id 2C709236F6B for ; Fri, 14 Jul 2006 12:49:18 +0100 (BST) From: "Greg Hennessy" To: "'Vlad GALU'" , Date: Fri, 14 Jul 2006 12:49:18 +0100 Keywords: freebsd-pf Message-ID: <000001c6a73b$89baaf20$0a00a8c0@thebeast> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <79722fad0607140413i10a2f5d9pfa0cc4b757e928a8@mail.gmail.com> Thread-Index: AcanOPsifa3B36oASoawFMQrWJ2tigAAmzqQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 14 Jul 2006 11:49:18.0226 (UTC) FILETIME=[89BAAF20:01C6A73B] Cc: Subject: RE: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? 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, 14 Jul 2006 11:49:22 -0000 >> > See the mac_ifoff(4) manpage. You can disable your interfaces until > the system is fully booted. > Crikey! Everyday a school day :-). Most useful. Greg From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 11:50:58 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EC1B16A4DA for ; Fri, 14 Jul 2006 11:50:58 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07EE343D49 for ; Fri, 14 Jul 2006 11:50:57 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 9FC1C2D4921; Fri, 14 Jul 2006 11:50:56 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 85F9911444; Fri, 14 Jul 2006 13:50:56 +0200 (CEST) Date: Fri, 14 Jul 2006 13:50:56 +0200 From: "Simon L. Nielsen" To: Ari Suutari Message-ID: <20060714115055.GD1111@zaphod.nitro.dk> References: <44B7715E.8050906@suutari.iki.fi> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yLVHuoLXiP9kZBkt" Content-Disposition: inline In-Reply-To: <44B7715E.8050906@suutari.iki.fi> User-Agent: Mutt/1.5.11 Cc: freebsd-pf@freebsd.org Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? 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, 14 Jul 2006 11:50:58 -0000 --yLVHuoLXiP9kZBkt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2006.07.14 13:26:38 +0300, Ari Suutari wrote: > Does anyone know if there are any plans to bring > pf boot-time protection (ie. /etc/rc.d/pf_boot and > related config files) from NetBSD to FreeBSD ? >=20 > This would close small (but as far as I understand existing) > window during boot where firewall is fully open (if using only > pf). I would really like to see this problem fixed. I have looked at it before, just not gotten around to doing something about it. Without having looked more closely at this pf_boot support from NetBSD it seems like a fine way to deal with the problem. mac_ifoff(4) might be a way to solve this problem, but it seems a bit overkill to require MAC to handle this. --=20 Simon L. Nielsen --yLVHuoLXiP9kZBkt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEt4Ufh9pcDSc1mlERAuOCAKCddVph3UBBpuzvrXvXc9CvZGPsTgCeK2S2 Vb5QlL9t26ZI3LH3Ktn8Ceo= =RbUi -----END PGP SIGNATURE----- --yLVHuoLXiP9kZBkt-- From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 15:44:36 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14FF316A4E1 for ; Fri, 14 Jul 2006 15:44:36 +0000 (UTC) (envelope-from ari@suutari.iki.fi) Received: from pne-smtpout4-sn2.hy.skanova.net (pne-smtpout4-sn2.hy.skanova.net [81.228.8.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id A33A543D72 for ; Fri, 14 Jul 2006 15:44:31 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from mato.suutari.iki.fi (80.222.160.17) by pne-smtpout4-sn2.hy.skanova.net (7.2.075) id 44A2EAB80007B655; Fri, 14 Jul 2006 17:44:30 +0200 Received: from [127.0.0.1] (raisa.suutari.iki.fi [192.168.60.100]) by mato.suutari.iki.fi (8.13.6/8.13.6) with ESMTP id k6EFiSiQ047304; Fri, 14 Jul 2006 18:44:28 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <44B7BBDD.8080302@suutari.iki.fi> Date: Fri, 14 Jul 2006 18:44:29 +0300 From: Ari Suutari User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Vlad GALU References: <44B7715E.8050906@suutari.iki.fi> <79722fad0607140413i10a2f5d9pfa0cc4b757e928a8@mail.gmail.com> In-Reply-To: <79722fad0607140413i10a2f5d9pfa0cc4b757e928a8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0628-5, 14.07.2006), Outbound message X-Antivirus-Status: Clean Cc: freebsd-pf@freebsd.org Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? 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, 14 Jul 2006 15:44:36 -0000 Hi, Vlad GALU wrote: > On 7/14/06, Ari Suutari wrote: >> Hi, >> >> Does anyone know if there are any plans to bring >> pf boot-time protection (ie. /etc/rc.d/pf_boot and >> related config files) from NetBSD to FreeBSD ? >> >> This would close small (but as far as I understand existing) >> window during boot where firewall is fully open (if using only >> pf). >> > > See the mac_ifoff(4) manpage. You can disable your interfaces until > the system is fully booted. How well would this work ? I think that idea of pf_boot is to disable incoming traffic, but allow certain outgoing traffic like dns. If dns doesn't work during startup (don't really know about mac_ifoff yet) it will cause problems, for example sendmail startup might hang for a while. Ari S. From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 15:57:45 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74E6516A619 for ; Fri, 14 Jul 2006 15:57:44 +0000 (UTC) (envelope-from vladgalu@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAC0643D6A for ; Fri, 14 Jul 2006 15:57:39 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by nf-out-0910.google.com with SMTP id n28so168416nfc for ; Fri, 14 Jul 2006 08:57:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FswcJJ3G1yIHlDXTa6Wlr2yKJwxVRnMVab62KKDx/svpIiU5E4JSAkMUMYvkcYdEgX5eE/HPVD29UvFtdqtdGTNdgaVrOu9czrtBDSf1Za0YyjaVerkZiz2YkseEnRlV7sHLbZkTI6unY9pPSPkS+MsY4U+Qx17JzdR5ZgN3Fwg= Received: by 10.49.19.18 with SMTP id w18mr2102841nfi; Fri, 14 Jul 2006 08:57:38 -0700 (PDT) Received: by 10.48.239.9 with HTTP; Fri, 14 Jul 2006 08:57:38 -0700 (PDT) Message-ID: <79722fad0607140857j154002e8r8bc24e24f0867c69@mail.gmail.com> Date: Fri, 14 Jul 2006 18:57:38 +0300 From: "Vlad GALU" To: freebsd-pf@freebsd.org In-Reply-To: <44B7BBDD.8080302@suutari.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44B7715E.8050906@suutari.iki.fi> <79722fad0607140413i10a2f5d9pfa0cc4b757e928a8@mail.gmail.com> <44B7BBDD.8080302@suutari.iki.fi> Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? 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, 14 Jul 2006 15:57:45 -0000 On 7/14/06, Ari Suutari wrote: > Hi, > > Vlad GALU wrote: > > On 7/14/06, Ari Suutari wrote: > >> Hi, > >> > >> Does anyone know if there are any plans to bring > >> pf boot-time protection (ie. /etc/rc.d/pf_boot and > >> related config files) from NetBSD to FreeBSD ? > >> > >> This would close small (but as far as I understand existing) > >> window during boot where firewall is fully open (if using only > >> pf). > >> > > > > See the mac_ifoff(4) manpage. You can disable your interfaces until > > the system is fully booted. > > How well would this work ? I think that idea of pf_boot > is to disable incoming traffic, but allow certain outgoing > traffic like dns. If dns doesn't work during startup (don't > really know about mac_ifoff yet) it will cause problems, for > example sendmail startup might hang for a while. It would disable all traffic until the system is up. That includes outgoing traffic. Basically the problem is that pf, unlike ipf/ipfw, doesn't have a "block everything by default" option, so the firewall is open until the ruleset has been loaded. That can be solved by either adding such an option or by having a "block all" rule inserted early in the booting process, which would be removed upon loading the rules from pf.conf. I think (I didn't check) that this is exactly what the NetBSD script Simon was telling us about does. > > Ari S. > > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 16:49:49 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 723B716A4E0 for ; Fri, 14 Jul 2006 16:49:49 +0000 (UTC) (envelope-from fb-pf@psconsult.nl) Received: from ps226.psconsult.nl (ps226.psconsult.nl [213.222.19.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F7B843D58 for ; Fri, 14 Jul 2006 16:49:47 +0000 (GMT) (envelope-from fb-pf@psconsult.nl) Received: from phuket.psconsult.nl (localhost [127.0.0.1]) by phuket.psconsult.nl (8.13.1/8.13.1) with ESMTP id k6EFlTMF008746 for ; Fri, 14 Jul 2006 17:47:29 +0200 (CEST) (envelope-from fb-pf@psconsult.nl) Received: (from paul@localhost) by phuket.psconsult.nl (8.13.1/8.13.1/Submit) id k6EFlTdI008745 for freebsd-pf@freebsd.org; Fri, 14 Jul 2006 17:47:29 +0200 (CEST) (envelope-from fb-pf@psconsult.nl) Date: Fri, 14 Jul 2006 17:47:29 +0200 From: Paul Schenkeveld To: freebsd-pf@freebsd.org Message-ID: <20060714154729.GA8616@psconsult.nl> Mail-Followup-To: freebsd-pf@freebsd.org References: <44B7715E.8050906@suutari.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B7715E.8050906@suutari.iki.fi> User-Agent: Mutt/1.5.6i Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? 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, 14 Jul 2006 16:49:49 -0000 Hello, On Fri, Jul 14, 2006 at 01:26:38PM +0300, Ari Suutari wrote: > Hi, > > Does anyone know if there are any plans to bring > pf boot-time protection (ie. /etc/rc.d/pf_boot and > related config files) from NetBSD to FreeBSD ? > > This would close small (but as far as I understand existing) > window during boot where firewall is fully open (if using only > pf). I'd prefer to have PF_DEFAULT_BLOCK analogous to IPFILTER_DEFAULT_BLOCK instead of some magic script closing the hole between driver init and configuration. Always wondered how the OpenBSD -securety minded- people have come up with a packet filter that's open by default. Or am I missing the point here? Regards, Paul Schenkeveld From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 17:11:23 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6A2D16A4DA for ; Fri, 14 Jul 2006 17:11:22 +0000 (UTC) (envelope-from phoemix@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id B890D43D53 for ; Fri, 14 Jul 2006 17:11:21 +0000 (GMT) (envelope-from phoemix@harmless.hu) Received: from localhost (localhost [127.0.0.1]) by marvin (Postfix) with ESMTP id 7BD9820001CB for ; Fri, 14 Jul 2006 19:11:20 +0200 (CEST) Received: from marvin.harmless.hu ([127.0.0.1]) by localhost (marvin [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17592-05 for ; Fri, 14 Jul 2006 19:11:18 +0200 (CEST) Received: by marvin (Postfix, from userid 1000) id D64F620001C9; Fri, 14 Jul 2006 19:11:18 +0200 (CEST) Date: Fri, 14 Jul 2006 19:11:18 +0200 To: freebsd-pf@freebsd.org Message-ID: <20060714171118.GA27379@marvin.harmless.hu> References: <44B7715E.8050906@suutari.iki.fi> <20060714154729.GA8616@psconsult.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <20060714154729.GA8616@psconsult.nl> User-Agent: Mutt/1.5.9i From: phoemix@harmless.hu (Gergely CZUCZY) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at harmless.hu Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? 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, 14 Jul 2006 17:11:23 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 14, 2006 at 05:47:29PM +0200, Paul Schenkeveld wrote: > Hello, >=20 > On Fri, Jul 14, 2006 at 01:26:38PM +0300, Ari Suutari wrote: > > Hi, > >=20 > > Does anyone know if there are any plans to bring > > pf boot-time protection (ie. /etc/rc.d/pf_boot and > > related config files) from NetBSD to FreeBSD ? > >=20 > > This would close small (but as far as I understand existing) > > window during boot where firewall is fully open (if using only > > pf). >=20 > I'd prefer to have PF_DEFAULT_BLOCK analogous to IPFILTER_DEFAULT_BLOCK > instead of some magic script closing the hole between driver init and > configuration. Always wondered how the OpenBSD -securety minded- people > have come up with a packet filter that's open by default. >=20 > Or am I missing the point here? On a linux box i'm running i have a 2-state firewall setup, that is i like it very much. the states looks like this: 1, bootup) this state only allows DNS and ssh communications, and as soon as possible at the bootup up process, the box will apply this ruleset. All the communications are disabled except the above mentioned ones. Even the running services are unreachable in this stage 2, online) The box goes to this state when all the services are running and the bootup process has been completed. in this stage every service can be accessed. Using this two state the services can be protected from the clients while not all of them are started. there are various reasons for this, i mention some: - Services may depend each other, and the startup order may not reflect this - Services that consists of multiple parts cannot be accessed while not all parts are up and running, this clients are unable to connect to the not-yet-fully-started services - the load at the startup can be pretty high, and the connection clients would raise this to even higher. this also can be prevented. - however, all basic (DNS resolving, and ssh for the admin) communication is allowed at the bootup stage I think netbsd also had achived a similar propose, also took some of these ideas, reasons. It would be very nice to have a pf_bootup.conf, which would= be applied as soon as the interfaces are up, but before anything else is start= ed. Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu PGP: http://phoemix.harmless.hu/phoemix.pgp Weenies test. Geniuses solve problems that arise. --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEt9A2bBsEN0U7BV0RAgRzAJ9LbyUA7YqTVeBvQYuLMZjIi8eReQCgyIzY URiMLrpZSjG3521r2/+afO0= =cfNG -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 17:47:39 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4A1916A4DE; Fri, 14 Jul 2006 17:47:39 +0000 (UTC) (envelope-from ari@suutari.iki.fi) Received: from pne-smtpout3-sn1.fre.skanova.net (pne-smtpout3-sn1.fre.skanova.net [81.228.11.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 216FF43D70; Fri, 14 Jul 2006 17:47:38 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from mato.suutari.iki.fi (80.222.160.17) by pne-smtpout3-sn1.fre.skanova.net (7.2.075) id 44A130990008CC95; Fri, 14 Jul 2006 19:47:37 +0200 Received: from [127.0.0.1] (raisa.suutari.iki.fi [192.168.60.100]) by mato.suutari.iki.fi (8.13.6/8.13.6) with ESMTP id k6EHlYp7047998; Fri, 14 Jul 2006 20:47:34 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <44B7D8B8.3090403@suutari.iki.fi> Date: Fri, 14 Jul 2006 20:47:36 +0300 From: Ari Suutari User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-pf@freebsd.org, freebsd-security@freebsd.org References: <44B7715E.8050906@suutari.iki.fi> <20060714154729.GA8616@psconsult.nl> In-Reply-To: <20060714154729.GA8616@psconsult.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0628-5, 14.07.2006), Outbound message X-Antivirus-Status: Clean Cc: Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? 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, 14 Jul 2006 17:47:39 -0000 Hi, [I have added freebsd-security to recipient list as I consider this issue a security risk] Paul Schenkeveld wrote: > Hello, > > On Fri, Jul 14, 2006 at 01:26:38PM +0300, Ari Suutari wrote: >> Hi, >> >> Does anyone know if there are any plans to bring >> pf boot-time protection (ie. /etc/rc.d/pf_boot and >> related config files) from NetBSD to FreeBSD ? >> >> This would close small (but as far as I understand existing) >> window during boot where firewall is fully open (if using only >> pf). > > I'd prefer to have PF_DEFAULT_BLOCK analogous to IPFILTER_DEFAULT_BLOCK > instead of some magic script closing the hole between driver init and > configuration. Always wondered how the OpenBSD -securety minded- people > have come up with a packet filter that's open by default. There has been discussion about this before. I know that perfect solution would be PF_DEFAULT_BLOCK, but while waiting for that I wonder why we cannot have pf_boot, which closes the boot hole (at least when run with proper filter rules). I would suggest: - first port pf_boot which brings us to same level of security as OpenBSD & NetBSD. - then, work with PF authors to get PF_DEFAULT_BLOCK if it still seems necessary. As pf becomes more and more popular on FreeBSD I see current state of system as security risk (ie. I won't use pf + FreeBSD on company firewalls although I would otherwise like to). Ari S. From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 23:09:20 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B56E16A4E0 for ; Fri, 14 Jul 2006 23:09:20 +0000 (UTC) (envelope-from jsimola@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E40143D46 for ; Fri, 14 Jul 2006 23:09:19 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so39192ugf for ; Fri, 14 Jul 2006 16:09:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MxCrfaTYR9iYh/H/Rgp3TRy/Mg3DlRToBdconRtCELvs4UaI6YrUglI5sH10h830k+C1zuS7lrOHIkL8KDuyXg3xa2orLqQ/6e4cb+eHnqZTgXw8Eq1bqzOrz0osxavDsPk+PJ+WPDPU+v2PW6+7I3bMiYsMZwzi8QKZ9//cJqs= Received: by 10.78.136.7 with SMTP id j7mr17153hud; Fri, 14 Jul 2006 16:09:18 -0700 (PDT) Received: by 10.78.196.19 with HTTP; Fri, 14 Jul 2006 16:09:17 -0700 (PDT) Message-ID: <8eea04080607141609n1270f57dva21efcd2d8eb5789@mail.gmail.com> Date: Fri, 14 Jul 2006 16:09:18 -0700 From: "Jon Simola" To: "Nejc Skoberne" In-Reply-To: <44B75A3D.5060108@skoberne.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44B75A3D.5060108@skoberne.net> Cc: freebsd-pf@freebsd.org Subject: Re: Multihoming with route-to 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, 14 Jul 2006 23:09:20 -0000 On 7/14/06, Nejc Skoberne wrote: > pass out on $UntrustInterface route-to ($UntrustInterface2 $NextHop2) from > $UntrustInterface2 to any keep state > pass out on $UntrustInterface2 route-to ($UntrustInterface $NextHop1) from > $UntrustInterface to any keep state > > I thought this would do the following: if I ping E.F.G.H from w.x.y.z (somewhere on the > Internet), the packet goes in through $UntrustInterface2, kernel crafts the ping-reply > packet and sends it out to default route via the $UntrustInterface - but since there is > a route-to rule, the packet should get routed to $UntrustInterface2 and $NextHop2 > instead. Is this reasoning correct? You need to use reply-to when a packet comes in on the second interface: pass in on $UntrustInterface2 reply-to ($UntrustInterface2 $NextHop2) keep state That should get you working, then apply filtering as desired. > You can find the full pf.conf here: http://nejc.skoberne.net/pf.conf Thanks for linking your full pf.conf, as it makes answering questions a lot easier. -- Jon From owner-freebsd-pf@FreeBSD.ORG Fri Jul 14 23:31:40 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 712B416A4DA for ; Fri, 14 Jul 2006 23:31:40 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from illusion.skoberne.net (illusion.skoberne.net [84.255.205.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5CC043D45 for ; Fri, 14 Jul 2006 23:31:39 +0000 (GMT) (envelope-from nejc@skoberne.net) Received: from localhost (localhost [127.0.0.1]) by illusion.skoberne.net (Postfix) with ESMTP id D0700B84D; Sat, 15 Jul 2006 01:31:40 +0200 (CEST) Received: from illusion.skoberne.net ([127.0.0.1]) by localhost (Illusion.skoberne.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70460-10; Sat, 15 Jul 2006 01:31:40 +0200 (CEST) Received: from [192.168.10.4] (unknown [192.168.10.4]) by illusion.skoberne.net (Postfix) with ESMTP id 24E50B82A; Sat, 15 Jul 2006 01:31:40 +0200 (CEST) Message-ID: <44B82950.8050905@skoberne.net> Date: Sat, 15 Jul 2006 01:31:28 +0200 From: Nejc Skoberne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jon Simola References: <44B75A3D.5060108@skoberne.net> <8eea04080607141609n1270f57dva21efcd2d8eb5789@mail.gmail.com> In-Reply-To: <8eea04080607141609n1270f57dva21efcd2d8eb5789@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------060002080603030606090600" X-Virus-Scanned: amavisd-new at skoberne.net X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: Multihoming with route-to 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, 14 Jul 2006 23:31:40 -0000 This is a multi-part message in MIME format. --------------060002080603030606090600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, > You need to use reply-to when a packet comes in on the second interface: > pass in on $UntrustInterface2 reply-to ($UntrustInterface2 $NextHop2) > keep state > > That should get you working, then apply filtering as desired. Thanks, it started to work as soon as I've added that line into pf.conf! Best regards. Nejc --------------060002080603030606090600-- From owner-freebsd-pf@FreeBSD.ORG Sat Jul 15 14:14:09 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8ACF16A4DA for ; Sat, 15 Jul 2006 14:14:09 +0000 (UTC) (envelope-from christian@de.clara.net) Received: from spamvir04.de.clara.net (spamvir04.de.clara.net [212.82.240.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A27843D49 for ; Sat, 15 Jul 2006 14:14:08 +0000 (GMT) (envelope-from christian@de.clara.net) Received: from localhost ([127.0.0.1]) by spamvir04.de.clara.net with esmtp (Exim 4.62) (envelope-from ) id 1G1kuF-0007w9-JY for freebsd-pf@freebsd.org; Sat, 15 Jul 2006 16:14:07 +0200 Received: from [192.168.0.221] (helo=[62.24.31.231]) by spamvir04.de.clara.net with esmtp (Exim 4.62) (envelope-from ) id 1G1kuF-0007w3-5a for freebsd-pf@freebsd.org; Sat, 15 Jul 2006 16:14:07 +0200 Message-ID: <44B8F827.5000602@de.clara.net> Date: Sat, 15 Jul 2006 16:13:59 +0200 From: Christian Meutes User-Agent: Mozilla Thunderbird 1.0.8 (Windows/20060417) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: RDR for locally generated traffic 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, 15 Jul 2006 14:14:10 -0000 Hello list, iam trying to redirect traffic which is locally generated on a server to a different IP address. PF is running on the server and there is no way to change this. So for example if the server wants to deliver a mail via SMTP to 1.1.1.1 then PF should rewrite 1.1.1.1 to 2.2.2.2, keep-state for this and when the traffic arrives back from 2.2.2.2 PF should memorized this for changing the Source-IP back to 1.1.1.1 This sounds like a default port-forwarding setup which is done everywhere even on the smallest soho solutions outside in the customer world. But the difference is, that the traffic is a) locally generated and b) that in conventionelly setups the traffic is always arriving on a "outside" interface where the IP address is directly assigned which isnt the case in this setup. I have used a simple RDR rule for accomplishing this: "rdr pass on fxp0 proto tcp from $server_ip to 1.1.1.1 port 25 -> 2.2.2.2 ... but without any success. When tcpdumping on fxp0 to check what is happening, I recognized that the packets are pushed untouched outside of fxp0 with the original IP address (1.1.1.1), so no rewriting was happening. I thought that this would be a simple DNAT scenario, but the more iam trying to get this working the more iam believing that it isnt even possible. Does anyone have an idea what iam doing wrong or can just confirm that its not possible to rewrite such packets and maybe can point me to a other software solution (serverbased). Thanks for your ear! cheers, Christian From owner-freebsd-pf@FreeBSD.ORG Sat Jul 15 14:22:03 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9BF416A4DA for ; Sat, 15 Jul 2006 14:22:03 +0000 (UTC) (envelope-from solinym@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1390343D4C for ; Sat, 15 Jul 2006 14:22:02 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so981950pyc for ; Sat, 15 Jul 2006 07:22:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oAEbuLDiJE/ND/Rcn4qQc6xa1NNk8ALKLSOfqLhU309VQvyoGpwYGk17GxIS/aWv9lwvlpuCOH/QdhQFGoCjqvCGl7MTOjP0qzFAcyBdLnjOejVSJa0gcAurlBBZdJeY+UBbWWWojASFBMm+FkgeQLqAzaazXC1uAo+yVSLQFzs= Received: by 10.35.88.17 with SMTP id q17mr1004052pyl; Sat, 15 Jul 2006 07:22:02 -0700 (PDT) Received: by 10.35.34.3 with HTTP; Sat, 15 Jul 2006 07:22:02 -0700 (PDT) Message-ID: Date: Sat, 15 Jul 2006 09:22:02 -0500 From: "Travis H." To: freebsd-pf@freebsd.org In-Reply-To: <20060714154729.GA8616@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44B7715E.8050906@suutari.iki.fi> <20060714154729.GA8616@psconsult.nl> Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? 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, 15 Jul 2006 14:22:03 -0000 On 7/14/06, Paul Schenkeveld wrote: > I'd prefer to have PF_DEFAULT_BLOCK analogous to IPFILTER_DEFAULT_BLOCK > instead of some magic script closing the hole between driver init and > configuration. Always wondered how the OpenBSD -securety minded- people > have come up with a packet filter that's open by default. In /etc/rc OpenBSD sets up pfctl before it runs /etc/netstart. The default ruleset is: block all pass on lo0 pass in proto tcp from any to any port 22 keep state pass out proto { tcp, udp } from any to any port 53 keep state pass out inet proto icmp all icmp-type echoreq keep state Then there's some stuff about IPv6 and some stuff for NFS. I'm not sure why they don't use "set skip" or "quick". Still, it'd be nice to have a "default deny" compile option. The question is, where do you check for this thing to be enabled? I suppose you could have both a default-deny compile option and a "block all" at the top of the ruleset (or equivalently a "block quick all" at the end), like wearing a belt and suspenders... wouldn't want installing a new kernel to suddenly open you up, nor would you want to have to remember the default deny rule when playing with different rulesets... -- ``I am not a pessimist. To perceive evil where it exists is, in my opinion, a form of optimism.'' -- Roberto Rossellini http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 From owner-freebsd-pf@FreeBSD.ORG Sat Jul 15 14:42:37 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A11116A4DF for ; Sat, 15 Jul 2006 14:42:37 +0000 (UTC) (envelope-from solinym@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CEE743D45 for ; Sat, 15 Jul 2006 14:42:36 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so987052pyc for ; Sat, 15 Jul 2006 07:42:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DoZN+bmnQ/spnlIFExLX/O0zTu73g/3qSkoCx4n35+IiAGGz9Yme+r1RqtzmerxaY5EZOJJpBrZEHoXCQafQo1tTVDA2vgC35PCJAogTTl7+7OMdeSgEie+4RvADrt+eN/nw0y5M8UCHrG9Yy4Fgpuc0aOlAc1Wjk6beDFBMEMk= Received: by 10.35.93.15 with SMTP id v15mr1031300pyl; Sat, 15 Jul 2006 07:42:36 -0700 (PDT) Received: by 10.35.34.3 with HTTP; Sat, 15 Jul 2006 07:42:36 -0700 (PDT) Message-ID: Date: Sat, 15 Jul 2006 09:42:36 -0500 From: "Travis H." To: "Christian Meutes" In-Reply-To: <44B8F827.5000602@de.clara.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44B8F827.5000602@de.clara.net> Cc: freebsd-pf@freebsd.org Subject: Re: RDR for locally generated traffic 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, 15 Jul 2006 14:42:37 -0000 On 7/15/06, Christian Meutes wrote: > I have used a simple RDR rule for accomplishing this: > "rdr pass on fxp0 proto tcp from $server_ip to 1.1.1.1 port 25 -> 2.2.2.2 > ... but without any success. > When tcpdumping on fxp0 to check what is happening, I recognized that > the packets are > pushed untouched outside of fxp0 with the original IP address (1.1.1.1), > so no rewriting was happening. Yes, rdr actually gets performed on inbound packets only. Conversely, nat gets performed on outbound only. You cannot DNAT in outbound, nor can you SNAT on inbound. I have been asking for the symmetric cases on the OpenBSD pf list, and it's on my "to do one day" list, but I have no idea when that will become the top priority (maybe never). As I understand it, this limitation has to do with the way the TCP/IP stack works in BSD, particularly vis-a-vis routing. You will note we don't have an equivalent to the PREROUTING chain, either. What I'd like to see is a real virtual machine designed for packet filtering (similar to BPF), and we compile the rules into VM instructions, and could support multiple source languages if so desired. This would give a lot more flexibility, and could lead to substantial innovations in firewalling (for example, doing stream reassembly to support variable-length re-writes, checking layer 7 data for stateful filtering (think DHCP and DNS), and doing extremely sophisticated state management). Plus, we could leverage all the optimizations that compiler designers have learned over the last 30 years. Well, it all comes down to code time. Feel free to beat me to this one :-) -- ``I am not a pessimist. To perceive evil where it exists is, in my opinion, a form of optimism.'' -- Roberto Rossellini http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 From owner-freebsd-pf@FreeBSD.ORG Sat Jul 15 15:49:24 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 025BC16A4DD for ; Sat, 15 Jul 2006 15:49:24 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from illusion.skoberne.net (illusion.skoberne.net [84.255.205.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DB9F43D45 for ; Sat, 15 Jul 2006 15:49:23 +0000 (GMT) (envelope-from nejc@skoberne.net) Received: from localhost (localhost [127.0.0.1]) by illusion.skoberne.net (Postfix) with ESMTP id 610A4B84B; Sat, 15 Jul 2006 17:49:22 +0200 (CEST) Received: from illusion.skoberne.net ([127.0.0.1]) by localhost (Illusion.skoberne.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85067-06; Sat, 15 Jul 2006 17:49:21 +0200 (CEST) Received: from [192.168.1.64] (84-255-241-13.dsl.t-2.net [84.255.241.13]) by illusion.skoberne.net (Postfix) with ESMTP id 6B80DB848; Sat, 15 Jul 2006 17:49:21 +0200 (CEST) Message-ID: <44B90E76.2080808@skoberne.net> Date: Sat, 15 Jul 2006 17:49:10 +0200 From: Nejc Skoberne User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Odhiambo WASHINGTON References: <44B75A3D.5060108@skoberne.net> <8eea04080607141609n1270f57dva21efcd2d8eb5789@mail.gmail.com> <44B82950.8050905@skoberne.net> <20060715084102.GA63164@ns2.wananchi.com> In-Reply-To: <20060715084102.GA63164@ns2.wananchi.com> Content-Type: multipart/mixed; boundary="------------040608010606080302020005" X-Virus-Scanned: amavisd-new at skoberne.net X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: Multihoming with route-to 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, 15 Jul 2006 15:49:24 -0000 This is a multi-part message in MIME format. --------------040608010606080302020005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I changed the pf.conf a little, so it fits to my needs (I also need multihoming for a server which is reachable via forwarded port). So TCP and ICMP work correctly now. However, I still have problems with UDP services. For example, I also run a DNS server on this FreeBSD server. If I try to resolve some host using this DNS server by some third party machine like this: $ nslookup host.domain.com A.B.C.D # See the first post for topology description it works smoothly. If I try to use the server's second IP (E.F.G.H), the DNS reply gets stuck in between. After tcpdumping the connection, I realized that even the destination IP in DNS request is E.F.G.H, the source address of DNS reply is A.B.C.D! That is why route-to rule doesn't work any more. If I remember correctly, this is due to the fact, that UDP is connectionless protocol and the DNS server doesn't have to bind to a specific address and port when sending an UDP packet (DNS reply). Therefore it uses the source IP address of the interface via which it tries to send the reply (default route). How could I solve this problem? > May I please see how your final pf.conf now looks like? You can find it here: http://nejc.skoberne.net/pf.conf I incorporated the reply-to rules directly in my filtering definitions. Do not hesitate to ask for further explanation of the rules. Thanks & bye. Nejc --------------040608010606080302020005-- From owner-freebsd-pf@FreeBSD.ORG Sat Jul 15 16:02:27 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A250416A4E6 for ; Sat, 15 Jul 2006 16:02:27 +0000 (UTC) (envelope-from solinym@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A9A443D66 for ; Sat, 15 Jul 2006 16:02:24 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so1006432pyc for ; Sat, 15 Jul 2006 09:02:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WzGFkn2wD7RuLX5aXEjBODbDjl8WnLWQznZJ+cJhe/x/EyDLVMbR3JwEbXQGKwK/tF9Utk4w6Fx9xv/T5LpRFiqx/aYQRyC0kggPzipd40UXxtHbN1TYDIcpa8M2AF0SZnB1hXQqBNOokcAh9c8Z5hiPvd2W6KDU9zxWOkybWAI= Received: by 10.35.19.6 with SMTP id w6mr1130530pyi; Sat, 15 Jul 2006 09:02:23 -0700 (PDT) Received: by 10.35.34.3 with HTTP; Sat, 15 Jul 2006 09:02:23 -0700 (PDT) Message-ID: Date: Sat, 15 Jul 2006 11:02:23 -0500 From: "Travis H." To: "Nejc Skoberne" In-Reply-To: <44B90E76.2080808@skoberne.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44B75A3D.5060108@skoberne.net> <8eea04080607141609n1270f57dva21efcd2d8eb5789@mail.gmail.com> <44B82950.8050905@skoberne.net> <20060715084102.GA63164@ns2.wananchi.com> <44B90E76.2080808@skoberne.net> Cc: Odhiambo WASHINGTON , freebsd-pf@freebsd.org Subject: Re: Multihoming with route-to 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, 15 Jul 2006 16:02:27 -0000 On 7/15/06, Nejc Skoberne wrote: > request is E.F.G.H, the source address of DNS reply is A.B.C.D! That is why route-to rule doesn't > work any more. If I remember correctly, this is due to the fact, that UDP is connectionless protocol > and the DNS server doesn't have to bind to a specific address and port when sending an UDP packet > (DNS reply). Therefore it uses the source IP address of the interface via which it tries to send > the reply (default route). > > How could I solve this problem? Well, the specification says that a DNS server reply may come from a different IP than the one the request was received upon. Every DNS server I work with binds to all the specific IPs with different sockets, instead of binding to the wildcard socket. Perhaps you can upgrade, or switch servers. If you're going to have to re-write the config file anyway, you might consider djbdns. Although it cannot put a cache and a server on the same socket, it is much more secure, much easier to configure, and you can use interface aliases. The other alternative is to run two instances of your server, and have each bind to one IP address alone, if that's possible. -- ``I am not a pessimist. To perceive evil where it exists is, in my opinion, a form of optimism.'' -- Roberto Rossellini http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 From owner-freebsd-pf@FreeBSD.ORG Sat Jul 15 18:53:10 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C92C416A4E0 for ; Sat, 15 Jul 2006 18:53:10 +0000 (UTC) (envelope-from christian@de.clara.net) Received: from spamvir02.de.clara.net (spamvir02.de.clara.net [212.82.240.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E71743D45 for ; Sat, 15 Jul 2006 18:53:09 +0000 (GMT) (envelope-from christian@de.clara.net) Received: from localhost ([127.0.0.1]) by spamvir02.de.clara.net with esmtp (Exim 4.62) (envelope-from ) id 1G1pGG-00019n-Ia; Sat, 15 Jul 2006 20:53:08 +0200 Received: from [192.168.0.221] (helo=[62.24.31.231]) by spamvir02.de.clara.net with esmtp (Exim 4.62) (envelope-from ) id 1G1pGG-00019j-Ba; Sat, 15 Jul 2006 20:53:08 +0200 Message-ID: <44B9398C.2080307@de.clara.net> Date: Sat, 15 Jul 2006 20:53:00 +0200 From: Christian Meutes User-Agent: Mozilla Thunderbird 1.0.8 (Windows/20060417) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Travis H." References: <44B8F827.5000602@de.clara.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: RDR for locally generated traffic 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, 15 Jul 2006 18:53:10 -0000 > > You cannot DNAT in outbound, nor can you SNAT on inbound. I have been > asking for the symmetric cases on the OpenBSD pf list, and it's on my > "to do one day" list, but I have no idea when that will become the top > priority (maybe never). > > As I understand it, this limitation has to do with the way the TCP/IP > stack works in BSD, particularly vis-a-vis routing. You will note we > don't have an equivalent to the PREROUTING chain, either. > Thanks for the answer! Then would it be possible to bind the IP to lo0 as an alias, connect to this IP and then let the rule rewrite the destination to a other one which lies on fxp0 directly? From owner-freebsd-pf@FreeBSD.ORG Sat Jul 15 19:01:41 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A990616A4E2 for ; Sat, 15 Jul 2006 19:01:41 +0000 (UTC) (envelope-from solinym@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3680143D45 for ; Sat, 15 Jul 2006 19:01:41 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so1037556pyc for ; Sat, 15 Jul 2006 12:01:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IFQE0aCoCf8s5Egl3j9/+HMxjSn9yV5iWcSu0JR4Mf7ZZs5ojlghgQ2FE/5ZpR2PKkKb93pMXqxUzJC//fuafUCWF0bKKUlZqcL1Xho1uH/NWLxFMdIXgoGeIdbeabm6QNZCnKO7+XTilBhXwjQkjhzcwDZAaavl+nDwM8m5Ofs= Received: by 10.35.93.1 with SMTP id v1mr1343027pyl; Sat, 15 Jul 2006 12:01:40 -0700 (PDT) Received: by 10.35.34.3 with HTTP; Sat, 15 Jul 2006 12:01:40 -0700 (PDT) Message-ID: Date: Sat, 15 Jul 2006 14:01:40 -0500 From: "Travis H." To: "Christian Meutes" In-Reply-To: <44B9398C.2080307@de.clara.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44B8F827.5000602@de.clara.net> <44B9398C.2080307@de.clara.net> Cc: freebsd-pf@freebsd.org Subject: Re: RDR for locally generated traffic 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, 15 Jul 2006 19:01:41 -0000 On 7/15/06, Christian Meutes wrote: > Then would it be possible to bind the IP to lo0 as an alias, connect to > this IP > and then let the rule rewrite the destination to a other one which lies > on fxp0 > directly? Hmm, gosh, I don't really know without trying. I think so, it should be like any other incoming packet as it arrives on the lo0 interface. Try it and let us know! You could also use route-to, or a static route, rather than an if alias, to get it to go to lo0, I think. -- ``I am not a pessimist. To perceive evil where it exists is, in my opinion, a form of optimism.'' -- Roberto Rossellini http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 From owner-freebsd-pf@FreeBSD.ORG Sat Jul 15 19:58:23 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34B0516A4DF for ; Sat, 15 Jul 2006 19:58:23 +0000 (UTC) (envelope-from christian@qunec.net) Received: from spamvir03.de.clara.net (spamvir03.de.clara.net [212.82.240.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id B373E43D70 for ; Sat, 15 Jul 2006 19:58:14 +0000 (GMT) (envelope-from christian@qunec.net) Received: from localhost ([127.0.0.1]) by spamvir03.de.clara.net with esmtp (Exim 4.62) (envelope-from ) id 1G1qHF-0002vn-FO; Sat, 15 Jul 2006 21:58:13 +0200 Received: from [192.168.0.221] (helo=[62.24.31.231]) by spamvir03.de.clara.net with esmtp (Exim 4.62) (envelope-from ) id 1G1qHF-0002vh-6t; Sat, 15 Jul 2006 21:58:13 +0200 Message-ID: <44B948CD.2060003@qunec.net> Date: Sat, 15 Jul 2006 21:58:05 +0200 From: christian User-Agent: Mozilla Thunderbird 1.0.8 (Windows/20060417) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Travis H." , freebsd-pf@freebsd.org References: <44B8F827.5000602@de.clara.net> <44B9398C.2080307@de.clara.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: RDR for locally generated traffic 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, 15 Jul 2006 19:58:23 -0000 > Hmm, gosh, I don't really know without trying. I think so, it should > be like any other incoming packet as it arrives on the lo0 interface. > Try it and let us know! > > You could also use route-to, or a static route, rather than an if > alias, to get it to go to lo0, I think. So, didnt worked on lo0 (dont know why). Instead I used a secondary NIC which is not in use and assigned there the IP address, this worked of course, but isnt the nicest solution. This setup affects 10 servers, all of them will get this RDR rule and the secondary IP address. Maybe its the only way. cheers, Christian From owner-freebsd-pf@FreeBSD.ORG Sat Jul 15 22:20:11 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDEEB16A4DD for ; Sat, 15 Jul 2006 22:20:11 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E40443D45 for ; Sat, 15 Jul 2006 22:20:11 +0000 (GMT) (envelope-from Greg.Hennessy@nviz.net) Received: from gw2.local.net (unknown [62.3.210.251]) by smtp.nildram.co.uk (Postfix) with ESMTP id AF1E42381C0 for ; Sat, 15 Jul 2006 23:20:04 +0100 (BST) From: "Greg Hennessy" To: "'Travis H.'" , "'Christian Meutes'" Date: Sat, 15 Jul 2006 23:20:06 +0100 Message-ID: <000601c6a85c$d3718e50$0a00a8c0@thebeast> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaoH3gotkLEzul/S2ezMF6tn5ow6AAPTgPg In-Reply-To: X-OriginalArrivalTime: 15 Jul 2006 22:20:06.0453 (UTC) FILETIME=[D3718E50:01C6A85C] Cc: freebsd-pf@freebsd.org Subject: RE: RDR for locally generated traffic 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, 15 Jul 2006 22:20:11 -0000 > What I'd like to see is a real virtual machine designed for > packet filtering (similar to BPF), and we compile the rules > into VM instructions, You've been using that Israeli firewall product again, what was it called again, Crackpoint ? :-) Greg