From owner-freebsd-ipfw Sun Sep 29 23:39:34 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EFF237B401 for ; Sun, 29 Sep 2002 23:39:32 -0700 (PDT) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EE9943E65 for ; Sun, 29 Sep 2002 23:39:31 -0700 (PDT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.12.6/8.12.6) with ESMTP id g8U6dTOp001255; Sun, 29 Sep 2002 23:39:29 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.12.6/8.12.6/Submit) id g8U6dTFf001254; Sun, 29 Sep 2002 23:39:29 -0700 (PDT) (envelope-from david) Date: Sun, 29 Sep 2002 23:39:29 -0700 (PDT) From: David Wolfskill Message-Id: <200209300639.g8U6dTFf001254@bunrab.catwhisker.org> To: freebsd-ipfw@freebsd.org Subject: Weird problem with ipfw (possibly natd/libalias, but I doubt it) Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Appropriate redirection strongly encouraged; please keep my address on recipient headers, as I'm not currently subscribed to -ipfw@. As is my custom on alternate Sundays, I updated an internal server and our firewall to today's -STABLE. (I track -STABLE daily on my laptop, so I have some idea what I'm getting into.) For the first time since I started this schedule -- over a year ago -- I needed to fall back to -STABLE from 15 Sep. (only on the firewall, though). What happened is that a specialized application that my spouse uses -- and has been using without incident for several months -- failed its (internal) authentication when she tried to connect when the firewall was running today's -STABLE. I rebooted the firewall from the alternate boot slice (as fallback), and now it works. I have a packet capture of each of a working and failing session. Of course, some of the differences are because of different timestamps, and the protocol is proprietary (and coyright by the service she's using). I have a single static IP address (residential Pac*Bell DSL, from back when static IP addresses were what they assigned). I generally allow traffic that is initiated from within; for TCP traffic, I use the "established" flag, and for UDP traffic, I use dynamic rules. The traffic in question appears to all be TCP. I set up each of the machines in question with 3 slices: * 1 has a / and /usr * 2 has a / and /usr * 3 has /var In this case, I had been running off of slice 2, so I used newfs/dump/restore to copy ad0s2{a,e} to ad0s1{a,e} (respectively), then changed /etc/fstab on ad0s1a so that / was ad0s1a and /usr was ad0s1e. I then rebooted the box and verified that things were generally (still) working. I then mounted /usr/src and /usr/obj from my build machine and did the * make installkernel * make installworld * mergemaster * reboot (after having done the full upgrade on the build machine, followed by a "make buildkernel" for each machine's kernel). This is the process I've been using for these machines for over a year (and I've done similar things before that). No problems were encountered during the process for either machine, and all other applications of which I know worked just fine -- including Web browsing, IRC, mail (I run my own SMTP server), DNS... Note, in particular, that the ipfw rules were copied, and that no changes were made to them (or to the natd configuration, for that matter). And I thought we were in code freeze.... :-{ Suggestions for identifying the nature of the problem would be heartily welcomed, though my ability to actually test the effects of the changes will be reduced, as I'm unwilling to lose domestic tranquility by causing unnecessary disruption. Thanks, david -- David H. Wolfskill david@catwhisker.org To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Sep 30 7:55:31 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFEB437B401 for ; Mon, 30 Sep 2002 07:55:29 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59A3543E65 for ; Mon, 30 Sep 2002 07:55:27 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id g8UEtNx32022 for ; Mon, 30 Sep 2002 11:55:23 -0300 Message-ID: <3D9865DB.5040902@tcoip.com.br> Date: Mon, 30 Sep 2002 11:55:23 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020905 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfw@freebsd.org Subject: Static NAT Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I discovered a nasty problem with the way 1-1 NAT is performed with ipfw atm (ie, divert throw natd). The problem is that, because a socket is used for this nat, the firewall becomes vulnerable to DoS attacks directed to such hosts. Since static 1-1 NAT is pretty straightforward, it could be done in the kernel-side of ipfw itself, thus avoiding this problem. Anyone have thoughts on the subject? -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net The surest sign that a man is in love is when he divorces his wife. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Sep 30 22:55: 5 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58BB537B401 for ; Mon, 30 Sep 2002 22:55:04 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC4F743E6A for ; Mon, 30 Sep 2002 22:55:03 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021001055503.QGRX17535.rwcrmhc51.attbi.com@blossom.cjclark.org>; Tue, 1 Oct 2002 05:55:03 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g915t3Wn079694; Mon, 30 Sep 2002 22:55:03 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g915t2qH079693; Mon, 30 Sep 2002 22:55:02 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Mon, 30 Sep 2002 22:55:02 -0700 From: "Crist J. Clark" To: "Daniel C. Sobral" Cc: ipfw@FreeBSD.ORG Subject: Re: Static NAT Message-ID: <20021001055502.GC79303@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <3D9865DB.5040902@tcoip.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D9865DB.5040902@tcoip.com.br> User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Sep 30, 2002 at 11:55:23AM -0300, Daniel C. Sobral wrote: > I discovered a nasty problem with the way 1-1 NAT is performed with ipfw > atm (ie, divert throw natd). The problem is that, because a socket is > used for this nat, the firewall becomes vulnerable to DoS attacks > directed to such hosts. > > Since static 1-1 NAT is pretty straightforward, it could be done in the > kernel-side of ipfw itself, thus avoiding this problem. > > Anyone have thoughts on the subject? What DoS? Only one socket is ever used. Or some other DoS? If you don't want to do natd(8) and divert(4), you can do ipfw(8) 'fwd' on each machine. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Oct 1 4: 4:42 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EACF237B401; Tue, 1 Oct 2002 04:04:40 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11A1C43E4A; Tue, 1 Oct 2002 04:04:39 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id g91B4Yx32711; Tue, 1 Oct 2002 08:04:36 -0300 Message-ID: <3D998142.8070005@tcoip.com.br> Date: Tue, 01 Oct 2002 08:04:34 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020905 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Crist J. Clark" Cc: ipfw@FreeBSD.ORG Subject: Re: Static NAT References: <3D9865DB.5040902@tcoip.com.br> <20021001055502.GC79303@blossom.cjclark.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Crist J. Clark wrote: > On Mon, Sep 30, 2002 at 11:55:23AM -0300, Daniel C. Sobral wrote: > >>I discovered a nasty problem with the way 1-1 NAT is performed with ipfw >>atm (ie, divert throw natd). The problem is that, because a socket is >>used for this nat, the firewall becomes vulnerable to DoS attacks >>directed to such hosts. >> >>Since static 1-1 NAT is pretty straightforward, it could be done in the >>kernel-side of ipfw itself, thus avoiding this problem. >> >>Anyone have thoughts on the subject? > > > What DoS? Only one socket is ever used. Or some other DoS? Yes, only one socket is used, and it uses mbuf clusters. > If you don't want to do natd(8) and divert(4), you can do ipfw(8) > 'fwd' on each machine. No, fwd is not nat. I need nat. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Some marriages are made in heaven -- but so are thunder and lightning. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Oct 1 10:45:51 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E63ED37B401 for ; Tue, 1 Oct 2002 10:45:49 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BF8F43E77 for ; Tue, 1 Oct 2002 10:45:49 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021001174548.UZZQ22381.sccrmhc03.attbi.com@blossom.cjclark.org>; Tue, 1 Oct 2002 17:45:48 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g91HjlWn082075; Tue, 1 Oct 2002 10:45:47 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g91Hjk2J082074; Tue, 1 Oct 2002 10:45:46 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Tue, 1 Oct 2002 10:45:46 -0700 From: "Crist J. Clark" To: "Daniel C. Sobral" Cc: ipfw@FreeBSD.ORG Subject: Re: Static NAT Message-ID: <20021001174546.GB81932@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <3D9865DB.5040902@tcoip.com.br> <20021001055502.GC79303@blossom.cjclark.org> <3D998142.8070005@tcoip.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D998142.8070005@tcoip.com.br> User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Oct 01, 2002 at 08:04:34AM -0300, Daniel C. Sobral wrote: > Crist J. Clark wrote: > >On Mon, Sep 30, 2002 at 11:55:23AM -0300, Daniel C. Sobral wrote: > > > >>I discovered a nasty problem with the way 1-1 NAT is performed with ipfw > >>atm (ie, divert throw natd). The problem is that, because a socket is > >>used for this nat, the firewall becomes vulnerable to DoS attacks > >>directed to such hosts. > >> > >>Since static 1-1 NAT is pretty straightforward, it could be done in the > >>kernel-side of ipfw itself, thus avoiding this problem. > >> > >>Anyone have thoughts on the subject? > > > > > >What DoS? Only one socket is ever used. Or some other DoS? > > Yes, only one socket is used, and it uses mbuf clusters. Sure, but even if you do everything in the kernel, you're still using some mbufs. Could you be more specific about how one would DoS a machine running with natd(8) and divert(4) that would not affect a machine doing some type of NAT in the kernel? Just saying, "it uses mbuf clusters," isn't enough for me to understand what type of resource exhaustion you are talking about and how it can be exploited. Please draw me a picture. I'm a bit slow today. Also, remember that when you push NAT into the kernel, you now need to find some place in kernel memory to jam the NAT state table. It opens up lots of new problems too. NAT in kernel or userland has lots of pros and cons each way. > >If you don't want to do natd(8) and divert(4), you can do ipfw(8) > >'fwd' on each machine. > > No, fwd is not nat. I need nat. Nope, 'fwd' is not NAT, but you can get arbitrary packets from the network in front of machine A to a socket on machine B with two 'fwd's. Depending on your needs, that may or may not be sufficient. (One big trip-up is if machine B is not FreeBSD for example.) -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Oct 1 11:51:57 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67C5737B401 for ; Tue, 1 Oct 2002 11:51:55 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 242E643E42 for ; Tue, 1 Oct 2002 11:51:53 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id g91Iphx15663; Tue, 1 Oct 2002 15:51:43 -0300 Message-ID: <3D99EEBE.2010403@tcoip.com.br> Date: Tue, 01 Oct 2002 15:51:42 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020905 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cjclark@alum.mit.edu Cc: ipfw@FreeBSD.ORG Subject: Re: Static NAT References: <3D9865DB.5040902@tcoip.com.br> <20021001055502.GC79303@blossom.cjclark.org> <3D998142.8070005@tcoip.com.br> <20021001174546.GB81932@blossom.cjclark.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Crist J. Clark wrote: > > [diet quote] > > Sure, but even if you do everything in the kernel, you're still using > some mbufs. Could you be more specific about how one would DoS a > machine running with natd(8) and divert(4) that would not affect a > machine doing some type of NAT in the kernel? Just saying, "it uses > mbuf clusters," isn't enough for me to understand what type of > resource exhaustion you are talking about and how it can be > exploited. Please draw me a picture. I'm a bit slow today. All I know is that the machine, running simply as a firewall/router, does not suffer from mbuf cluster exaustion. Does not come even close to it. Does not even notice a DoS in progress. As soon as there is a network connection _to_ the firewall, in this case the natd divert socket, this memory starts to get used and, during a DoS, exausted. How's and Why's are really beyond me. It's just a matter of what I see happening. > Also, remember that when you push NAT into the kernel, you now need to > find some place in kernel memory to jam the NAT state table. It opens > up lots of new problems too. NAT in kernel or userland has lots of > pros and cons each way. Now go back to the subject and read it again. Static nat does not have a state table. It need not keep state because it is, well, static. It isn't much different, really, from fwd. fwd changes the next hop, static nat changes one ip address and possibly the next hop. >>>If you don't want to do natd(8) and divert(4), you can do ipfw(8) >>>'fwd' on each machine. >> >>No, fwd is not nat. I need nat. > > Nope, 'fwd' is not NAT, but you can get arbitrary packets from the > network in front of machine A to a socket on machine B with two > 'fwd's. Depending on your needs, that may or may not be > sufficient. (One big trip-up is if machine B is not FreeBSD for > example.) I need fake ip servers being visible from outside. I need to change destination addresses which are routed to through OSPF, _after_ the firewall. Neither of these are possible with fwd. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net The goal of Computer Science is to build something that will at least last until we've finished building it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Oct 1 12:19:33 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B48CE37B401 for ; Tue, 1 Oct 2002 12:19:30 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC6D543E75 for ; Tue, 1 Oct 2002 12:19:28 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id g91JJJx16500; Tue, 1 Oct 2002 16:19:19 -0300 Message-ID: <3D99F536.2050201@tcoip.com.br> Date: Tue, 01 Oct 2002 16:19:18 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020905 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo Cc: ipfw@FreeBSD.ORG Subject: Re: ipfw2 vs. ipfw1 and 4.7 References: <20020902082743.D87097@iguana.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I find it EXTREMELY inconvenient that 4.7 gets released with a KNOWN bug, that was corrected in -current before we were halfway into the 4.7 freeze. Even more so when the change does not affect *any* default installation, because the feature must be explicitly enabled before this code gets even installed. There I go, installing 4.7, with not a worry in mind, only to be bitten by the fwd bug. Luigi Rizzo wrote: > People, > now that the release of 4.7 is approaching, i would really appreciate > if you could give ipfw2 a try and see whether it breaks anything > in your rulesets. Also have a look at the manpage highlighting the > differences between ipfw1 and ipfw2 to see if your rulesets can be > simplified/made more efficient. > > While I am not suggesting a switch in the default to be used in the > distribution, i think it would be appropriate to mention ipfw2's > existence in the release notes and elsewhere. > I really believe it to be at least as reliable as ipfw1 and a lot > more powerful in terms of features. > > I know there are several people already using ipfw2 in production, > and I have no outstanding bug reports for the kernel part of > ipfw2 (there were very few anyways) and only one for the userland > part (wrong byte order for port numbers in "fwd" commands, for which > the [trivial] fix below will be committed soon. > > Also, I am not going to put work on extending ipfw1's life -- > if you have an ipfw1 bug report or feature request for something > that is working in ipfw2, you know what my answer will be... > > cheers > luigi > > NOTE: > > In order to use ipfw2, you must compile your kernel with > > options IPFW2 > > in addition to all other IPFIREWALL* options, and also > rebuild and reinstall /sbin/ipfw and usr/lib/libalias with > > make -DIPFW2 > make -DIPFW2 install > > The manpage for ipfw now tells you the syntax for ipfw2 commands > and has a section highlighting the differences between ipfw1 and ipfw2. > > Index: ipfw2.c > =================================================================== > RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v > retrieving revision 1.12 > diff -u -r1.12 ipfw2.c > --- ipfw2.c 19 Aug 2002 12:36:54 -0000 1.12 > +++ ipfw2.c 2 Sep 2002 15:01:31 -0000 > @@ -908,7 +908,7 @@ > > printf("fwd %s", inet_ntoa(s->sa.sin_addr)); > if (s->sa.sin_port) > - printf(",%d", ntohs(s->sa.sin_port)); > + printf(",%d", s->sa.sin_port); > } > break; > > @@ -2592,7 +2592,7 @@ > if (s == end) > errx(EX_DATAERR, > "illegal forwarding port ``%s''", s); > - p->sa.sin_port = htons( (u_short)i ); > + p->sa.sin_port = (u_short)i; > } > lookup_host(*av, &(p->sa.sin_addr)); > } > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net If the master dies and the disciple grieves, the lives of both have been wasted. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Oct 1 12:55:31 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22D0737B401 for ; Tue, 1 Oct 2002 12:55:29 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9444643E3B for ; Tue, 1 Oct 2002 12:55:28 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021001195259.YSKW18767.rwcrmhc53.attbi.com@blossom.cjclark.org>; Tue, 1 Oct 2002 19:52:59 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g91JqxWn082678; Tue, 1 Oct 2002 12:52:59 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g91JqwOa082677; Tue, 1 Oct 2002 12:52:58 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Tue, 1 Oct 2002 12:52:58 -0700 From: "Crist J. Clark" To: "Daniel C. Sobral" Cc: ipfw@FreeBSD.ORG Subject: Re: Static NAT Message-ID: <20021001195258.GB82099@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <3D9865DB.5040902@tcoip.com.br> <20021001055502.GC79303@blossom.cjclark.org> <3D998142.8070005@tcoip.com.br> <20021001174546.GB81932@blossom.cjclark.org> <3D99EEBE.2010403@tcoip.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D99EEBE.2010403@tcoip.com.br> User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Oct 01, 2002 at 03:51:42PM -0300, Daniel C. Sobral wrote: > Crist J. Clark wrote: > > > > [diet quote] > > > >Sure, but even if you do everything in the kernel, you're still using > >some mbufs. Could you be more specific about how one would DoS a > >machine running with natd(8) and divert(4) that would not affect a > >machine doing some type of NAT in the kernel? Just saying, "it uses > >mbuf clusters," isn't enough for me to understand what type of > >resource exhaustion you are talking about and how it can be > >exploited. Please draw me a picture. I'm a bit slow today. > > All I know is that the machine, running simply as a firewall/router, > does not suffer from mbuf cluster exaustion. Does not come even close to > it. Does not even notice a DoS in progress. As soon as there is a > network connection _to_ the firewall, in this case the natd divert > socket, this memory starts to get used and, during a DoS, exausted. But that's what I'm saying, there is not a network connection _to_ the firewall by an attacker. There are no addtional sockets are created by an attacker, there is nothing consumed socket-wise. There is a single socket opened when natd(8) starts up and it is the only socket ever used (well, there are are some cases where natd(8) can consume more sockets, but you'd actually have to turn this behavior on). If you were to throw an attack at a ipfw(8)-natd(8) box, the first thing you are probably going to start to feel is natd(8) slowing down. If you are using dynamic rules in ipfw(8), they might cause issues in the kernel, but NAT'ing actually doesn't consume any kernel memory resources since it is all done in userland. It may be possible to cause a d(enial|egredation) of service in a ipfw(8)-natd(8) firewall through various attacks, but consuming sockets, and therefore kernel memory associated with a socket, is not a mechanism. It sounds like you are actually getting attacked and seeing problems? Could you show us the data that makes you think that this is related to socket-mbuf problems? There could easily be some obvious mechanism that I'm not seeing. What type of attacks are these? Oh, and what version of FreeBSD is this machine running. There used to be problems with natd(8) trying to resend data when sendto(2) failed rather than dropping. > How's and Why's are really beyond me. It's just a matter of what I see > happening. > > >Also, remember that when you push NAT into the kernel, you now need to > >find some place in kernel memory to jam the NAT state table. It opens > >up lots of new problems too. NAT in kernel or userland has lots of > >pros and cons each way. > > Now go back to the subject and read it again. Static nat does not have a > state table. It need not keep state because it is, well, static. natd(8) always has a state table. NAT code that simply rewrote the destination address on incoming packets to a certain IP and the source on the ones going out from that IP would not be very useful to most people. If that's all you are going to do, why not just really put the address on the destination machine and just route the packets normally? So, one could do this, but the code wouldn't be useful to very many people. > It isn't much different, really, from fwd. fwd changes the next hop, > static nat changes one ip address and possibly the next hop. But you have the traffic going back out too. And natd(8) and most other NAT implementations assume that there will be other traffic going back out as well. > >>>If you don't want to do natd(8) and divert(4), you can do ipfw(8) > >>>'fwd' on each machine. > >> > >>No, fwd is not nat. I need nat. > > > >Nope, 'fwd' is not NAT, but you can get arbitrary packets from the > >network in front of machine A to a socket on machine B with two > >'fwd's. Depending on your needs, that may or may not be > >sufficient. (One big trip-up is if machine B is not FreeBSD for > >example.) > > I need fake ip servers being visible from outside. I need to change > destination addresses which are routed to through OSPF, _after_ the > firewall. Neither of these are possible with fwd. Right, the other big trip-up that I was thinking of adding seems to be yours. 'fwd' is only useful if the target machine is one hop away. I've got some generic code that would be easy to modify to do what you want, but it to uses a divert(4) socket. If you're convinced that divert(4) is the problem, then it wouldn't be any help. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Oct 1 13: 8:11 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 008A237B404 for ; Tue, 1 Oct 2002 13:08:08 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E399643E4A for ; Tue, 1 Oct 2002 13:08:05 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id g91K82x18235; Tue, 1 Oct 2002 17:08:02 -0300 Message-ID: <3D9A00A1.2070809@tcoip.com.br> Date: Tue, 01 Oct 2002 17:08:01 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020905 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cjclark@alum.mit.edu Cc: ipfw@FreeBSD.ORG Subject: Re: Static NAT References: <3D9865DB.5040902@tcoip.com.br> <20021001055502.GC79303@blossom.cjclark.org> <3D998142.8070005@tcoip.com.br> <20021001174546.GB81932@blossom.cjclark.org> <3D99EEBE.2010403@tcoip.com.br> <20021001195258.GB82099@blossom.cjclark.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Crist J. Clark wrote: > On Tue, Oct 01, 2002 at 03:51:42PM -0300, Daniel C. Sobral wrote: > >>Crist J. Clark wrote: >> >>>[diet quote] >>> >>>Sure, but even if you do everything in the kernel, you're still using >>>some mbufs. Could you be more specific about how one would DoS a >>>machine running with natd(8) and divert(4) that would not affect a >>>machine doing some type of NAT in the kernel? Just saying, "it uses >>>mbuf clusters," isn't enough for me to understand what type of >>>resource exhaustion you are talking about and how it can be >>>exploited. Please draw me a picture. I'm a bit slow today. >> >>All I know is that the machine, running simply as a firewall/router, >>does not suffer from mbuf cluster exaustion. Does not come even close to >>it. Does not even notice a DoS in progress. As soon as there is a >>network connection _to_ the firewall, in this case the natd divert >>socket, this memory starts to get used and, during a DoS, exausted. > > > But that's what I'm saying, there is not a network connection _to_ the > firewall by an attacker. There are no addtional sockets are created by > an attacker, there is nothing consumed socket-wise. There is a single > socket opened when natd(8) starts up and it is the only socket ever > used (well, there are are some cases where natd(8) can consume more > sockets, but you'd actually have to turn this behavior on). If you > were to throw an attack at a ipfw(8)-natd(8) box, the first thing you > are probably going to start to feel is natd(8) slowing down. If you > are using dynamic rules in ipfw(8), they might cause issues in the > kernel, but NAT'ing actually doesn't consume any kernel memory > resources since it is all done in userland. > > It may be possible to cause a d(enial|egredation) of service in a > ipfw(8)-natd(8) firewall through various attacks, but consuming > sockets, and therefore kernel memory associated with a socket, is not > a mechanism. > > It sounds like you are actually getting attacked and seeing problems? > Could you show us the data that makes you think that this is related > to socket-mbuf problems? There could easily be some obvious mechanism > that I'm not seeing. What type of attacks are these? > > Oh, and what version of FreeBSD is this machine running. There used to > be problems with natd(8) trying to resend data when sendto(2) failed > rather than dropping. This is a 4.7-something. I'd have to search old syslogs to find the messages, but the reason I think this is happening is simple. The attack is a Syn Flood. Nothing is affected by the attack except natd. The symptom with NAT is packet loss (ie, packets enter from one interface do not exit through the other if they happen to go through natd). Restarting natd eliminates the symptom immediatly on start (and then the flood gets to it again). netstat -m shows mbuf clusters peak equal to maximum, and some hundreds of thousands (maybe more, I don't recall the exact order, but at least that much) of requests for memory denied. On syslog, there are messages of packets dropped because of lack of mbuf clusters. If the attacker ever went to a host without NAT, we didn't even notice it. If you have a likelier explanation, I'm all ears. > > >>How's and Why's are really beyond me. It's just a matter of what I see >>happening. >> >> >>>Also, remember that when you push NAT into the kernel, you now need to >>>find some place in kernel memory to jam the NAT state table. It opens >>>up lots of new problems too. NAT in kernel or userland has lots of >>>pros and cons each way. >> >>Now go back to the subject and read it again. Static nat does not have a >>state table. It need not keep state because it is, well, static. > > > natd(8) always has a state table. NAT code that simply rewrote the > destination address on incoming packets to a certain IP and the source > on the ones going out from that IP would not be very useful to most > people. If that's all you are going to do, why not just really put the > address on the destination machine and just route the packets normally? > So, one could do this, but the code wouldn't be useful to very many > people. > > >>It isn't much different, really, from fwd. fwd changes the next hop, >>static nat changes one ip address and possibly the next hop. > > > But you have the traffic going back out too. And natd(8) and most > other NAT implementations assume that there will be other traffic > going back out as well. > > >>>>>If you don't want to do natd(8) and divert(4), you can do ipfw(8) >>>>>'fwd' on each machine. >>>> >>>>No, fwd is not nat. I need nat. >>> >>>Nope, 'fwd' is not NAT, but you can get arbitrary packets from the >>>network in front of machine A to a socket on machine B with two >>>'fwd's. Depending on your needs, that may or may not be >>>sufficient. (One big trip-up is if machine B is not FreeBSD for >>>example.) >> >>I need fake ip servers being visible from outside. I need to change >>destination addresses which are routed to through OSPF, _after_ the >>firewall. Neither of these are possible with fwd. > > > Right, the other big trip-up that I was thinking of adding seems to > be yours. 'fwd' is only useful if the target machine is one hop away. > > I've got some generic code that would be easy to modify to do what you > want, but it to uses a divert(4) socket. If you're convinced that > divert(4) is the problem, then it wouldn't be any help. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Exciting plays occur only while you are watching the scoreboard or out buying a hot dog. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Oct 1 13:41:22 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAB5D37B414 for ; Tue, 1 Oct 2002 13:41:20 -0700 (PDT) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EC3443E75 for ; Tue, 1 Oct 2002 13:41:20 -0700 (PDT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.12.6/8.12.6) with ESMTP id g91KfJOp007842; Tue, 1 Oct 2002 13:41:19 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.12.6/8.12.6/Submit) id g91KfJRo007841; Tue, 1 Oct 2002 13:41:19 -0700 (PDT) (envelope-from david) Date: Tue, 1 Oct 2002 13:41:19 -0700 (PDT) From: David Wolfskill Message-Id: <200210012041.g91KfJRo007841@bunrab.catwhisker.org> To: david@catwhisker.org, freebsd-ipfw@freebsd.org Subject: Re: Weird problem with ipfw (possibly natd/libalias, but I doubt it) In-Reply-To: <200209300639.g8U6dTFf001254@bunrab.catwhisker.org> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Date: Sun, 29 Sep 2002 23:39:29 -0700 (PDT) >From: David Wolfskill >What happened is that a specialized application that my spouse uses -- >and has been using without incident for several months -- failed its >(internal) authentication when she tried to connect when the firewall >was running today's -STABLE. I rebooted the firewall from the alternate >boot slice (as fallback), and now it works. False alarm. After a colleague (maxim) looked through the packet captures, he suggested that the observed failure was an artifact of the selected server (out of the pool of load-sharing boxes) hardware & OS running, but the service failing to respond to Spouse's clients requests for service. I finally(!) had a chance to test again (boot from the other slice & see if things work) ... and no problem observed. Sorry if I alarmed anyone unnecessarily. Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill david@catwhisker.org To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Oct 1 16:19:32 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00EFF37B401 for ; Tue, 1 Oct 2002 16:19:32 -0700 (PDT) Received: from thufir.bluecom.no (thufir.bluecom.no [217.118.32.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C0E743E4A for ; Tue, 1 Oct 2002 16:19:31 -0700 (PDT) (envelope-from erik@pentadon.com) Received: from erik (a217-118-56-152.bluecom.no [217.118.56.152]) by thufir.bluecom.no (Postfix) with ESMTP id 30DB750EC63 for ; Wed, 2 Oct 2002 01:19:25 +0200 (CEST) Message-ID: <002701c269a0$fad01560$0a00000a@trollbakken.no> From: =?iso-8859-1?Q?Erik_Paulsen_Sk=E5lerud?= To: Subject: DUMMYNET? Date: Wed, 2 Oct 2002 01:19:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Good day. I'm not sure wether this belongs to freebsd-ipfw or freebsd-questions, so I'll just try freebsd-ipfw. Feel free to move this if it doesnt belong here. I'm having difficulties finding out how dynamically share a wan link. We have a ADSL-line (1024/256), wich 3 persons share. I want to be able to share the link so that for example two users are downloading, they get 512kbit each. If 1 user is downloading, he gets 1024kbit. I know that TCP Windows already does this, but isnt that just for each TCP session? I'd like to get this managed by -all- traffic for each IP. Any ideas/configuration examples? Thanks in advance, Erik. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 5:18:32 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C1BE37B401 for ; Wed, 2 Oct 2002 05:18:30 -0700 (PDT) Received: from schurli.wu-wien.ac.at (schurli.wu-wien.ac.at [137.208.16.32]) by mx1.FreeBSD.org (Postfix) with SMTP id E655943E42 for ; Wed, 2 Oct 2002 05:18:24 -0700 (PDT) (envelope-from georg-ipfw@graf.priv.at) Received: (qmail 17390 invoked by uid 1001); 2 Oct 2002 11:51:43 -0000 Date: Wed, 2 Oct 2002 13:51:43 +0200 From: Georg Graf To: freebsd-ipfw@freebsd.org Subject: Natd plus statefull connections impossible? Message-ID: <20021002115143.GA54827@graf.priv.at> Mail-Followup-To: freebsd-ipfw@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, this is a long story. Please be patient. There is a thing I want to do with stateful rules and nat, but I think it is impossible. I have a cable connection at home, and I may not run any services to the outside world (client only), but there is a fixed IP. But I want to run services available to _some_ hosts on the internet. There is a divert natd setup for 2-3 internal machines. For new services which per default bind to *.* I thought I could make a firewall that blocks my configuration lazyness with stateful firewall rules, so I dont have to bother turning on nfsd or something like that. The idea was "Have a nat setup and stateful rules for all coming from the natted network or the gateway machine to the Internet. Allow incoming from friends. Deny all the rest that does not have a dynamic rule. I failed. The internal interface is ed0 (192.168.0.1), the external where natd runs on is ep0 (195.34.150.181). All the rulesets I tried started with allow ip from any to any via lo0 and ed0. Look: 1) "allow keep state on packets before rewriting": i.e.: allow ip from any to any out via ep0 keep-state and then: divert natd ip from any to any out via ep0 BUT this rule (divert natd) never matches because the allow in the rule before already sends the packet out. So it is not possible to have stateful rules like (192.168.0.2 2141<-> 213.160.193.116 80) because I would have to divert and allow+keep in one rule which is impossible. 2) "allow keep-state on packets as are rewritten while passing out through ep0": divert natd ip from any to any out via ep0 and then allow ip from any to any out via ep0 Here the problem is with the packets coming back: If the check-state comes before the divert, then the packets which need to be rewritten to go to an internal host are ejected out of the chain too early. If the check-state comes after the divert, then the rules for the internal network do not match, because the rules are installed as (195.34.150.181 4711 <-> 213.160.193.116 80) and do not match (192.168.0.2 4711 <-> 213.160.193.116 80) for example. 3) I also tried to put divert and keep-state in one rule, but apparently this is nonsense. The dynamic rules are needed for a decision if a packet should be denied or allowed. Anyhow, the result was funny: The packets seemed to have an endless loop in line 500: ipfw -f flush ipfw add 100 allow ip from any to any via lo0 ipfw add 200 allow ip from any to any via ed0 ipfw add 300 allow ip from any to any via wi0 ipfw add 400 check-state ipfw add 500 divert natd log logamount 0 ip from me to any out via ep0 keep-state ipfw add 600 allow log logamount 0 ip from me to any out via ep0 keep-state 4) Let's try one more: Maybe we can have the following for incoming packets from the internet: check-state (for connections back to the gateway host) divert check-state (for connections back to the natted network) Here we would have to allow+keep-state the outgoing packet from the natted network while it comes in via ed0, allow keep-state from 192.* to internet in via ed0 divert outgoing through ep0 allow + (keep-state only for the packets originating from the gateway machine) out through ep0 BUT in the step mentioned last there is no possibility to decide which one originated from the gateway because its after rewriting. Questions: a) is there a way to do the thing I want at all with ipfw? b) if no, is there a proof? c) Did I miss something obvious? (Maybe the intelligent use of skipto?) d) Did I miss something not so obvious? Thank for your brain! George -- Georg Graf http://georg.graf.priv.at/ PGP Key ID: 0xA5232AD5 Gobergasse 43/2 A-1130 Wien Tel: +43 1 8796723 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 6:23: 0 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AC1137B401 for ; Wed, 2 Oct 2002 06:23:00 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAA3B43E4A for ; Wed, 2 Oct 2002 06:22:59 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g92DMxIb022381; Wed, 2 Oct 2002 06:22:59 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g92DMwpf022380; Wed, 2 Oct 2002 06:22:58 -0700 (PDT) (envelope-from rizzo) Date: Wed, 2 Oct 2002 06:22:58 -0700 From: Luigi Rizzo To: "Daniel C. Sobral" Cc: ipfw@FreeBSD.ORG Subject: Re: ipfw2 vs. ipfw1 and 4.7 Message-ID: <20021002062258.B22163@iguana.icir.org> References: <20020902082743.D87097@iguana.icir.org> <3D99F536.2050201@tcoip.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D99F536.2050201@tcoip.com.br>; from dcs@tcoip.com.br on Tue, Oct 01, 2002 at 04:19:18PM -0300 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Oct 01, 2002 at 04:19:18PM -0300, Daniel C. Sobral wrote: > I find it EXTREMELY inconvenient that 4.7 gets released with a KNOWN > bug, that was corrected in -current before we were halfway into the 4.7 ENOTIME luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 6:40:59 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2666C37B401 for ; Wed, 2 Oct 2002 06:40:58 -0700 (PDT) Received: from mail1.ing.nl (mail1.ing.nl [145.221.93.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E45F643E6E for ; Wed, 2 Oct 2002 06:40:56 -0700 (PDT) (envelope-from Danny.Carroll@mail.ing.nl) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: ipfw2 vs. ipfw1 and 4.7 Date: Wed, 2 Oct 2002 15:38:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ipfw2 vs. ipfw1 and 4.7 Thread-Index: AcJpf39EqLbhyWJDSEOVeQLHkdFT4AAmR8mw From: Importance: normal To: , Cc: X-OriginalArrivalTime: 02 Oct 2002 13:38:20.0604 (UTC) FILETIME=[F8D197C0:01C26A18] Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Daniel C. Sobral [mailto:dcs@tcoip.com.br] > Sent: 01 October 2002 21:19 > I find it EXTREMELY inconvenient that 4.7 gets released with a KNOWN=20 > bug, that was corrected in -current before we were halfway into the = 4.7=20 > freeze. Even more so when the change does not affect *any* default=20 > installation, because the feature must be explicitly enabled before = this=20 > code gets even installed. inconvenient? How about contributing? Most contributers are volunteers you know..... -D -----------------------------------------------------------------=0A= ATTENTION:=0A= The information in this electronic mail message is private and=0A= confidential, and only intended for the addressee. Should you=0A= receive this message by mistake, you are hereby notified that=0A= any disclosure, reproduction, distribution or use of this=0A= message is strictly prohibited. Please inform the sender by=0A= reply transmission and delete the message without copying or=0A= opening it.=0A= =0A= Messages and attachments are scanned for all viruses known.=0A= If this message contains password-protected attachments, the=0A= files have NOT been scanned for viruses by the ING mail domain.=0A= Always scan attachments before opening them.=0A= ----------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 6:47:52 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A725837B401 for ; Wed, 2 Oct 2002 06:47:51 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36F7343E6E for ; Wed, 2 Oct 2002 06:47:51 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g92DlpIb022632; Wed, 2 Oct 2002 06:47:51 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g92DloQj022631; Wed, 2 Oct 2002 06:47:50 -0700 (PDT) (envelope-from rizzo) Date: Wed, 2 Oct 2002 06:47:50 -0700 From: Luigi Rizzo To: Danny.Carroll@mail.ing.nl Cc: dcs@tcoip.com.br, ipfw@FreeBSD.ORG Subject: Re: ipfw2 vs. ipfw1 and 4.7 Message-ID: <20021002064750.G22163@iguana.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Danny.Carroll@mail.ing.nl on Wed, Oct 02, 2002 at 03:38:20PM +0200 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG in defense of daniel, this particular problem has a know fix (attached to his message) and it "just" requires some amount of committer time (more than what i have spent in replying to this thread) to put it into stable, verify that it works as desired, get re@ approval and do the commmit. Daniel is not a committer so the most he can do is remind me of the pending MFC, which i appreciate. Now, the tone might have been slightly different, but i am just looking at the good intentions behind it. cheers luigi On Wed, Oct 02, 2002 at 03:38:20PM +0200, Danny.Carroll@mail.ing.nl wrote: > > From: Daniel C. Sobral [mailto:dcs@tcoip.com.br] > > Sent: 01 October 2002 21:19 > > I find it EXTREMELY inconvenient that 4.7 gets released with a KNOWN > > bug, that was corrected in -current before we were halfway into the 4.7 > > freeze. Even more so when the change does not affect *any* default > > installation, because the feature must be explicitly enabled before this > > code gets even installed. > > inconvenient? How about contributing? > Most contributers are volunteers you know..... > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 7:22: 4 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4BD537B401 for ; Wed, 2 Oct 2002 07:22:02 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB16943E75 for ; Wed, 2 Oct 2002 07:22:00 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id g92ELex16998; Wed, 2 Oct 2002 11:21:40 -0300 Message-ID: <3D9B00F3.9040308@tcoip.com.br> Date: Wed, 02 Oct 2002 11:21:39 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020905 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo Cc: Danny.Carroll@mail.ing.nl, ipfw@FreeBSD.ORG Subject: Re: ipfw2 vs. ipfw1 and 4.7 References: <20021002064750.G22163@iguana.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > in defense of daniel, this particular problem has a know fix (attached > to his message) and it "just" requires some amount of committer > time (more than what i have spent in replying to this thread) > to put it into stable, verify that it works as desired, get > re@ approval and do the commmit. > > Daniel is not a committer so the most he can do is remind me of the > pending MFC, which i appreciate. Now, the tone might have been > slightly different, but i am just looking at the good intentions > behind it. Actually, I am a committer. I don't know what I would have done or not had I suspected the fix had *not* been merged. I was, however, under the distinct impression it had already been merged. Looking back, I see that you said "which reminds me I have to...", so I got the impression you were going to do it, which somehow become the impression that you had done it. The fix was actually provided by yourself, in the message in which you asked for feedback given that 4.7 was entering the release process. I mentioned in my reply to that the bug *did* cause me trouble. Perhaps the trouble this caused me makes me touchy about it, but I extremely dislike known problems with known fixes left unattended on -stable, and I dislike this even more when we are preparing a release. Every bug in a release gives us a black eye. If we don't know about the bug, if it's difficult to reproduce, if the fix has subtle side-effects or has complications or is just plain difficult, I understand that. But a simple bug, easily reproduced, easily fixed, with no side effects? That does annoy me. > > cheers > luigi > > On Wed, Oct 02, 2002 at 03:38:20PM +0200, Danny.Carroll@mail.ing.nl wrote: > >>>From: Daniel C. Sobral [mailto:dcs@tcoip.com.br] >>>Sent: 01 October 2002 21:19 >>>I find it EXTREMELY inconvenient that 4.7 gets released with a KNOWN >>>bug, that was corrected in -current before we were halfway into the 4.7 >>>freeze. Even more so when the change does not affect *any* default >>>installation, because the feature must be explicitly enabled before this >>>code gets even installed. >> >>inconvenient? How about contributing? >>Most contributers are volunteers you know..... >> > -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Preudhomme's Law of Window Cleaning: It's on the other side. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 7:40:20 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 404B437B404 for ; Wed, 2 Oct 2002 07:40:19 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 900AC43E42 for ; Wed, 2 Oct 2002 07:40:18 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g92EeIIb023022; Wed, 2 Oct 2002 07:40:18 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g92EeIF5023021; Wed, 2 Oct 2002 07:40:18 -0700 (PDT) (envelope-from rizzo) Date: Wed, 2 Oct 2002 07:40:18 -0700 From: Luigi Rizzo To: "Daniel C. Sobral" Cc: Danny.Carroll@mail.ing.nl, ipfw@FreeBSD.ORG Subject: Re: ipfw2 vs. ipfw1 and 4.7 Message-ID: <20021002074018.A22920@iguana.icir.org> References: <20021002064750.G22163@iguana.icir.org> <3D9B00F3.9040308@tcoip.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D9B00F3.9040308@tcoip.com.br>; from dcs@tcoip.com.br on Wed, Oct 02, 2002 at 11:21:39AM -0300 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Oct 02, 2002 at 11:21:39AM -0300, Daniel C. Sobral wrote: > Luigi Rizzo wrote: > > in defense of daniel, this particular problem has a know fix (attached > > to his message) and it "just" requires some amount of committer > > time (more than what i have spent in replying to this thread) > > to put it into stable, verify that it works as desired, get > > re@ approval and do the commmit. > > > > Daniel is not a committer so the most he can do is remind me of the > > pending MFC, which i appreciate. Now, the tone might have been > > slightly different, but i am just looking at the good intentions > > behind it. > > Actually, I am a committer. I don't know what I would have done or not ok, then instead of simply being annoyed be constructive, and do whatever is required to fix the problem, which boils down to what i listed above plus a "do you mind if I do this MFC" email to the author of the bug if you feel like. Posting "i am annoyed" messages does not fix problems nor has a very positive impact on people... cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 8: 7:25 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5827537B401 for ; Wed, 2 Oct 2002 08:07:22 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8665043E42 for ; Wed, 2 Oct 2002 08:07:20 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id g92F6Nx18574; Wed, 2 Oct 2002 12:06:23 -0300 Message-ID: <3D9B0B6F.5020304@tcoip.com.br> Date: Wed, 02 Oct 2002 12:06:23 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020905 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Georg Graf Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: Natd plus statefull connections impossible? References: <20021002115143.GA54827@graf.priv.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Georg Graf wrote: > [diet quote: I want to use nat and stateful firewall rules] > > Questions: > > a) is there a way to do the thing I want at all with ipfw? > b) if no, is there a proof? > c) Did I miss something obvious? (Maybe the intelligent use of skipto?) > d) Did I miss something not so obvious? For a long time, I also thought it was not possible. But, while working on another firewall, and trying to understand how NAT interacted with firewall rules (they were separated), it came to me that all rules applied to the real addresses, never their translation. I then set out to reproduce this in ipfw. Here is how. Requirements: 1) If the packet is outgoing (ie, will be natted on it's way out), you want the NAT to be the last thing done. 2) If the packet is incoming (ie, will be "un-natted" on it's way in), you want the NAT to be the first thing done. Now, the second requirement is easily accomplished. Just put the nat rules at the beginning: ipfw add divert natd ip from any to ${NAT_ADDRESSES} in via ${EXT_IF} There. If a packet is arriving on the external interface to a natted address, unnat it and be done with it. Now, the reverse is much more difficult, because the first "accept" rule will end processing. The secret, alas, is *also* adding it to the beginning. First, the rule, then the explanation: ipfw add divert natd ip from ${NATABLE_ADDRESSES} to any out via ${EXT_IF} ipfw add allow ip from ${NAT_ADDRESSES} to any out via ${EXT_IF} Well, what it does is easy to see. Nat anything outgoing that needs to be natted, and then allow it to go out. More difficult to explain is why this is ok (and when it isn't). Thing is, a packet goes through ipfw rules two times. First, when entering through and interface, and second when leaving through another (or the same, as the case may be). Remember that I proposed to have rules apply only to the _unnatted_ addresses, right? So, when the packet arrives on the firewall, it by-passes the first rule because it's "in", not "out". The second rule is by-passed for the very same reason. Thus, the packet has to be allowed (or denied) by the normal firewall rules. The second time around, though, the packet will be blissfully allowed to go, the filtering having been done on the first time. Now, what blind-spots may this introduce? First, you have to be sure you don't have any rules that have to be done on the packet's way out. Mind you, you still can have such rules for packets going to your internal networks, or packets going out that do not get natted. Second, one must never enable any feature that makes ipfw process the rules only once. IIRC, there are ways to do that. Third, and most importantly, this rule won't block any outgoing traffic from the firewall itself, if the nat address is used by the firewall itself (as is very common). I have thought of two solutions for this third problem. First, and most simple, but which goes agains the idea of having the NAT first thing, is having the firewall own rules as first thing: # Firewall rules ipfw check-state ipfw add allow tcp from me to any ssh setup keep-state out via ${EXT_IF} ipfw add allow udp from me to any 53 keep-state out via ${EXT_IF} ipfw add allow icmp from me to any out via ${EXT_IF} ipfw add deny ip from me to any out via ${EXT_IF} # Nat rules ... # Main rules ipfw check-state So, what that does is allowing the firewall to do ssh, dns requests and pings (well, more than pings, but let's not go there), denying anything else, and only then doing the NAT, which will let *other* kinds of traffic to go out using the firewall ip. The two check-states ought to do the right thing. If they don't, then the deny in the first set must be restricted to outgoing setup TCP packets only, and you'll have to live with that. The second alternative is placing the line that allows all outgoing traffic out at the *end* of the rules, before the denies. This won't work if you have denies alternated with allows. I can think of a few other alternatives, but these are the best, IMHO. So. There you have. The stateful rules will work, because they will ALWAYS refer to the real address, not the translated one, no matter if the packet is incoming or outgoing. And it *will* be stateful, because the packets will have been allowed by the stateful rules when entering the firewall, or they won't get the *chance* to go out. :-) If anyone is willing to create an rc.firewall profile with stateful rules *and* NAT, preferably based on one of the others, I'll see if I can get it committed. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Mundus vult decipi decipiatur ergo. -- Xaviera Hollander [The world wants to be cheated, so cheat.] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 8:16:26 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B095137B404 for ; Wed, 2 Oct 2002 08:16:24 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2718A43E6A for ; Wed, 2 Oct 2002 08:16:24 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g92FGNIb023265; Wed, 2 Oct 2002 08:16:23 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g92FGNY8023264; Wed, 2 Oct 2002 08:16:23 -0700 (PDT) (envelope-from rizzo) Date: Wed, 2 Oct 2002 08:16:23 -0700 From: Luigi Rizzo To: "Daniel C. Sobral" Cc: Georg Graf , freebsd-ipfw@FreeBSD.ORG Subject: Re: Natd plus statefull connections impossible? Message-ID: <20021002081623.B23060@iguana.icir.org> References: <20021002115143.GA54827@graf.priv.at> <3D9B0B6F.5020304@tcoip.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D9B0B6F.5020304@tcoip.com.br>; from dcs@tcoip.com.br on Wed, Oct 02, 2002 at 12:06:23PM -0300 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Oct 02, 2002 at 12:06:23PM -0300, Daniel C. Sobral wrote: ... > For a long time, I also thought it was not possible. But, while working > on another firewall, and trying to understand how NAT interacted with > firewall rules (they were separated), it came to me that all rules > applied to the real addresses, never their translation. Actually, the last statement is not true in general (it may be true with the specific rule organization that Daniel suggests below.) In general, the addresses that the firewall sees depends on whether the packet is checked before or after the packet is reinjected in the firewall after going through the natd daemon. cheers luigi > > Requirements: > > 1) If the packet is outgoing (ie, will be natted on it's way out), you > want the NAT to be the last thing done. > > 2) If the packet is incoming (ie, will be "un-natted" on it's way in), > you want the NAT to be the first thing done. ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 9:51:19 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47C9937B401 for ; Wed, 2 Oct 2002 09:51:17 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 029EC43E77 for ; Wed, 2 Oct 2002 09:51:15 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id g92Go0x21682; Wed, 2 Oct 2002 13:50:00 -0300 Message-ID: <3D9B23B7.1000906@tcoip.com.br> Date: Wed, 02 Oct 2002 13:49:59 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20020905 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo Cc: Georg Graf , freebsd-ipfw@FreeBSD.ORG Subject: Re: Natd plus statefull connections impossible? References: <20021002115143.GA54827@graf.priv.at> <3D9B0B6F.5020304@tcoip.com.br> <20021002081623.B23060@iguana.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > On Wed, Oct 02, 2002 at 12:06:23PM -0300, Daniel C. Sobral wrote: > ... > >>For a long time, I also thought it was not possible. But, while working >>on another firewall, and trying to understand how NAT interacted with >>firewall rules (they were separated), it came to me that all rules >>applied to the real addresses, never their translation. > > > Actually, the last statement is not true in general (it > may be true with the specific rule organization that Daniel > suggests below.) > In general, the addresses that the firewall sees depends on whether > the packet is checked before or after the packet is reinjected in the > firewall after going through the natd daemon. Sorry if I didn't make it clear. I was trying to understand how ANOTHER kind of firewall worked, and in THAT firewall, nat was not done by firewall rules, but as a separate function in the packet routing. What I suggested here was how to simulate that behavior. > > cheers > luigi > > >>Requirements: >> >>1) If the packet is outgoing (ie, will be natted on it's way out), you >>want the NAT to be the last thing done. >> >>2) If the packet is incoming (ie, will be "un-natted" on it's way in), >>you want the NAT to be the first thing done. > > ... -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: Daniel.Capo@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net Progress is impossible without change, and those who cannot change their minds cannot change anything. -- G.B. Shaw To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 10:36:25 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCB7437B401; Wed, 2 Oct 2002 10:36:23 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DD5843E42; Wed, 2 Oct 2002 10:36:23 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021002173623.GSVH18767.rwcrmhc53.attbi.com@blossom.cjclark.org>; Wed, 2 Oct 2002 17:36:23 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g92HaLWn087456; Wed, 2 Oct 2002 10:36:22 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g92HaKhI087455; Wed, 2 Oct 2002 10:36:20 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Wed, 2 Oct 2002 10:36:20 -0700 From: "Crist J. Clark" To: ipfw@freebsd.org, luigi@freebsd.org Subject: ipfw(8), bridge(4), and arp(4) Message-ID: <20021002173620.GA87135@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I am seeing some strangeness with ipfw(8) and bridge(4). It looks like ARP is being blocked somewhere for the bridging host. When I enable bridging, everything works fine. When I turn on ipfw(8) in the bridge, # sysctl net.link.ether.bridge_ipfw=1 Things get a little messed up. The funny thing is, machines can communicate freely with one another on opposite sides of the bridge, but the bridge host itself seems to be having some problems. When I try to communicate directly with the bridge host, the ARPs go unanswered. tcpdump(8) on any host, including the bridge host, show the "who-is" messages go out, but there is no response. This seems to be an ARP or at least non-IP problem. Can anyone reproduce the following or something like it: (1) Establish a TCP connection to a bridging host (e.g. ssh or telnet in). (2) On the bridging host, turn on ipfw(8) in the bridge, # sysctl net.link.ether.bridge_ipfw=1 (3) If your arp(8) cache is still fresh, your TCP connection should work fine. (4) On the TCP client, clear the arp(8) entry for the bridge host from the cache, # arp -d bridge-host (5) Does your TCP connection no longer work? (6) Turn off ipfw(8) in the bridge, # sysctl net.link.ether.bridge_ipfw=0 (7) Does the TCP connection snap back to life? I'm wondering if this is a result of some of the changes to ipfw(8) in bridging and filtering at the Ethernet layer. Bug or feature? luigi, is there something, besides code and commit messages, documenting the design of ipfw(8) interaction at the link-layer? I've bumped into this while trying to get IPFilter working in RELENG_4 bridging again. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 13:52:49 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64A1837B40C for ; Wed, 2 Oct 2002 13:52:48 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16E1243E65 for ; Wed, 2 Oct 2002 13:52:48 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g92KqkIb027437; Wed, 2 Oct 2002 13:52:46 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g92KqjdN027436; Wed, 2 Oct 2002 13:52:45 -0700 (PDT) (envelope-from rizzo) Date: Wed, 2 Oct 2002 13:52:45 -0700 From: Luigi Rizzo To: cjclark@alum.mit.edu Cc: ipfw@FreeBSD.ORG Subject: Re: ipfw(8), bridge(4), and arp(4) Message-ID: <20021002135245.B27273@iguana.icir.org> References: <20021002173620.GA87135@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021002173620.GA87135@blossom.cjclark.org>; from crist.clark@attbi.com on Wed, Oct 02, 2002 at 10:36:20AM -0700 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Oct 02, 2002 at 10:36:20AM -0700, Crist J. Clark wrote: > I am seeing some strangeness with ipfw(8) and bridge(4). It looks like > ARP is being blocked somewhere for the bridging host. ... > I'm wondering if this is a result of some of the changes to ipfw(8) in > bridging and filtering at the Ethernet layer. Bug or feature? it might certainly depend on that change, and in case, it is a bug (there is probably a pending PR for that). Thanks for the detailed report, i'll see if i can find the time to investigate on it. > luigi, is there something, besides code and commit messages, > documenting the design of ipfw(8) interaction at the link-layer? I've no, sorry. But basically enabling or disabling bridge_ipfw should be transparent for the bridging host. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Oct 2 15:39:52 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B05237B401 for ; Wed, 2 Oct 2002 15:39:51 -0700 (PDT) Received: from kalahari.flup.org (kalahari.flup.org [198.78.66.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3020A43E6E for ; Wed, 2 Oct 2002 15:39:47 -0700 (PDT) (envelope-from allan@saddi.com) Received: from kalahari (kalahari [198.78.66.13]) by kalahari.flup.org (Postfix) with ESMTP id 4D8F115A1E for ; Wed, 2 Oct 2002 15:39:42 -0700 (PDT) Date: Wed, 2 Oct 2002 15:39:41 -0700 (PDT) From: Allan Saddi X-X-Sender: asaddi@kalahari.flup.org To: freebsd-ipfw@freebsd.org Subject: ipfw + ICMP_BANDLIM? Message-ID: <20021002152116.A12717-100000@kalahari.flup.org> Organization: Saddi Enterprises MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi there, I was wondering if there was any reason why ipfw's reject/ unreach/reset rules were not subjected to any sort of rate limiting? (imposed by the ICMP_BANDLIM option) I made a small modification[1] to ip_fw.c (on a 4.6.2 system) to accomplish this. I want to bring these changes into production, but I first wanted to know if this omission was by design? (Perhaps the rate limiting is being done someplace else?) Thanks, Allan [1] http://www.saddi.com/allan/tmp/ipfw-bandlim.diff -- Allan Saddi "The Earth is the cradle of mankind, allan@saddi.com but we cannot live in the cradle http://www.saddi.com/allan/ forever." - K.E. Tsiolkovsky To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Oct 3 16:28: 9 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BFC137B404 for ; Thu, 3 Oct 2002 16:28:05 -0700 (PDT) Received: from mta11.srv.hcvlny.cv.net (mta11.srv.hcvlny.cv.net [167.206.5.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 631AF43E6E for ; Thu, 3 Oct 2002 16:28:03 -0700 (PDT) (envelope-from avg@icyb.net.ua) Received: from conversion-daemon.mta11.srv.hcvlny.cv.net by mta11.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) id <0H3F00B01G7WMH@mta11.srv.hcvlny.cv.net> for freebsd-ipfw@freebsd.org; Thu, 03 Oct 2002 18:43:39 -0400 (EDT) Received: from edge.foundation.invalid (ool-182f90f3.dyn.optonline.net [24.47.144.243]) by mta11.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) with ESMTP id <0H3F00J2IF3ZV6@mta11.srv.hcvlny.cv.net>; Thu, 03 Oct 2002 18:14:24 -0400 (EDT) Date: Thu, 03 Oct 2002 18:14:23 -0400 (EDT) From: Andriy Gapon Subject: Re: Natd plus statefull connections impossible? X-X-Sender: avg@edge.foundation.invalid To: Georg Graf Cc: freebsd-ipfw@freebsd.org Message-id: <20021003161757.I32181-100000@edge.foundation.invalid> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Georg, I've been trying to do the same thing (or almost the same) recently and I have found this one trick on some mailing list archive (don't remember where and who is the author, try searching on google for "nat ipfw stateful"). After playing around for some time I have some observations/rules of thumb that helped me to build a quite simple and much stateless set of rules than I originally had in my mind. 1simpe/ no stateful rules before divert rules 1expanded/ if you have stateful rules that may match the same packet that you want to go throgh natd, you must not put any keep-state, check-state rules before divert 2/ most of the rules will be after divert(s), so always keep in mind that all incoming traffic has addresses internal_ip<-real_world_ip and all outgoing traffic has addresses external_interface_ip->real_world_ip. 3/ dynamic rules that were created by match of a stateful rule on a particular interface do apply to all interfaces 4/ the only way to have a dynamic rule that matches internal_ip<-real_world_ip packet is to put a keep-state rule on interal interface that would match internal_ip->real_world_ip packet when it enters a gateway host 5/ for access to a server on the internal network you can have either of: a. rule that allows packets from XXX to internal adderss:port b. (trust natd) rule that allows all packets after divert that originated in real world and go to internal network plus either of: a'. rule that allows packets from external_if:forwarded_port to XXX b'. general rule that allows all outgoing traffic from external_if Ok, here is my simplest firewall ruleset: (rl1 - internal_if, rl0 - external_if) #loopback stuff add 00100 allow ip from any to any via lo0 add 00110 deny ip from any to 127.0.0.0/8 add 00120 deny ip from 127.0.0.0/8 to any #trust internal network add 00125 allow all from any to any via rl1 #make sure we don't leak internal traffic out there add 00150 deny all from any to 192.168.0.0/16 via rl0 add 00200 divert natd all from 192.168.0.0/16 to any out via rl0 #probably just paranoia add 00250 deny all from 192.168.0.0/16 to any via rl0 #allow me to connect to gateway from outside via ssh (can not be stateful) add 00400 allow tcp from any to me ssh in via rl0 add 00410 allow tcp from me ssh to any out via rl0 #translate incoming add 00500 divert natd all from any to me in via rl0 #trust natd, it shouldn't translate destination address to my internal #network unless session was initiated from there, or this a port, address #etc forwarding add 00510 allow ip from any to 192.168.0.0/16 in via rl0 #check dynamic rules add 00600 check-state #allow all outgoing traffic (this will match packets both originated in #in internal network and here on gateway add 01000 allow ip from me to any out via rl0 keep-state add 01200 allow icmp from any to any #all legitimate traffic should have matched above add 01300 deny log logamount 30 tcp from any to any established #don't put this garbage in logs add 64900 deny udp from any to any 137,138,139 in recv rl0 add 64901 deny tcp from any to any 137,138,139,443,1443,27374 in recv rl0 add 65000 deny log logamount 30 ip from any to any as you have figured out this allows all traffic established from inside as well as traffic established from the outside and forwarded ny natd. Here's also much more elaborate, prohibitive and paranoid ruleset. It also illustrates the idea of keep-state rules on internal interface that produce dynamic rules for the external interface: (sorry, much less comments) add 00100 allow ip from any to any via lo0 add 00110 deny ip from any to 127.0.0.0/8 add 00120 deny ip from 127.0.0.0/8 to any add 00130 allow udp from any bootps to any bootpc add 00131 allow udp from me bootpc to any bootps add 00150 deny all from any to 10.0.0.0/8 via rl0 add 00151 deny all from any to 172.16.0.0/12 via rl0 add 00152 deny all from any to 192.168.0.0/16 via rl0 add 00153 deny all from any to 0.0.0.0/8 via rl0 add 00154 deny all from any to 169.254.0.0/16 via rl0 add 00155 deny all from any to 192.0.2.0/24 via rl0 add 00156 deny all from any to 224.0.0.0/4 via rl0 add 00157 deny all from any to 240.0.0.0/4 via rl0 add 00200 divert natd all from 192.168.0.0/16 to any out via rl0 add 00250 deny all from 10.0.0.0/8 to any via rl0 add 00251 deny all from 172.16.0.0/12 to any via rl0 add 00252 deny all from 192.168.0.0/16 to any via rl0 add 00253 deny all from 0.0.0.0/8 to any via rl0 add 00254 deny all from 169.254.0.0/16 to any via rl0 add 00255 deny all from 192.0.2.0/24 to any via rl0 add 00256 deny all from 224.0.0.0/4 to any via rl0 add 00257 deny all from 240.0.0.0/4 to any via rl0 add 00301 deny ip from not 192.168.1.0/24 to any in via rl1 add 00303 deny ip from any to not 192.168.1.0/24 out via rl1 add 00400 allow tcp from any to me ssh in via rl0 add 00410 allow tcp from me ssh to any out via rl0 add 00500 divert natd all from any to me in via rl0 #keep-state rules on the internal if add 00550 allow tcp from any to not 192.168.0.0/16 in via rl1 setup keep-state add 00552 allow ip from any to not 192.168.0.0/16 in via rl1 keep-state add 00553 allow all from any to any via rl1 add 00600 deny log logamount 10 ip from any to any frag add 00900 reset log logamount 10 tcp from any to me auth in via rl0 #allow only ssh on 2222, and 49333 port connection #to a particular internal host add 00950 allow tcp from any to 192.168.1.12 22 in via rl0 setup add 00951 allow tcp from me 2222 to any out via rl0 established add 00970 allow tcp from any to 192.168.1.12 49333 in via rl0 setup add 00971 allow tcp from me 49333 to any out via rl0 established add 01000 deny log logamount 30 tcp from any to any established add 01002 allow tcp from me to any out via rl0 setup keep-state add 01103 allow udp from me to any domain via rl0 keep-state add 01104 allow tcp from me to any domain via rl0 setup keep-state add 01105 allow udp from me to any ntp via rl0 keep-state add 01106 allow udp from me to any out via rl0 add 01200 allow icmp from any to any add 64000 allow tcp from me to any out tcpflags rst add 64900 deny udp from any to any 137,138,139 in recv rl0 add 64901 deny tcp from any to any 137,138,139,443,1443,27374 in recv rl0 add 65000 deny log logamount 30 ip from any to any comments are welcome. Hope this is useful for you, because both configs are actually working for me. -- Andriy Gapon * Hang on tightly, let go lightly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Oct 3 22: 9:22 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CF9237B401 for ; Thu, 3 Oct 2002 22:09:21 -0700 (PDT) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.5.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C40443E6E for ; Thu, 3 Oct 2002 22:09:21 -0700 (PDT) (envelope-from agapon@excite.com) Received: from edge.foundation.invalid (ool-182f90f3.dyn.optonline.net [24.47.144.243]) by mta1.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) with ESMTP id <0H3F00MHVYC1EN@mta1.srv.hcvlny.cv.net> for freebsd-ipfw@freebsd.org; Fri, 04 Oct 2002 01:09:38 -0400 (EDT) Received: from localhost (localhost.foundation.invalid [127.0.0.1]) by edge.foundation.invalid (8.12.3/8.12.3) with ESMTP id g9459Ji0045910; Fri, 04 Oct 2002 01:09:19 -0400 (EDT envelope-from agapon@excite.com) Date: Fri, 04 Oct 2002 01:09:19 -0400 (EDT) From: Andriy Gapon Subject: Re: Natd plus statefull connections impossible? [correction!] X-X-Sender: avg@edge.foundation.invalid To: Georg Graf Cc: freebsd-ipfw@freebsd.org Message-id: <20021004010449.O45826-100000@edge.foundation.invalid> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG correction: in the more complex set, rules like: allow tcp from any to 192.168.1.12 NNN in via rl0 setup should be stateful: allow tcp from any to 192.168.1.12 NNN in via rl0 setup keep-state sorry lost it during copying. -- Andriy Gapon * "I do not know myself, and God forbid that I should." Johann Wolfgang von Goethe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Oct 4 4:14:16 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16C6C37B401 for ; Fri, 4 Oct 2002 04:14:15 -0700 (PDT) Received: from mail1.ing.nl (mail1.ing.nl [145.221.93.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6FB243E4A for ; Fri, 4 Oct 2002 04:14:13 -0700 (PDT) (envelope-from Danny.Carroll@mail.ing.nl) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Question about to/from matching. Date: Fri, 4 Oct 2002 13:14:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Thread-Topic: Question about to/from matching. thread-index: AcJrlyPPETTLsZSgQfSjuiyNqVt/gg== From: To: X-OriginalArrivalTime: 04 Oct 2002 11:14:00.0792 (UTC) FILETIME=[23FEA580:01C26B97] Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have not got my copy of "Internetworking with TCP/IP Vol. x" with me = (someone borrowed it indefinatly) so forgive this rather basic question. I have a rule, very early in my ruleset that says: deny log ip from any to 10.0.0.0/8 via xl0 but my gateway (and default route) is 10.0.0.100 Now, it's working the way I want it to... In that it sends outside = stuff to 10.0.0.100 and I can't telnet directly to the gateway. But I = am curious why this rule does not get inforced. What does a TCP packet look like when it's being sent *to* a remote = destination, but via a gateway. Does the ip stack translate 10.0.0.100 = to an ethernet address and pass it on that way? -D -----------------------------------------------------------------=0A= ATTENTION:=0A= The information in this electronic mail message is private and=0A= confidential, and only intended for the addressee. Should you=0A= receive this message by mistake, you are hereby notified that=0A= any disclosure, reproduction, distribution or use of this=0A= message is strictly prohibited. Please inform the sender by=0A= reply transmission and delete the message without copying or=0A= opening it.=0A= =0A= Messages and attachments are scanned for all viruses known.=0A= If this message contains password-protected attachments, the=0A= files have NOT been scanned for viruses by the ING mail domain.=0A= Always scan attachments before opening them.=0A= ----------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Oct 5 15:17: 0 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2053C37B40B for ; Sat, 5 Oct 2002 15:16:58 -0700 (PDT) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id 6BD6943E65 for ; Sat, 5 Oct 2002 15:16:57 -0700 (PDT) (envelope-from darcy@wavefire.com) Received: (qmail 24006 invoked from network); 5 Oct 2002 17:09:04 -0000 Received: from dbitech.wavefire.com (HELO dbitech) (darcy@64.141.15.253) by 64.141.13.252 with SMTP; 5 Oct 2002 17:09:04 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Darcy Buskermolen Organization: Wavefire Technologies Corp. To: freebsd-ipfw@FreeBSD.ORG Subject: Re: Policy routing using IPFW for multiple ISP's Date: Sat, 5 Oct 2002 09:50:00 -0700 User-Agent: KMail/1.4.3 References: <20020827215445.GA8419@blossom.cjclark.org> <20020827180538.K34809-100000@skywalker.rogness.net> <20020829194300.GB17576@blossom.cjclark.org> In-Reply-To: <20020829194300.GB17576@blossom.cjclark.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200210050950.00061.darcy@wavefire.com> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > > =09Um, I believe he is running nat on rl0 (his DSL). As the pack= et > > > > =09leaves rl0 it will be assigned the SRC IP of rl0. > > > > > > That's the problem, it won't. When the packet hit the 'fwd' rule ab= ove, > > > it is accepted by the firewall and queued up on rl0. It doesn't > > > continue through or start again through the rules with the new > > > interface. > > > > Did this change? I swear this used to work at one time. > > Either way he can still use: > > > > fwd 199.185.xx.xx tcp from any to 66.25.xx.0/24 80 out recv fxp0 xmi= t > > ed0 > > > > I believe that should work. > > This made me think. I don't think this used to work, but you should be > able to do this now. > > In the past, you could only 'fwd' outgoing packets. That won't work > here since once the packets hit the 'fwd' they are out of the firewall > rules, out the speficied interface, and on the wire before they can > ever be processed by a natd(8) handling packets crossing the other > interface. > > But now that we can use 'fwd' on incoming packets, you should be able > to do this. However, you'd need to change the above rule to, > > fwd 199.185.xx.xx tcp from any to 66.25.xx.0/24 80 in via fxp0 > > Now, the packets are routed out the other interface _AND_ go through > the ipfw(8) rules on that interface. That means that they will go to > the natd(8) watching the other interface. I just tried this nearly exact configuration, and I see packets heading o= ut=20 the external interface with a source address of private IP space=20 wb0 =3D DLS ed0 =3D Cable wb1 =3D Internal net 00101 fwd ip.of.dsl.gateway tcp from any to ip.of.test.host 80 in recv wb= 1 00998 divert 8668 ip from any to any via wb0 00999 divert 8669 ip from any to any via ed0 A tcpdump on wb0 shows the following: 09:44:51.005399 192.168.1.59.4348 > ip.of.test.host.http: S=20 902332116:902332116(0) win 64240 (DF) 09:44:53.919608 192.168.1.49.4348 > ip.of.test.host.http: S=20 902332116:902332116(0) win 64240 (DF) 09:44:59.938801 192.168.1.59.4348 > ip.of.test.host.http: S=20 902332116:902332116(0) win 64240 (DF) natd is properly configured, because if I remove the fwd rule, and just a= pply=20 a: route add ip.of.test.host ip.of.dsl.gateway Packets get sent back and forth as they should (however this way isn't a = poert=20 based routing). Hopfuly this information will help. --=20 Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message