From owner-freebsd-ipfw Sun Jul 28 7:25:39 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 6841F37B400 for ; Sun, 28 Jul 2002 07:25:38 -0700 (PDT) Received: from gs166.sp.cs.cmu.edu (GS166.SP.CS.CMU.EDU [128.2.205.169]) by mx1.FreeBSD.org (Postfix) with SMTP id 033CA43E65 for ; Sun, 28 Jul 2002 07:25:38 -0700 (PDT) (envelope-from dpelleg@gs166.sp.cs.cmu.edu) To: ipfw@freebsd.org Subject: IPFW2 keep-alive From: Dan Pelleg Date: 28 Jul 2002 10:25:25 -0400 In-Reply-To: Message-ID: Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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 What's the exact mechanism to expire dynamic rules under IPFW2? I understand it's sending keep-alive packets as the rule is about to expire. Is there any way for these to result in the rule being removed? The behaviour I'm seeing is this: During a network partition, the application program (Mozilla) retried to connect to remote hosts and opened many connections, eventually hitting the LIMIT count. Now the network is back up. However there is no way to open new connections since the appropriate rule's LIMIT is met. Repeated ipfw -d show that the rules are refreshed when they have 5-6 seconds to live (and go back to 10 seconds or so). I'm not sure what's doing that - the local application is long terminated. The only workaround I found was to flush the ruleset (I guess replacing just that rule would have also worked). -- Dan Pelleg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 6:47:18 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 1110B37B401 for ; Mon, 29 Jul 2002 06:47:12 -0700 (PDT) Received: from relay01.esat.net (relay01.esat.net [192.111.39.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 684FF43E42 for ; Mon, 29 Jul 2002 06:47:10 -0700 (PDT) (envelope-from phil@ipac.ie) Received: from ipac-gw.cr001.ddm.esat.net (mail.rfc-networks.ie) [193.95.188.30] by relay01.esat.net with esmtp id 17ZArd-000248-00; Mon, 29 Jul 2002 14:47:09 +0100 Received: from tear.domain (unknown [10.0.1.254]) by mail.rfc-networks.ie (Postfix) with ESMTP id 628FB54830 for ; Mon, 29 Jul 2002 13:51:14 +0100 (IST) Received: by tear.domain (Postfix, from userid 1000) id F3C772113F; Mon, 29 Jul 2002 14:47:58 +0000 (GMT) Date: Mon, 29 Jul 2002 14:47:58 +0000 From: Philip Reynolds To: freebsd-ipfw@freebsd.org Subject: 4.6-RELEASE / NATD + IPFW + keep-state Message-ID: <20020729144758.A11849@rfc-networks.ie> Reply-To: philip.reynolds@rfc-networks.ie Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 4.6-RC X-URL: http://www.rfc-networks.ie 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, I'm having a few problems with using natd and ipfw. Originally, I was having serious serious problems trying to get stateful firewalling working with NAT. Currently my setup is the following: Public Interface: xl0 Interface address: 10.0.0.1 Subnet mask: 255.255.255.0 Private interface: xl1 Interface Address: 10.0.1.1 Subnet mask: 255.255.255.0 I am doing NAT on anything going out through xl0 from 10.0.1.0/24. However, I want a default DENY policy, with a few stateful rules to allow ssh, http-proxy and smtp (just common examples, I have plenty more contrived wishes once this is up and working). divert 8668 ip from any to any check-state allow ip from 10.0.1.0/24 to 10.0.1.0/24 via xl1 allow tcp from any to not 10.0.1.0/24 22 keep-state setup deny ip from any to any After quite a lot of painful testing, I came up with the above rules. 1. NAT everything going through xl0 (this can be refined later) 2. check the state of the packet. 3. allow stuff through on in inside interface, from a machine on the inside network to another machine on the inside network. 4. allow a setup packet (SYN but no ACK) from machine on inside network to a machine on the outside network (to a port of 22), and keep it's state. 5. Deny everything else This works, but not the way it should, as I'll explain below. Once a connection is made to the machine, ``ipfw -d list'' brings up the following in it's dynamic ruleset. 00100 11 726 (T 19, slot 137) <-> tcp, 10.0.0.56 3245<-> 10.0.0.10 22 00100 33 3958 (T 299, slot 179) <-> tcp, 10.0.1.2 3245<-> 10.0.0.10 22 There are two connections showing and the first is actually a SYN packet, while the second is an ACK. How it's obvious (at least to me) is the value beside the T (i.e. the timeout value). The first, counts down from 20, the second from 300 (the default values of net.inet.ip.fw.dyn_syn_lifetime and net.inet.ip.fw.dyn_ack_lifetime respectively) Basically, in ssh-like connections, this means pumping up net.inet.ip.fw.dyn_ack_lifetime _AND_ net.inet.ip.fw.dyn_syn_lifetime, which I'm a little wary of. Is what's happening OK? Is there a different way I could order/write the ruleset to have some "normal" stateful connections. i.e. Packet comes in on inside interface. Packet matches access rule with keep-state option and gets added to dynamic ruleset Packet NAT'd Packet comes in on outside interface Packet gets NAT'd Packet matches check-state rule If anyone has any light to shed on the subject I would be very grateful. I've spent the last 2 hours or so digging up material (there's not a whole lot) on ipfw/nat/stateful firewalling, searching the archives etc. but nothing that will explain the above behaviour or give me a working alternative. Regards, -- Philip Reynolds | Technical Director philip.reynolds@rfc-networks.ie | RFC Networks Ltd. http://www.rfc-networks.ie | +353 (0)1 8832063 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 7: 6: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 3149237B400 for ; Mon, 29 Jul 2002 07:06:17 -0700 (PDT) Received: from relay04.esat.net (relay04.esat.net [193.95.141.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7132943E42 for ; Mon, 29 Jul 2002 07:06:16 -0700 (PDT) (envelope-from phil@ipac.ie) Received: from ipac-gw.cr001.ddm.esat.net (mail.rfc-networks.ie) [193.95.188.30] by relay04.esat.net with esmtp id 17ZBA7-0002Yg-00; Mon, 29 Jul 2002 15:06:15 +0100 Received: from tear.domain (unknown [10.0.1.254]) by mail.rfc-networks.ie (Postfix) with ESMTP id B9B1854834 for ; Mon, 29 Jul 2002 14:10:20 +0100 (IST) Received: by tear.domain (Postfix, from userid 1000) id 82FFB2113F; Mon, 29 Jul 2002 15:07:05 +0000 (GMT) Date: Mon, 29 Jul 2002 15:07:05 +0000 From: Philip Reynolds To: freebsd-ipfw@freebsd.org Subject: Re: 4.6-RELEASE / NATD + IPFW + keep-state Message-ID: <20020729150705.A13050@rfc-networks.ie> Reply-To: philip.reynolds@rfc-networks.ie References: <20020729144758.A11849@rfc-networks.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020729144758.A11849@rfc-networks.ie>; from philip.reynolds@rfc-networks.ie on Mon, Jul 29, 2002 at 02:47:58PM +0000 X-Operating-System: FreeBSD 4.6-RC X-URL: http://www.rfc-networks.ie 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 Philip Reynolds 91 lines of wisdom included: > Once a connection is made to the machine, ``ipfw -d list'' brings up > the following in it's dynamic ruleset. > > 00100 11 726 (T 19, slot 137) <-> tcp, 10.0.0.56 3245<-> 10.0.0.10 > 22 > 00100 33 3958 (T 299, slot 179) <-> tcp, 10.0.1.2 3245<-> 10.0.0.10 > 22 These lines are of course 00100 11 726 (T 19, slot 137) <-> tcp, 10.0.0.1 3245<-> 10.0.0.10 22 00100 33 3958 (T 299, slot 179) <-> tcp, 10.0.1.2 3245<-> 10.0.0.10 22 The connection is being made from 10.0.1.2 to 10.0.0.10 Once the first connection (i.e. the lower timeout value, the SYN connection) drops, my whole connection drops. Apologies. Phil. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 9:57:21 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 9728C37B400 for ; Mon, 29 Jul 2002 09:57:19 -0700 (PDT) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id E704E43E3B for ; Mon, 29 Jul 2002 09:57:18 -0700 (PDT) (envelope-from m@devzerog.com) Received: from devzerog.com ([80.4.0.140]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020729165717.GOJV5047.mta06-svc.ntlworld.com@devzerog.com> for ; Mon, 29 Jul 2002 17:57:17 +0100 Message-ID: <3D45740A.2000704@devzerog.com> Date: Mon, 29 Jul 2002 17:57:46 +0100 From: Mike Dewhirst User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: divert a port to another ip 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 Hi, If I want to divert all requests on a certain port to another ip address and another port, e.g. 80.0.0.123:666 --> 192.10.10.5:22 what would be the rule? I thought: divert 8668 tcp from any 666 to 192.10.10.5 22 via xl0 8668 is the natd port (I think) - I have this rule that works: divert 8668 ip from any to any via xl1 But it doesn't seem to work. Any ideas? Also, what is a good online resource for ipfw? Thanks for any advice in advance! Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 11:34: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 D0F0637B400 for ; Mon, 29 Jul 2002 11:34:07 -0700 (PDT) Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15DA643E67 for ; Mon, 29 Jul 2002 11:34:07 -0700 (PDT) (envelope-from m@devzerog.com) Received: from devzerog.com ([80.4.0.140]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020729183405.BSAD23840.mta03-svc.ntlworld.com@devzerog.com>; Mon, 29 Jul 2002 19:34:05 +0100 Message-ID: <3D458ABA.4090309@devzerog.com> Date: Mon, 29 Jul 2002 19:34:34 +0100 From: Mike Dewhirst User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chad Ziccardi Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: fwd (was divert a port to another ip References: <20020729141909.F12318-100000@digitalfreaks.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 Chad, Thanks for the advice. It didn't quite work though. :( What am I doing wrong: # ipfw add 4 fwd 192.10.10.4,22 tcp from any to 80.x.x.x 666 via xl0 ipfw: getsockopt(IP_FW_ADD): Invalid argument Running FreeBSD 4.4 How do I find out what version of FreeBSD I'm running? Thanks in advance, Mike Chad Ziccardi wrote: > begin quote from Mike Dewhirst written 2002-07-29: > > >>Hi, >> >>If I want to divert all requests on a certain port to another ip address >>and another port, e.g. >> >>80.0.0.123:666 --> 192.10.10.5:22 >> >>what would be the rule? I thought: >> >>divert 8668 tcp from any 666 to 192.10.10.5 22 via xl0 >> >>8668 is the natd port (I think) - I have this rule that works: >>divert 8668 ip from any to any via xl1 >> >>But it doesn't seem to work. Any ideas? >> >>Also, what is a good online resource for ipfw? >> >>Thanks for any advice in advance! > > > You'll need the option IP_FORWARD I believe > > fwd 216.151.80.60,7300 tcp from any to 216.151.80.60 80 via xl0 > > fwd dest ip, dest port, from any, incoming ip, incoming port > > so a hit to 216.151.80.60 port 80 would be rewritten to goto port 7300. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 11:42:46 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 9AFBF37B400 for ; Mon, 29 Jul 2002 11:42:43 -0700 (PDT) Received: from relay03.esat.net (relay03.esat.net [193.95.141.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0058743E31 for ; Mon, 29 Jul 2002 11:42:43 -0700 (PDT) (envelope-from phil@ipac.ie) Received: from ipac-gw.cr001.ddm.esat.net (mail.rfc-networks.ie) [193.95.188.30] by relay03.esat.net with esmtp id 17ZFTd-0004Tu-00; Mon, 29 Jul 2002 19:42:41 +0100 Received: from tear.domain (unknown [10.0.1.254]) by mail.rfc-networks.ie (Postfix) with ESMTP id E6BE454834 for ; Mon, 29 Jul 2002 18:46:46 +0100 (IST) Received: by tear.domain (Postfix, from userid 1000) id C4EFF2113F; Mon, 29 Jul 2002 19:43:31 +0000 (GMT) Date: Mon, 29 Jul 2002 19:43:31 +0000 From: Philip Reynolds To: freebsd-ipfw@freebsd.org Subject: Re: divert a port to another ip Message-ID: <20020729194331.A14733@rfc-networks.ie> Reply-To: philip.reynolds@rfc-networks.ie References: <3D45740A.2000704@devzerog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D45740A.2000704@devzerog.com>; from m@devzerog.com on Mon, Jul 29, 2002 at 05:57:46PM +0100 X-Operating-System: FreeBSD 4.6-RC X-URL: http://www.rfc-networks.ie 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 Mike, Mike Dewhirst 25 lines of wisdom included: > Hi, > > If I want to divert all requests on a certain port to another ip address > and another port, e.g. > > 80.0.0.123:666 --> 192.10.10.5:22 > > what would be the rule? I thought: > > divert 8668 tcp from any 666 to 192.10.10.5 22 via xl0 Divert 8668 is using NAT (Network Address Translation). Do you actually want to forward all requests to another IP and port or do you want to do NAT? If you're looking to blindly forward, look at the ``fwd'' part of ipfw(8) (man 8 ipfw) For this, on 4.6-RELEASE anyways, it expects that options IPFIREWALL_FORWARD is in your kernel. If it's not you're going to have to do a kernel recompile. http://tardis.redbrick.dcu.ie/87 > 8668 is the natd port (I think) - I have this rule that works: > divert 8668 ip from any to any via xl1 > > But it doesn't seem to work. Any ideas? > > Also, what is a good online resource for ipfw? http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO -- Philip Reynolds | Technical Director philip.reynolds@rfc-networks.ie | RFC Networks Ltd. http://www.rfc-networks.ie | +353 (0)1 8832063 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 11:51:38 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 BC14037B400 for ; Mon, 29 Jul 2002 11:51:34 -0700 (PDT) Received: from digitalfreaks.org (digitalfreaks.org [216.151.95.156]) by mx1.FreeBSD.org (Postfix) with SMTP id 2E07D43E4A for ; Mon, 29 Jul 2002 11:51:34 -0700 (PDT) (envelope-from ziccardi@digitalfreaks.org) Received: (qmail 14942 invoked by uid 1000); 29 Jul 2002 18:51:28 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Jul 2002 18:51:28 -0000 Date: Mon, 29 Jul 2002 14:51:28 -0400 (EDT) From: Chad Ziccardi To: Mike Dewhirst Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: fwd (was divert a port to another ip In-Reply-To: <3D458ABA.4090309@devzerog.com> Message-ID: <20020729144713.R14599-100000@digitalfreaks.org> 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 begin quote from Mike Dewhirst written 2002-07-29: Mike, Here's the line I'm using, I remember seeing issues if you don't have the forward option (IPFIREWALL_FORWARD) enabled in the kernel. ipfw add 30000 fwd 216.151.80.60,17337 tcp from any to 216.151.80.60 80 viaxl0 uname -a will tell you some more info about your freebsd version/kernel. [ziccardi@:~]$ uname -a FreeBSD digitalfreaks.org 4.6-STABLE FreeBSD 4.6-STABLE #5: Sat Jul 13 15:12:00 EDT 2002 root@digitalfreaks.org:/usr/obj/usr/src/sys/DIGITALFREAKS i386 Refs:: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html http://renaud.waldura.com/doc/freebsd/firewall/ http://www.acme.com/firewall.html > Chad, > > Thanks for the advice. It didn't quite work though. :( > > What am I doing wrong: > > # ipfw add 4 fwd 192.10.10.4,22 tcp from any to 80.x.x.x 666 via xl0 > ipfw: getsockopt(IP_FW_ADD): Invalid argument > > Running FreeBSD 4.4 > > How do I find out what version of FreeBSD I'm running? > > Thanks in advance, > > Mike > > > Chad Ziccardi wrote: > > begin quote from Mike Dewhirst written 2002-07-29: > > > > > >>Hi, > >> > >>If I want to divert all requests on a certain port to another ip address > >>and another port, e.g. > >> > >>80.0.0.123:666 --> 192.10.10.5:22 > >> > >>what would be the rule? I thought: > >> > >>divert 8668 tcp from any 666 to 192.10.10.5 22 via xl0 > >> > >>8668 is the natd port (I think) - I have this rule that works: > >>divert 8668 ip from any to any via xl1 > >> > >>But it doesn't seem to work. Any ideas? > >> > >>Also, what is a good online resource for ipfw? > >> > >>Thanks for any advice in advance! > > > > > > You'll need the option IP_FORWARD I believe > > > > fwd 216.151.80.60,7300 tcp from any to 216.151.80.60 80 via xl0 > > > > fwd dest ip, dest port, from any, incoming ip, incoming port > > > > so a hit to 216.151.80.60 port 80 would be rewritten to goto port 7300. > > > > > > > > > > > > > > > -- Chad Ziccardi, Professional Slacker cz@digitalfreaks.org "Some cause happiness wherever they go; others whenever they go." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 12: 2:17 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 72CE037B400 for ; Mon, 29 Jul 2002 12:02:15 -0700 (PDT) Received: from samuelstn.dyndns.org (h24-64-81-248.cg.shawcable.net [24.64.81.248]) by mx1.FreeBSD.org (Postfix) with SMTP id 21C1843E70 for ; Mon, 29 Jul 2002 12:02:13 -0700 (PDT) (envelope-from cyschow@shaw.ca) Received: (qmail 63426 invoked from network); 29 Jul 2002 19:02:11 -0000 Received: from firewall (HELO SAMCHOW1.ca.nortel.com) (192.168.1.1) by homeserver with SMTP; 29 Jul 2002 19:02:11 -0000 Message-ID: <003901c23732$b53c0fe0$2784412f@ca.nortel.com> From: "Samuel Chow" To: "Mike Dewhirst" Cc: References: <20020729141909.F12318-100000@digitalfreaks.org> <3D458ABA.4090309@devzerog.com> Subject: Re: fwd (was divert a port to another ip Date: Mon, 29 Jul 2002 13:04:04 -0600 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 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 ----- Original Message ----- From: "Mike Dewhirst" > > What am I doing wrong: > > # ipfw add 4 fwd 192.10.10.4,22 tcp from any to 80.x.x.x 666 via xl0 > ipfw: getsockopt(IP_FW_ADD): Invalid argument You need IPFIREWALL_FORWARD option in your kernel. --- Samuel Chow cyschow@shaw.ca This message is displayed using recycled electrons. Segmentation Fault (core dumped) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 13: 8: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 19DF537B401 for ; Mon, 29 Jul 2002 13:08:56 -0700 (PDT) Received: from chello.barmentlo.net (a124038.upc-a.chello.nl [62.163.124.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51A4F43E42 for ; Mon, 29 Jul 2002 13:08:54 -0700 (PDT) (envelope-from patrick@barmentlo.nl) Received: from gateway.barmentlo.net (gateway [10.0.0.1]) by chello.barmentlo.net (8.12.5/8.12.3) with ESMTP id g6TK7lmi089312; Mon, 29 Jul 2002 22:07:47 +0200 (CEST) (envelope-from patrick@barmentlo.nl) Received: from localhost (pbm@localhost) by gateway.barmentlo.net (8.12.5/8.12.3/Submit) with ESMTP id g6TK7gKD089309; Mon, 29 Jul 2002 22:07:46 +0200 (CEST) (envelope-from patrick@barmentlo.nl) X-Authentication-Warning: gateway.barmentlo.net: pbm owned process doing -bs Date: Mon, 29 Jul 2002 22:07:42 +0200 (CEST) From: patrick X-X-Sender: pbm@gateway.barmentlo.net To: Mike Dewhirst Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: divert a port to another ip In-Reply-To: <3D45740A.2000704@devzerog.com> Message-ID: <20020729220304.K88943-100000@gateway.barmentlo.net> 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 On Mon, 29 Jul 2002, Mike Dewhirst wrote: > If I want to divert all requests on a certain port to another ip address > and another port, e.g. > > 80.0.0.123:666 --> 192.10.10.5:22 > I have this rule that works: > divert 8668 ip from any to any via xl1 you should extend this command with -redirect_port tcp x.x.x.x:666 x.x.x.x:22 if you need more, just extend the command again. you will see the rules back with the ipfw show command next to your 'regular' divert rule. check man natd, you can use a config file in order to prevent your command to become really long. grtz patrick -- Patrick Barmentlo - Unix System Administrator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 15:32: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 8123737B400 for ; Mon, 29 Jul 2002 15:32:17 -0700 (PDT) Received: from xy.blank.spb.ru (xy.blank.spb.ru [194.67.6.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 668EB43E31 for ; Mon, 29 Jul 2002 15:32:16 -0700 (PDT) (envelope-from borman@blank.spb.ru) Received: from xy.blank.spb.ru (localhost.blank.spb.ru [127.0.0.1]) by xy.blank.spb.ru (8.12.3/8.12.3/blank) with ESMTP id g6TMWEKj001830; Tue, 30 Jul 2002 02:32:14 +0400 (MSD) (envelope-from borman@xy.blank.spb.ru) Received: (from borman@localhost) by xy.blank.spb.ru (8.12.3/8.12.3/Submit) id g6TMWEeF001829; Tue, 30 Jul 2002 02:32:14 +0400 (MSD) Date: Tue, 30 Jul 2002 02:32:14 +0400 From: boris karlov To: Philip Reynolds Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: 4.6-RELEASE / NATD + IPFW + keep-state Message-ID: <20020729223214.GB1488@xy.blank.spb.ru> Mail-Followup-To: Philip Reynolds , freebsd-ipfw@FreeBSD.ORG References: <20020729144758.A11849@rfc-networks.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20020729144758.A11849@rfc-networks.ie> 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 On Mon, 29 Jul 2002 14:47:58 +0000, Philip Reynolds wrote: > > divert 8668 ip from any to any -- mb, divert 8668 ip from any to any via xl0? > check-state > allow ip from 10.0.1.0/24 to 10.0.1.0/24 via xl1 > allow tcp from any to not 10.0.1.0/24 22 keep-state setup > deny ip from any to any > > Once a connection is made to the machine, ``ipfw -d list'' brings up > the following in it's dynamic ruleset. > > 00100 11 726 (T 19, slot 137) <-> tcp, 10.0.0.1 3245<-> 10.0.0.10 22 > 00100 33 3958 (T 299, slot 179) <-> tcp, 10.0.1.2 3245<-> 10.0.0.10 22 -- IMHO: these packets are processed twice by ipfw(8) as for packets routed by the host (acting as a gateway) (see ipfw(8), `IMPLEMENTATION NOTES' section). you should alias only outgoing packets before next hop forwarding but not incoming ones after reception on an IP interface (see divert(4), `READING PACKETS' section). > > > Is what's happening OK? Is there a different way I could order/write > the ruleset to have some "normal" stateful connections. > i.e. > > Packet comes in on inside interface. > Packet matches access rule with keep-state option and gets added to > dynamic ruleset > Packet NAT'd -- it seems you forgot `Packet comes out from outside interface and gets NATed too' here. > > Packet comes in on outside interface > Packet gets NAT'd > Packet matches check-state rule > regards, boris karlov. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 16:19:12 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 87F7337B400 for ; Mon, 29 Jul 2002 16:19:09 -0700 (PDT) Received: from relay01.esat.net (relay01.esat.net [192.111.39.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7972643E42 for ; Mon, 29 Jul 2002 16:19:08 -0700 (PDT) (envelope-from phil@ipac.ie) Received: from ipac-gw.cr001.ddm.esat.net (mail.rfc-networks.ie) [193.95.188.30] by relay01.esat.net with esmtp id 17ZJn8-00008q-00; Tue, 30 Jul 2002 00:19:06 +0100 Received: from tear.domain (unknown [10.0.1.254]) by mail.rfc-networks.ie (Postfix) with ESMTP id 95F3954834 for ; Mon, 29 Jul 2002 23:23:11 +0100 (IST) Received: by tear.domain (Postfix, from userid 1000) id 5694A2113F; Tue, 30 Jul 2002 00:19:56 +0000 (GMT) Date: Tue, 30 Jul 2002 00:19:56 +0000 From: Philip Reynolds To: freebsd-ipfw@freebsd.org Subject: Re: 4.6-RELEASE / NATD + IPFW + keep-state Message-ID: <20020730001956.A15831@rfc-networks.ie> Reply-To: philip.reynolds@rfc-networks.ie References: <20020729144758.A11849@rfc-networks.ie> <20020729223214.GB1488@xy.blank.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020729223214.GB1488@xy.blank.spb.ru>; from borman@blank.spb.ru on Tue, Jul 30, 2002 at 02:32:14AM +0400 X-Operating-System: FreeBSD 4.6-RC X-URL: http://www.rfc-networks.ie 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 boris karlov 48 lines of wisdom included: > On Mon, 29 Jul 2002 14:47:58 +0000, Philip Reynolds wrote: > > > > divert 8668 ip from any to any > > -- mb, divert 8668 ip from any to any via xl0? This is actually what I have (unfortunately messing around with my rules etc. caused me to paste not quite the exact ruleset I started out with). The still works as I documented in my previous mail, with ``ipfw -d list'' bring up two connections. > -- IMHO: these packets are processed twice by ipfw(8) as for packets > routed by the host (acting as a gateway) (see ipfw(8), `IMPLEMENTATION NOTES' > section). you should alias only outgoing packets before next hop forwarding > but not incoming ones after reception on an IP interface (see divert(4), > `READING PACKETS' section). I'm not too clear on what you mean by "alias", I can only presume you mean translations via NAT, in which case I'm not sure where you're coming from? (i.e. NAT needs to be done on incoming and outgoing packets on the public interface). > > Packet comes in on inside interface. > > Packet matches access rule with keep-state option and gets added to > > dynamic ruleset > > Packet NAT'd > > -- it seems you forgot `Packet comes out from outside interface and gets > NATed too' here. That's what I meant by the last line. Unfortunately I didn't specify the ``via xl0'' in my original ruleset for the divert line, however I can assure you, the behaviour is consistent with this in. What I'm curious about is the connection which is showing up in ``ipfw -d list'', which is timing out according to "net.inet.ip.fw.dyn_syn_lifetime:". Unfortunately nothing you've suggested seems to have worked (unless I've missed something?), although thankyou for your suggestions. Perhaps this mail may shed some more light on the issue. Phil. -- Philip Reynolds | Technical Director philip.reynolds@rfc-networks.ie | RFC Networks Ltd. http://www.rfc-networks.ie | +353 (0)1 8832063 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 22:25: 2 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 B802A37B400 for ; Mon, 29 Jul 2002 22:24:58 -0700 (PDT) Received: from xy.blank.spb.ru (xy.blank.spb.ru [194.67.6.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D1F943E67 for ; Mon, 29 Jul 2002 22:24:57 -0700 (PDT) (envelope-from borman@blank.spb.ru) Received: from xy.blank.spb.ru (localhost.blank.spb.ru [127.0.0.1]) by xy.blank.spb.ru (8.12.3/8.12.3/blank) with ESMTP id g6U5OuKj002782 for ; Tue, 30 Jul 2002 09:24:56 +0400 (MSD) (envelope-from borman@xy.blank.spb.ru) Received: (from borman@localhost) by xy.blank.spb.ru (8.12.3/8.12.3/Submit) id g6U5OtkN002781 for freebsd-ipfw@FreeBSD.ORG; Tue, 30 Jul 2002 09:24:55 +0400 (MSD) Date: Tue, 30 Jul 2002 09:24:55 +0400 From: boris karlov To: freebsd-ipfw@FreeBSD.ORG Subject: Re: 4.6-RELEASE / NATD + IPFW + keep-state Message-ID: <20020730052455.GA2719@xy.blank.spb.ru> Mail-Followup-To: freebsd-ipfw@FreeBSD.ORG References: <20020729144758.A11849@rfc-networks.ie> <20020729223214.GB1488@xy.blank.spb.ru> <20020730001956.A15831@rfc-networks.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20020730001956.A15831@rfc-networks.ie> 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 On Tue, 30 Jul 2002 00:19:56 +0000, Philip Reynolds wrote: > boris karlov 48 lines of wisdom included: > > On Mon, 29 Jul 2002 14:47:58 +0000, Philip Reynolds wrote: > > > > > > divert 8668 ip from any to any > > > > -- mb, divert 8668 ip from any to any via xl0? > > This is actually what I have (unfortunately messing around with my > rules etc. caused me to paste not quite the exact ruleset I started > out with). -- in this case all my previous words are useless ;-) > > The still works as I documented in my previous mail, with ``ipfw -d > list'' bring up two connections. > > > What I'm curious about is the connection which is showing up in > ``ipfw -d list'', which is timing out according to > "net.inet.ip.fw.dyn_syn_lifetime:". -- since it's unclear at all for me I suppose to audit connections with tcpdump (both ifaces), turn on ipfw logging (almost all rules) and verbose natd. too much logs to check but may be you can find an answer. -- regards, boris karlov. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 22:33:40 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 47BCB37B400 for ; Mon, 29 Jul 2002 22:33:38 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id C74FD43E67 for ; Mon, 29 Jul 2002 22:33:37 -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 <20020730053337.QDHI24567.rwcrmhc51.attbi.com@blossom.cjclark.org>; Tue, 30 Jul 2002 05:33:37 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g6U5XaJK089525; Mon, 29 Jul 2002 22:33:36 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g6U5XXEp089524; Mon, 29 Jul 2002 22:33:33 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Mon, 29 Jul 2002 22:33:33 -0700 From: "Crist J. Clark" To: Naga Suresh B Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: problem with portforwarding Message-ID: <20020730053333.GA89241@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <004d01c232d3$352683c0$9600a8c0@blraddrcom> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004d01c232d3$352683c0$9600a8c0@blraddrcom> 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 [-security snipped, this has nothing to do with -security. It is probably better for -questions than -ipfw too, but I'll not change that.] On Wed, Jul 24, 2002 at 11:00:20AM +0530, Naga Suresh B wrote: > Hai, > > We are facing a problem in configuring the portforwarding on > our gateway. We are having a gateway with two network cards one with > external ip(xxx.xxx.xxx.170) and another one with internal > ip(192.168.0.200). We Created an alias ip for another external > ip(xxx.xxx.xxx.172) and we had done portforwarding 443 to another internal > ip (192.168.0.203) on another fbsd machine. We added the following line in > the natd.conf on 192.168.0.200 > redirect_port tcp 192.168.0.203:443 xxx.xxx.xxx.172:443 > redirect_port tcp 192.168.0.203:22 xxx.xxx.xxx.172:22 > We are running ipfw on the 192.168.0.200. We are running httpd on both the > machines. After doing portforwarding when we are trying to access the > application from outside xxx.xxx.xxx.172 is working fine. But we are not > able to access the application on 172 from inside with public ip and we are > able to access the application with 192.168.0.203. Also the name does not > resolve for the IP xxx.xxx.xxx.172 from the internal network where as the > same thing happens from outside. How do we solve this? Please Give the > solution as early as possible and plz help us. This is a FAQ, http://docs.freebsd.org/cgi/getmsg.cgi?fetch=0+0+archive/2002/freebsd-questions/20020224.freebsd-questions There are a number of ways to solve this. The two most common are two invoke another natd(8) on the internal interface or to properly configure DNS to resolve to different IPs for the same hostname depending on which network the query comes. Your DNS issue is completely separate and has nothing to do with NAT. -- 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 Mon Jul 29 22:43:46 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 50C8137B400 for ; Mon, 29 Jul 2002 22:43:43 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id D82AB43E5E for ; Mon, 29 Jul 2002 22:43:42 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020730054342.QVML22139.rwcrmhc52.attbi.com@blossom.cjclark.org>; Tue, 30 Jul 2002 05:43:42 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g6U5hfJK089603; Mon, 29 Jul 2002 22:43:42 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g6U5hf1n089602; Mon, 29 Jul 2002 22:43:41 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Mon, 29 Jul 2002 22:43:40 -0700 From: "Crist J. Clark" To: Luigi Rizzo Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: ipfw behaviour with non IPv4 packets Message-ID: <20020730054340.GB89241@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <20020725001652.A94913@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020725001652.A94913@iguana.icir.org> 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 Thu, Jul 25, 2002 at 12:16:52AM -0700, Luigi Rizzo wrote: > Hi, > I would like your input here on the following issue. > > > The original "ipfw" would only see IPv4 packets, so given a rule > of the form > > ip from to > > the "ip" protocol specifier effectively meant "any packet" (and > "any" is in fact a synonym for "ip"). > > IPFW2 also sees non-ipv4 packets, so in some cases (e.g. when no > other fields refer to IPv4 information, say "ip from any to any") > the rule can be ambiguous. As a matter of fact, the way I have > implemented it now is > > "ip" = "any" --> any packet, ipv4 or not > > You can have the same ambiguity when you specify a protocol like > "tcp" or "udp" -- do you want these rules to match only "*-over-ip4" > or ipv6 as well ? > > I am a bit uncertain on what is the best path, but i believe a > reasonable one is to assume > > "ip" = "any" --> any IP packet (v4 or v6) > > and similarly > > "proto" --> any packet of protocol "proto" over IP (v4 or v6) > > Comments ? What happens when you do, pass ip from any to any ipoptions blah,blah... Or some other field that is inconsistent for both IPv4 and IPv6? Or more simply can you do, pass ip from 192.168.0.1 to any And, pass ip from fe80::203:0405:0607:0809 to any And, pass ip from 192.168.0.1 or fe80::203:0405:0607:0809 to any And ipfw(8) will "do the right thing?" (Whatever that might be?) -- 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 Mon Jul 29 22:48:55 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 CA68237B400; Mon, 29 Jul 2002 22:48:52 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 596A443E65; Mon, 29 Jul 2002 22:48:52 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g6U5mqQ49174; Mon, 29 Jul 2002 22:48:52 -0700 (PDT) (envelope-from rizzo) Date: Mon, 29 Jul 2002 22:48:52 -0700 From: Luigi Rizzo To: "Crist J. Clark" Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: ipfw behaviour with non IPv4 packets Message-ID: <20020729224852.A49134@iguana.icir.org> References: <20020725001652.A94913@iguana.icir.org> <20020730054340.GB89241@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: <20020730054340.GB89241@blossom.cjclark.org>; from crist.clark@attbi.com on Mon, Jul 29, 2002 at 10:43:40PM -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 when you pass inconsistent options the rule will never match -- now a more sophisticated user interface might detect that and prevent such a rule from being entered, but this is not a major issue. cheers luigi On Mon, Jul 29, 2002 at 10:43:40PM -0700, Crist J. Clark wrote: ... > What happens when you do, > > pass ip from any to any ipoptions blah,blah... > > Or some other field that is inconsistent for both IPv4 and IPv6? > > Or more simply can you do, > > pass ip from 192.168.0.1 to any > > And, > > pass ip from fe80::203:0405:0607:0809 to any > > And, > > pass ip from 192.168.0.1 or fe80::203:0405:0607:0809 to any > > And ipfw(8) will "do the right thing?" (Whatever that might be?) > -- > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Jul 29 22:52: 8 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 2DB2737B400 for ; Mon, 29 Jul 2002 22:52:06 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59C3943E65 for ; Mon, 29 Jul 2002 22:52:05 -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 <20020730055204.QRDS24567.rwcrmhc51.attbi.com@blossom.cjclark.org>; Tue, 30 Jul 2002 05:52:04 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g6U5q4JK089637; Mon, 29 Jul 2002 22:52:04 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g6U5q2hJ089636; Mon, 29 Jul 2002 22:52:02 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Mon, 29 Jul 2002 22:52:02 -0700 From: "Crist J. Clark" To: Mike Dewhirst Cc: Chad Ziccardi , freebsd-ipfw@FreeBSD.org Subject: Re: fwd (was divert a port to another ip Message-ID: <20020730055202.GC89241@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <20020729141909.F12318-100000@digitalfreaks.org> <3D458ABA.4090309@devzerog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D458ABA.4090309@devzerog.com> 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, Jul 29, 2002 at 07:34:34PM +0100, Mike Dewhirst wrote: > Chad, > > Thanks for the advice. It didn't quite work though. :( > > What am I doing wrong: > > # ipfw add 4 fwd 192.10.10.4,22 tcp from any to 80.x.x.x 666 via xl0 > ipfw: getsockopt(IP_FW_ADD): Invalid argument > > Running FreeBSD 4.4 > > How do I find out what version of FreeBSD I'm running? Please read, http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/networking.html#IPFW-FWD Before you work to hard on this. -- 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 Mon Jul 29 22:57: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 D84F237B400 for ; Mon, 29 Jul 2002 22:57:24 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6595943E42 for ; Mon, 29 Jul 2002 22:57:24 -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 <20020730055724.QVCA24567.rwcrmhc51.attbi.com@blossom.cjclark.org>; Tue, 30 Jul 2002 05:57:24 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g6U5vNJK089654; Mon, 29 Jul 2002 22:57:23 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g6U5vNhe089653; Mon, 29 Jul 2002 22:57:23 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Mon, 29 Jul 2002 22:57:22 -0700 From: "Crist J. Clark" To: Philip Reynolds Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: 4.6-RELEASE / NATD + IPFW + keep-state Message-ID: <20020730055722.GD89241@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <20020729144758.A11849@rfc-networks.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020729144758.A11849@rfc-networks.ie> 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, Jul 29, 2002 at 02:47:58PM +0000, Philip Reynolds wrote: > Hi, > > I'm having a few problems with using natd and ipfw. > > Originally, I was having serious serious problems trying to get > stateful firewalling working with NAT. This is a FAQ, http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13412+0+archive/2002/freebsd-net/20020217.freebsd-net -- 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 Jul 30 2:41:43 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 42BCD37B400 for ; Tue, 30 Jul 2002 02:41:42 -0700 (PDT) Received: from xy.blank.spb.ru (xy.blank.spb.ru [194.67.6.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A65043E42 for ; Tue, 30 Jul 2002 02:41:41 -0700 (PDT) (envelope-from borman@blank.spb.ru) Received: from xy.blank.spb.ru (localhost.blank.spb.ru [127.0.0.1]) by xy.blank.spb.ru (8.12.5/8.12.5/blank) with ESMTP id g6U9fdTi001738 for ; Tue, 30 Jul 2002 13:41:39 +0400 (MSD) (envelope-from borman@xy.blank.spb.ru) Received: (from borman@localhost) by xy.blank.spb.ru (8.12.5/8.12.5/Submit) id g6U9fd0K001737 for freebsd-ipfw@FreeBSD.ORG; Tue, 30 Jul 2002 13:41:39 +0400 (MSD) Date: Tue, 30 Jul 2002 13:41:39 +0400 From: boris karlov To: freebsd-ipfw@FreeBSD.ORG Subject: Re: 4.6-RELEASE / NATD + IPFW + keep-state Message-ID: <20020730094139.GA1606@xy.blank.spb.ru> Mail-Followup-To: freebsd-ipfw@FreeBSD.ORG References: <20020729144758.A11849@rfc-networks.ie> <20020730055722.GD89241@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20020730055722.GD89241@blossom.cjclark.org> 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 On Mon, 29 Jul 2002 22:57:22 -0700, "Crist J. Clark" wrote: > On Mon, Jul 29, 2002 at 02:47:58PM +0000, Philip Reynolds wrote: > > Hi, > > > > I'm having a few problems with using natd and ipfw. > > > > Originally, I was having serious serious problems trying to get > > stateful firewalling working with NAT. > > This is a FAQ, > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13412+0+archive/2002/freebsd-net/20020217.freebsd-net > -- all the same it's a `twice processing' issue, AFAIU. suggestions: playing with in/out iface-specifiers and/or `skipto' for `divert'/`keep-state' rules. -- regards, boris karlov. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 30 5:32: 1 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 C2D1237B400 for ; Tue, 30 Jul 2002 05:31:58 -0700 (PDT) Received: from relay04.esat.net (relay04.esat.net [193.95.141.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24BF243E31 for ; Tue, 30 Jul 2002 05:31:58 -0700 (PDT) (envelope-from phil@ipac.ie) Received: from ipac-gw.cr001.ddm.esat.net (mail.rfc-networks.ie) [193.95.188.30] by relay04.esat.net with esmtp id 17ZWAO-0000B7-00; Tue, 30 Jul 2002 13:31:57 +0100 Received: from tear.domain (unknown [10.0.1.254]) by mail.rfc-networks.ie (Postfix) with ESMTP id 1E63F54834 for ; Tue, 30 Jul 2002 12:36:01 +0100 (IST) Received: by tear.domain (Postfix, from userid 1000) id 1A44C2113F; Tue, 30 Jul 2002 13:32:46 +0000 (GMT) Date: Tue, 30 Jul 2002 13:32:46 +0000 From: Philip Reynolds To: freebsd-ipfw@freebsd.org Subject: Re: 4.6-RELEASE / NATD + IPFW + keep-state Message-ID: <20020730133246.A18016@rfc-networks.ie> Reply-To: philip.reynolds@rfc-networks.ie References: <20020729144758.A11849@rfc-networks.ie> <20020730055722.GD89241@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020730055722.GD89241@blossom.cjclark.org>; from crist.clark@attbi.com on Mon, Jul 29, 2002 at 10:57:22PM -0700 X-Operating-System: FreeBSD 4.6-RC X-URL: http://www.rfc-networks.ie 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" 19 lines of wisdom included: > On Mon, Jul 29, 2002 at 02:47:58PM +0000, Philip Reynolds wrote: > > Hi, > > > > I'm having a few problems with using natd and ipfw. > > > > Originally, I was having serious serious problems trying to get > > stateful firewalling working with NAT. > > This is a FAQ, > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13412+0+archive/2002/freebsd-net/20020217.freebsd-net using ``via'' helped along the way and the setup is currently working. What was needed was a specification of the public interface _only_ for the ``NATD'' rule in conjunction with a specification of the private interface _only_ for the ``keep-state'' rule. Unfortunately tweaking my rules before, I must have missed this combination, although I'm not sure how. Thanks for to Crist and Boris for their help. Regards, -- Philip Reynolds | Technical Director philip.reynolds@rfc-networks.ie | RFC Networks Ltd. http://www.rfc-networks.ie | +353 (0)1 8832063 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 30 5:57:13 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 5348E37B408 for ; Tue, 30 Jul 2002 05:57:04 -0700 (PDT) Received: from mail.wsf.at (MAIL.WSF.AT [212.16.37.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3641743E42 for ; Tue, 30 Jul 2002 05:57:03 -0700 (PDT) (envelope-from net@wsf.at) Received: (from root@localhost) by mail.wsf.at (8.11.6/8.9.3) id g6UCuxP08757 for freebsd-ipfw@FreeBSD.ORG.KAV; Tue, 30 Jul 2002 14:56:59 +0200 (CEST) (envelope-from net@wsf.at) Received: from wsf.at (localhost [127.0.0.1]) by www.wsf.at (8.11.6/8.9.3) with SMTP id g6UCuwY08741; Tue, 30 Jul 2002 14:56:58 +0200 (CEST) (envelope-from net@wsf.at) Message-Id: <200207301256.g6UCuwY08741@www.wsf.at> Date: Tue, 30 Jul 2002 12:56:58 -0000 To: , Subject: Re: 4.6-RELEASE / NATD + IPFW + keep-state From: X-Mailer: TWIG 2.6.2 In-Reply-To: <20020730133246.A18016@rfc-networks.ie> 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 Philip Reynolds schrieb: > "Crist J. Clark" 19 lines of wisdom included: > > On Mon, Jul 29, 2002 at 02:47:58PM +0000, Philip Reynolds wrote: > > > Hi, > > > > > > I'm having a few problems with using natd and ipfw. > > > > > > Originally, I was having serious serious problems trying to get > > > stateful firewalling working with NAT. > > > > This is a FAQ, > > > > http://docs.freebsd.org/cgi/getmsg.cgi? fetch=13412+0+archive/2002/freebsd-net/20020217.freebsd-net > > using ``via'' helped along the way and the setup is currently > working. > > What was needed was a specification of the public interface _only_ > for the ``NATD'' rule in conjunction with a specification of the > private interface _only_ for the ``keep-state'' rule. > > Unfortunately tweaking my rules before, I must have missed this > combination, although I'm not sure how. > > Thanks for to Crist and Boris for their help. > Hi Philip, Could you send your working ruleset to the list ? It would help others in the future... Thomas Wolf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Jul 30 8:45:50 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 ED2A037B400 for ; Tue, 30 Jul 2002 08:45:45 -0700 (PDT) Received: from relay01.esat.net (relay01.esat.net [192.111.39.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D92A43E31 for ; Tue, 30 Jul 2002 08:45:45 -0700 (PDT) (envelope-from phil@ipac.ie) Received: from ipac-gw.cr001.ddm.esat.net (mail.rfc-networks.ie) [193.95.188.30] by relay01.esat.net with esmtp id 17ZZBs-0007O1-00; Tue, 30 Jul 2002 16:45:40 +0100 Received: from tear.domain (unknown [10.0.1.254]) by mail.rfc-networks.ie (Postfix) with ESMTP id E232554839 for ; Tue, 30 Jul 2002 15:49:42 +0100 (IST) Received: by tear.domain (Postfix, from userid 1000) id F0DB72113F; Tue, 30 Jul 2002 16:46:27 +0000 (GMT) Date: Tue, 30 Jul 2002 16:46:27 +0000 From: Philip Reynolds To: freebsd-ipfw@freebsd.org Subject: Re: 4.6-RELEASE / NATD + IPFW + keep-state Message-ID: <20020730164627.A19307@rfc-networks.ie> Reply-To: philip.reynolds@rfc-networks.ie References: <20020729144758.A11849@rfc-networks.ie> <20020730055722.GD89241@blossom.cjclark.org> <20020730133246.A18016@rfc-networks.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020730133246.A18016@rfc-networks.ie>; from philip.reynolds@rfc-networks.ie on Tue, Jul 30, 2002 at 01:32:46PM +0000 X-Operating-System: FreeBSD 4.6-RC X-URL: http://www.rfc-networks.ie 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 Philip Reynolds 33 lines of wisdom included: > "Crist J. Clark" 19 lines of wisdom included: > > This is a FAQ, > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13412+0+archive/2002/freebsd-net/20020217.freebsd-net > > using ``via'' helped along the way and the setup is currently > working. > > What was needed was a specification of the public interface _only_ > for the ``NATD'' rule in conjunction with a specification of the > private interface _only_ for the ``keep-state'' rule. > > Unfortunately tweaking my rules before, I must have missed this > combination, although I'm not sure how. > > Thanks for to Crist and Boris for their help. After a lot of testing, I solved the problem earlier on (although not adequately, however it helped produce the solution below) --] Public Info [- Interface: xl0 Network: 10.0.0.0/24 (or simply: ``not 10.0.1.0/24'') Address: 10.0.0.56 --] Private Info [- Interface: xl1 Network: 10.0.1.0/24 Address: 10.0.1.56 Rules: divert natd ip from any to any via xl0 check-state deny tcp from any to any via xl1 established deny ip from any to any in recv xl1 frag allow tcp from 10.0.1.0/24 to any 22 via xl1 setup keep-state allow tcp from 10.0.0.56 to any 22 out xmit xl0 deny ip from any to any 1: Divert everything through the public interface to NAT 2: Check the state of the packets coming through. 3&4: No established connections or IP fragments should be here that aren't in the stateful ruleset table. 5: Allow any packets out to port 22 that have SYN (but not ACK) bit set (i.e. ``setup packets'') 6: Allow TCP connections from 10.0.0.56 to port 22. I was getting messages that a TCP connect from 10.0.0.56 to the destination machine on port 22 was being rejected without this. 7: Deny everything else. I hope my logic above is right, as you can see from my rules listing below, it seems to have solved the problem. $ ipfw -d list 00100 divert 8668 ip from any to any via xl0 00200 check-state 00250 deny tcp from any to any via xl1 established 00251 deny ip from any to any in recv xl1 frag 00300 allow tcp from 10.0.1.0/24 to any 22 keep-state via xl1 setup 00400 allow tcp from 10.0.0.56 to any 22 out xmit xl0 65534 deny ip from any to any ## Dynamic rules: 00300 32 4394 (T 203, slot 135) <-> tcp, 10.0.1.2 4249<-> 10.0.0.10 22 This is basically the refined version of my previous mail, the following commmands is a reduced ruleset that will work but provides no ruleset protecting packets coming in xl0 not destined for the 10.0.1.0/24 network. divert natd ip from any to any via xl0 check-state allow tcp from 10.0.1.0/24 to any 22 via xl1 setup keep-state deny ip from any to any via xl1 allow ip from any to any I think I confused people in my previous mail, however the above is what I meant. The ruleset, provided by a colleague of mine, however, is too open for my (and probably a lot of other peoples) needs. As you can see, the ``deny'' line, only denies anything going through xl1. With a bit of messing here as well though, another appropiate solution could be adequate. If anyone has any comments/suggestions etc. please direct them my way. Regards and many thanks, -- Philip Reynolds | Technical Director philip.reynolds@rfc-networks.ie | RFC Networks Ltd. http://www.rfc-networks.ie | +353 (0)1 8832063 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 31 14:59:18 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 4A7BA37B400 for ; Wed, 31 Jul 2002 14:59:16 -0700 (PDT) Received: from alchemistry.net (alchemistry.net [66.114.66.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id B415B43E4A for ; Wed, 31 Jul 2002 14:59:15 -0700 (PDT) (envelope-from mail@krel.org) Received: from amavis by alchemistry.net with scanned-ok (Exim 3.36 #1) id 17a1Ux-000Pyh-00 for freebsd-ipfw@freebsd.org; Wed, 31 Jul 2002 17:59:15 -0400 Received: from [192.168.0.1] (helo=ilya) by alchemistry.net with smtp (TLSv1:RC4-MD5:128) (Exim 3.36 #1) id 17a1Uw-000PyX-00 for freebsd-ipfw@freebsd.org; Wed, 31 Jul 2002 17:59:14 -0400 Message-ID: <015c01c238dd$a8bc8450$0100a8c0@ilya> From: "Ilya" To: Subject: ruleset q-n Date: Wed, 31 Jul 2002 17:59:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Virus-Scanned: by AMaViS snapshot-20010714 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 SSBoYXZlIGEgcHJvYmxlbSwgd2l0aCBzbXRwIHRyYWZmaWMsIGluIG15IGlwZncubG9nIGkgc2Vl IGFsb3Qgb2YgNjU1MzQgZGVuaWVkIHBhY2tldHMgZWl0aGVyIGZyb20gZm9yZWlnbl9pcCBwb3J0 IDI1LCBvciB0byBteSBpbnRlcm5ldF9pcCBwb3J0IDI1LCBldmVuIHRob3VnaCBhbGwgZW1haWxz IHNlZW0gdG8gZ28gdGhyb3VnaC4NCmhlcmUgaXMgbXkgcnVsZXNldDoNCg0KMDAxMDAgICAgIDAg MCBkaXZlcnQgODY2OCBpcCBmcm9tIGFueSB0byBhbnkgdmlhICRpbmV0ZXJuZXRfaWYgc2V0dXAN CjAwMjAwICAgICAwIDAgY2hlY2stc3RhdGUNCjAwMzAwICAgICAwIDAgYWxsb3cgaXAgZnJvbSAk TEFOIHRvIGFueSBrZWVwLXN0YXRlIHZpYSAkbGFuX2lmDQowMDQwMCAgICAgMCAwIGFsbG93IGlw IGZyb20gJGluZXRlcm5faXAgdG8gYW55IGtlZXAtc3RhdGUgdmlhICRpbnRlcm5ldF9pZg0KMDA1 MDAgICAgIDAgMCBhbGxvdyB0Y3AgZnJvbSBhbnkgdG8gJGludGVybmV0X2lwIDI1IGtlZXAtc3Rh dGUgdmlhICRpbmV0ZXJuZXRfaWYgc2V0dXANCjAwNjAwICAgICAwIDAgY2hlY2stc3RhdGUNCjAw NzAwICAgICAwIDAgYWxsb3cgdWRwIGZyb20gYW55IDUzIHRvICRpbmV0ZXJuZXRfaXAgNTMgdmlh ICRpbmV0ZXJuZXRfaWYgc2V0dXANCjAwODAwICAgICAwIDAgYWxsb3cgdWRwIGZyb20gYW55IDEw MjQtNjU1MzUgdG8gJGluZXRlcm5ldF9pcCA1MyB2aWEgJGluZXRlcm5ldF9pZiBzZXR1cA0KMDA5 MDAgICAgIDAgMCBhbGxvdyB1ZHAgZnJvbSBhbnkgNTMgdG8gJGluZXRlcm5ldF9pcCA1MyB2aWEg JGluZXRlcm5ldF9pZiBzZXR1cA0KMDEwMDAgICAgIDAgMCBhbGxvdyB1ZHAgZnJvbSBhbnkgMTAy NC02NTUzNSB0byAkaW5ldGVybmV0X2lwIDUzIHZpYSAkaW5ldGVybmV0X2lmIHNldHVwDQowMTEw MCAgICAgMCAwIGFsbG93IHVkcCBmcm9tIGFueSA1MyB0byAkaW5ldGVybmV0X2lwIDEwMjQtNjU1 MzUgdmlhICRpbmV0ZXJuZXRfaWYgc2V0dXANCjAxMjAwICAgICAwIDAgYWxsb3cgdWRwIGZyb20g YW55IDUzIHRvICRpbmV0ZXJuZXRfaXAgMTAyNC02NTUzNSB2aWEgJGluZXRlcm5ldF9pZiBzZXR1 cA0KMDEzMDAgICAgIDAgMCBhbGxvdyBpY21wIGZyb20gYW55IHRvIGFueSBpY21wdHlwZSAzLDQs MTEsMTINCjAxNDAwICAgICAwIDAgYWxsb3cgdGNwIGZyb20gYW55IHRvICRpbmV0ZXJuZXRfaXAg NDQzIHZpYSAkaW5ldGVybmV0X2lmIHNldHVwIHNldHVwDQowMTUwMCAgICAgMCAwIGFsbG93IGlw IGZyb20gYW55IHRvIGFueSB2aWEgbG8wDQo2NTUzNCAgICAgMCAwIGRlbnkgbG9nIGxvZ2Ftb3Vu dCAyMDAgaXAgZnJvbSBhbnkgdG8gYW55IGluIHJlY3YgJGluZXRlcm5ldF9pZiBzZXR1cA0KNjU1 MzUgICAgIDAgMCBhbGxvdyBpcCBmcm9tIGFueSB0byBhbnkNCg0KaSBoYWQgc2FtZSBwcm9ibGVt IHdpdGggRE5TIGFuZCBzb2x2ZWQgIGl0IGJ5IHNwZWNpZmljYWxseSBhbG93aW5nIEROUyB0cmFm ZmljIGluIGFsbCBkaXJlY3Rpb25zLCBidXQgaSBkb250IHRoaW5rIHRoYXRzIHRoZSByaWdodCB3 YXkuDQpXaHkgd291bGQgc210cCB0cmFmZmljIGhpdCB0aGUgbGFzdCBkZW55IHJ1bGUgYXQgYWxs Pw0KZm9yIGV4YW1wbGUgdGhpcyBpcyBhbiBlbnRyeSBmcm9tIGxvZzoNCkp1bCAzMSAxNzo1Mjo1 NyBteWJveCBpcGZ3OiA2NTUzNCBEZW55IFRDUCAyMTYuMTM2LjIwNC4xMTk6MjAwMjggJGludGVy bmV0X2lwOjI1IGluIHZpYSBlZDANCmJ1dCB0aGUgZW1haWwgZGlkIGNhbWUgdGhyb3VnaC4gaXQg YWxtb3N0IGxvb2tzIGxpa2UgdGhlIGNvbm5lY3Rpb24gaXMgY2xvc2VkLCBhbmQgdGhhbiBteDIu RnJlZUJTRC5vcmcgdHJpZXMgdG8gY29ubmVjdCB0byBwb3J0IDI1IGFnYWluLiANCndoeSB3b3Vs ZG50IGl0IGJlIGFibGUgdG8gZG8gc28/IHdoeSBkaWRudCB0aGlzIHBhY2tldCBoaXQgcnVsZSA1 MDAgPyBhbmQgaW5zdGVhZCBoaXQgNjU1MzQ/DQoNCkkgZXZlbiBhZGRlZCBjaGVja19zdGF0ZSBp biB0d28gcGxhY2VzLCBidXQgdGhhdCBkaWRudCBoZWxwLg0KDQp0aGFua3MgYSBsb3QgaW4gYWR2 YW5jZQ== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 31 15:28:10 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 2BC7937B400 for ; Wed, 31 Jul 2002 15:28:08 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA03843E31 for ; Wed, 31 Jul 2002 15:28:07 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g6VMS6f69442; Wed, 31 Jul 2002 15:28:06 -0700 (PDT) (envelope-from rizzo) Date: Wed, 31 Jul 2002 15:28:06 -0700 From: Luigi Rizzo To: Dan Pelleg Cc: ipfw@FreeBSD.ORG Subject: Re: IPFW2 keep-alive Message-ID: <20020731152806.B69266@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 daniel+bsd@pelleg.org on Sun, Jul 28, 2002 at 10:25:25AM -0400 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 The logic works as follows: when a O_LIMIT or O_KEEP_STATE rule has less than 20 seconds left, the firewall will send a keepalive packet to both sides every 5 seconds. If any of the two responds, then the timeout will be updated accordingly -- i.e. a regular data packet will reset it up to 300 seconds or whatever the default is, a RST will put it down to 1 which is below the threshold for generating a new keepalive. If none responds, the timeout will be left untouched. Now i wonder if in your case what happens is that the remote server is not sending RST for invalid packets, and you do have a socket in some closing state (or even a mozilla about to close) still handling the keepalives and replying to them. cheers luigi On Sun, Jul 28, 2002 at 10:25:25AM -0400, Dan Pelleg wrote: > > What's the exact mechanism to expire dynamic rules under IPFW2? I > understand it's sending keep-alive packets as the rule is about to > expire. Is there any way for these to result in the rule being removed? The > behaviour I'm seeing is this: > > During a network partition, the application program (Mozilla) retried to > connect to remote hosts and opened many connections, eventually hitting the > LIMIT count. > > Now the network is back up. However there is no way to open new > connections since the appropriate rule's LIMIT is met. Repeated ipfw -d > show that the rules are refreshed when they have 5-6 seconds to live (and > go back to 10 seconds or so). I'm not sure what's doing that - the local > application is long terminated. The only workaround I found was to flush > the ruleset (I guess replacing just that rule would have also worked). > > -- > > Dan Pelleg > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Jul 31 19: 8: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 D1F6F37B400 for ; Wed, 31 Jul 2002 19:08:02 -0700 (PDT) Received: from smtp.a1poweruser.com (oh-chardon6a-62.clvhoh.adelphia.net [68.65.175.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id D49A343E42 for ; Wed, 31 Jul 2002 19:08:01 -0700 (PDT) (envelope-from barbish@a1poweruser.com) Received: from barbish (lanwin1 [10.0.10.6]) by smtp.a1poweruser.com (Postfix) with SMTP id 0B6F2D7 for ; Wed, 31 Jul 2002 22:11:48 -0400 (EDT) Reply-To: From: "Joe & Fhe Barbish" To: "FBIPFW" Subject: natd & keep-state Date: Wed, 31 Jul 2002 22:07:59 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 IPFW list members Advanced Stateful extensions were introduced in FBSD 4.0. When they first can out I changed my ipfw rules from stateless and simple stateful to using only Advanced Stateful rules for my user ppp -nat ISP connection. The ipfw rule set that works with user ppp -nat is posted below. I have tried to get this same rules file to function exchanging user ppp -nat for ipfw natd. There was always problems with natd ip address and the dynamic rules table getting mismatches so I went back to user ppp -nat. Every new version of FBSD I would try again to use natd hopping there may have been some fixes to natd, but no such luck. Each new version still failed. Each time I would post questions to the FBSD questions list, but most of the replies were from people who were having the same problems with natd and keep-state rules that I was. Well now I am forced to address the problem again because I now have cable access to the internet and I can no longer use the -nat function of user ppp. So this time I joined this ipfw list hoping my post will be read by a larger group of people who have an very technical understanding of IPFW/NATD and the Advanced Stateful extensions check-state / keep-state who will be able to Provide a solution or come to the realization that there is a bug that needs fixing. The following posted rules are the rules file that works just fine using user ppp -nat. As you can see it is very basic but demonstrates the logic flow of only allowing selected functions to be started for access to the public internet and selected functions originating from the public internet to be started for access to the local network. To use these rules for NATD I change xif="tun0" to xif="rl0" which is the Nic card cabled to the cable modem. odns1 & odns2 to the ip address of the cable providers dns servers. And add the $cmd 200 divert natd all from any to any via $xif as rule number 200 so it gets positioned before the check-state statement. The positioning of the divert statement is patterned after the /etc/rc.firewall sample. Be assured that the rc.conf and kernel options are in place to activate NATD. I an now using FBSD version 4.6. I have read and reread the ipfw man pages until I an blue in the face. I am not a newbe to FBSD or IPFW and post this in hopes of achieving a real solution in the way of a working ipfw/natd rules file based on my rules file below. I have chosen functions which should be easy for you to test on your own systems. Thanks for your help in this matter Joe # Flush out the list before we begin. /sbin/ipfw -q -f flush # Set rules command prefix # The -q option on the command is for quite mode. # Do not display rules as they load. Remove during development to see. #cmd="/sbin/ipfw -q add" cmd="/sbin/ipfw add" # Set defaults # set these to your external interface network xif="tun0" odns1="218.216.115.111" # ISP's dns server 1 IP address odns2="218.216.115.112" # ISP's dns server 2 IP address # Set these to your inside interface network iif="xl0" # Nic card # Internal gateway housekeeping $cmd 100 allow all from any to any via lo0 # allow all localhost $cmd 150 deny all from any to 127.0.0.0/8 # deny use of localhost IP $cmd 160 deny all from 127.0.0.0/8 to any # deny use of localhost IP $cmd 180 allow all from any to any via $iif # allow all local LAN ######## control section ############################################ $cmd 500 check-state # Deny & log all fragments as bogus packets $cmd 502 deny log all from any to any frag via $xif # Deny & log ACK packets that did not match the dynamic rule table $cmd 501 deny log tcp from any to any established via $xif ######## outbound section ########################################### # Interrogate packets originating from behind the firewall, private net. # Upon a rule match, it's keep-state option will create a dynamic rule. # Allow out www function $cmd 600 allow tcp from any to any 80 out via $xif setup keep-state # Allow out access to my ISP's Domain name server. $cmd 610 allow tcp from any to $odns1 53 out via $xif setup keep-state $cmd 611 allow udp from any to $odns1 53 out via $xif keep-state $cmd 615 allow tcp from any to $odns2 53 out via $xif setup keep-state $cmd 616 allow udp from any to $odns2 53 out via $xif keep-state # Allow out send & get email function $cmd 630 allow tcp from any to any 25,110 out via $xif setup keep-state # Allow out & in FBSD (make install & CVSUP) functions # Basically give user id root "GOD" privileges. $cmd 640 allow tcp from me to any out via $xif setup keep-state uid root # Allow out ping $cmd 650 allow icmp from any to any out via $xif keep-state # Allow out TELNET $cmd 660 allow tcp from any to any 23 out via $xif setup keep-state ############ passive FTP rules for LAN PC FTP to public Internet ###### # Allow passive FTP control channel 21 & data high ports $cmd 700 allow tcp from any to any 21 out via $xif setup keep-state $cmd 710 allow tcp from any to any 10000-65000 out via $xif setup keep-state ##### End of passive FTP rules for LAN PC FTP to public Internet ###### ######## inbound section ############################################ # Allow in www $cmd 800 allow tcp from any to any 80 in via $xif setup limit src-addr 4 # Allow in ssh function $cmd 820 allow log tcp from any to me 22 in via $xif setup limit src-addr 4 # Allow in Telnet $cmd 830 allow tcp from any to any 23 in via $xif setup limit src-addr 4 #$cmd 830 allow tcp from any to any 23 in via $xif setup keep-state ######## catch all section ############################################ # Stop & log external redirect requests. $cmd 845 deny log icmp from any to any icmptype 5 in via $xif # Stop & log spoofing Attack attempts. $cmd 850 deny log ip from me to me in via $xif # Stop & log ping echo attacks # stop echo reply (ICMP type 0), and echo request (type 8). $cmd 860 deny log icmp from any to me icmptype 0,8 in via $xif # Reject & Log all setup of incoming connections from the outside $cmd 900 deny log tcp from any to any setup in via $xif # Everything else is denied by default # deny and log all packets that fall through to see what they are $cmd 910 deny log logamount 500 all from any to any To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 1 2:43:55 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 D2B1337B400 for ; Thu, 1 Aug 2002 02:43:52 -0700 (PDT) Received: from relay02.esat.net (relay02.esat.net [192.111.39.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B5CB43E42 for ; Thu, 1 Aug 2002 02:43:52 -0700 (PDT) (envelope-from phil@ipac.ie) Received: from ipac-gw.cr001.ddm.esat.net (mail.rfc-networks.ie) [193.95.188.30] by relay02.esat.net with esmtp id 17aCUp-0007aQ-00; Thu, 01 Aug 2002 10:43:51 +0100 Received: from tear.domain (unknown [10.0.1.254]) by mail.rfc-networks.ie (Postfix) with ESMTP id A04315483C for ; Thu, 1 Aug 2002 09:47:52 +0100 (IST) Received: by tear.domain (Postfix, from userid 1000) id 5AE9E2113F; Thu, 1 Aug 2002 10:44:38 +0000 (GMT) Date: Thu, 1 Aug 2002 10:44:38 +0000 From: Philip Reynolds To: freebsd-ipfw@freebsd.org Subject: Re: ruleset q-n Message-ID: <20020801104438.A28257@rfc-networks.ie> Reply-To: philip.reynolds@rfc-networks.ie References: <015c01c238dd$a8bc8450$0100a8c0@ilya> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015c01c238dd$a8bc8450$0100a8c0@ilya>; from mail@krel.org on Wed, Jul 31, 2002 at 05:59:55PM -0400 X-Operating-System: FreeBSD 4.6-RC X-URL: http://www.rfc-networks.ie 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 Ilya 41 lines of wisdom included: > I have a problem, with smtp traffic, in my ipfw.log i see alot of 65534 denied packets either from foreign_ip port 25, or to my internet_ip port 25, even though all emails seem to go through. > here is my ruleset: > > > i had same problem with DNS and solved it by specifically alowing DNS traffic in all directions, but i dont think thats the right way. > Why would smtp traffic hit the last deny rule at all? > for example this is an entry from log: > Jul 31 17:52:57 mybox ipfw: 65534 Deny TCP 216.136.204.119:20028 $internet_ip:25 in via ed0 > but the email did came through. it almost looks like the connection is closed, and than mx2.FreeBSD.org tries to connect to port 25 again. > why wouldnt it be able to do so? why didnt this packet hit rule 500 ? and instead hit 65534? I don't have the time to look at your problem in-depth at the moment, but perhaps look at the following: http://resources.rfc-networks.ie/freebsd/ipfw_nat_stateful.phtml As you seem to be using NAT and stateful firewalling. After coming across problems with NAT and stateful firewalling, the above solution worked for me. If you're still having problems after completing the instructions (there aren't many I know, but I'm just starting it), paste the output for ipfw -d list, during the connections, and more verbose logs, plus an analysis of the traffic would be nice as well (see tcpdump(1)). -- Philip Reynolds | Technical Director philip.reynolds@rfc-networks.ie | RFC Networks Ltd. http://www.rfc-networks.ie | +353 (0)1 8832063 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 1 8:36:18 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 451F737B400 for ; Thu, 1 Aug 2002 08:36:15 -0700 (PDT) Received: from novaconnect.net (ns.novaconnect.net [205.150.191.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id B02E143E6A for ; Thu, 1 Aug 2002 08:36:14 -0700 (PDT) (envelope-from mailing@novaconnect.net) Received: from [192.168.100.21] (account ) by novaconnect.net (CommuniGate Pro WebUser 3.5b5) with HTTP id 44848 for ; Thu, 01 Aug 2002 11:33:52 -0400 From: "Matt Abraham" Subject: "ipfw fwd" not working without static route? To: freebsd-ipfw@freebsd.org X-Mailer: CommuniGate Pro Web Mailer v.3.5b5 Date: Thu, 01 Aug 2002 11:33:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit 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'm trying to forward all packets from a privately addressed machine (172.17.1.5) to a gateway via a FreeBSD box running ipfw. Here's the ipfw directive: fwd 192.168.215.15 log logamount 10000 ip from 172.17.1.5 to any Now when I ping public address a.b.c.d from 172.17.1.5, I get a "Destination Host Unreachable." When I try to ping this same address from the FreeBSD box, I get a "No route to host" message. Adding a static route, however, solves the problem: route add -net a.b.c.d 192.169.215.15 ...so now I can ping from both 172.17.1.5 and my FreeBSD firewall! Of course, having to add routes, sort of defeats the ipfw fwd command, doesn't it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 1 11:44:53 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 73E2737B400 for ; Thu, 1 Aug 2002 11:44:51 -0700 (PDT) Received: from mail.robhughes.com (12-237-138-77.client.attbi.com [12.237.138.77]) by mx1.FreeBSD.org (Postfix) with SMTP id 9F61E43E9E for ; Thu, 1 Aug 2002 11:44:50 -0700 (PDT) (envelope-from rob@robhughes.com) Received: (qmail 5256 invoked from network); 1 Aug 2002 18:44:45 -0000 Received: from hexch01.robhughes.com (192.168.1.3) by ns2.robhughes.com with SMTP; 1 Aug 2002 18:44:45 -0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: natd & keep-state X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 1 Aug 2002 13:44:43 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: natd & keep-state Thread-Index: AcI5AF/KS1scQqs3QI22afC+RE/OeQAieK4u From: "Robert D Hughes" To: "FBIPFW" 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 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQpGcm9tOiBKb2UgJiBGaGUgQmFyYmlzaCBbbWFp bHRvOmJhcmJpc2hAYTFwb3dlcnVzZXIuY29tXSANClNlbnQ6IFdlZCA3LzMxLzIwMDIgOTowNyBQ TSANClRvOiBGQklQRlcgDQpDYzogDQpTdWJqZWN0OiBuYXRkICYga2VlcC1zdGF0ZQ0KDQoNCg0K CUlQRlcgbGlzdCBtZW1iZXJzDQoJDQoJQWR2YW5jZWQgU3RhdGVmdWwgZXh0ZW5zaW9ucyB3ZXJl IGludHJvZHVjZWQgaW4gRkJTRCA0LjAuIFdoZW4gdGhleQ0KCWZpcnN0IGNhbiBvdXQgSSBjaGFu Z2VkIG15IGlwZncgcnVsZXMgZnJvbSBzdGF0ZWxlc3MgYW5kIHNpbXBsZQ0KCXN0YXRlZnVsIHRv IHVzaW5nIG9ubHkgQWR2YW5jZWQgU3RhdGVmdWwgcnVsZXMgZm9yIG15IHVzZXINCglwcHAgLW5h dCBJU1AgY29ubmVjdGlvbi4gVGhlIGlwZncgcnVsZSBzZXQgdGhhdCB3b3JrcyB3aXRoIHVzZXIN CgkNCg0KCUl0IG1pZ2h0IGhlbHAgaWYgeW91IGRlc2NyaWJlZCBpbiBtb3JlIGRldGFpbCB3aGF0 IHByb2JsZW1zIHlvdSdyZSBoYXZpbmcuIEknbSBydW5uaW5nIGEgcmF0aGVyIG11Y2ggbW9yZSBj b21wbGV4IHJ1bGUgc2V0IHRoYXQgd29ya3MgdXNpbmcgZmluZSBpcGZ3IGFuZCBuYXRkLCBpbmNs dWRpbmcgcG9ydCByZWRpcmVjdHMsIHBhc3NpdmUgYW5kIGFjdGl2ZSBmdHAsIGV0Yy4gV291bGQg eW91IGxpa2UgdG8gbG9vayBhdCBteSBydWxlIHNldD8NCg0KCVJvYg0KDQo= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 1 12:49:40 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 E1AAE37B400 for ; Thu, 1 Aug 2002 12:49:35 -0700 (PDT) Received: from smtp.a1poweruser.com (oh-chardon6a-62.clvhoh.adelphia.net [68.65.175.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0074C43E84 for ; Thu, 1 Aug 2002 12:49:35 -0700 (PDT) (envelope-from barbish@a1poweruser.com) Received: from barbish (lanwin1 [10.0.10.6]) by smtp.a1poweruser.com (Postfix) with SMTP id 584B631; Thu, 1 Aug 2002 15:53:15 -0400 (EDT) Reply-To: From: "Joe & Fhe Barbish" To: "Robert D Hughes" Cc: "FBIPFW" Subject: RE: natd & keep-state Date: Thu, 1 Aug 2002 15:49:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal 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 Bob, thanks very much for your offer. If your rules file has keep-state rules in it, I would be interested in = seeing it. The problem is natd with ipfw keep-state rules not ipfw with natd.=20 This being the list where IPFW internals and design problems are talked = over,=20 I really want a experienced person like you to provide independent = verification =20 that there is a bug in natd with ipfw keep-state rules.=20 Just humor me and test the simple rules file I provided in my original = post and=20 make it work on your box. I bet you can not get it to work. =20 I say there's a bug in natd and need help bring it to light before this = list group. Can you help in this effort?=20 Thanks Joe=20 -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG = [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Robert D Hughes Sent: Thursday, August 01, 2002 2:45 PM To: FBIPFW Subject: RE: natd & keep-state -----Original Message----- From: Joe & Fhe Barbish [mailto:barbish@a1poweruser.com] Sent: Wed 7/31/2002 9:07 PM To: FBIPFW Cc: Subject: natd & keep-state IPFW list members =20 Advanced Stateful extensions were introduced in FBSD 4.0. When = they first can out I changed my ipfw rules from stateless and simple stateful to using only Advanced Stateful rules for my user ppp -nat ISP connection. The ipfw rule set that works with user =20 It might help if you described in more detail what problems = you're having. I'm running a rather much more complex rule set that = works using fine ipfw and natd, including port redirects, passive and = active ftp, etc. Would you like to look at my rule set? Rob Nrz vfj:v?=16=05=20 =1Bry y{y?=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 1 13:18: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 A612537B400 for ; Thu, 1 Aug 2002 13:18:12 -0700 (PDT) Received: from mail.robhughes.com (12-237-138-77.client.attbi.com [12.237.138.77]) by mx1.FreeBSD.org (Postfix) with SMTP id 9A5DE43E4A for ; Thu, 1 Aug 2002 13:18:11 -0700 (PDT) (envelope-from rob@robhughes.com) Received: (qmail 5536 invoked from network); 1 Aug 2002 20:18:11 -0000 Received: from hexch01.robhughes.com (192.168.1.3) by ns2.robhughes.com with SMTP; 1 Aug 2002 20:18:11 -0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: natd & keep-state X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 1 Aug 2002 15:18:09 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: natd & keep-state Thread-Index: AcI5lKGKxGl8qZxCSweRB76DQCX8XAAAcQoY From: "Robert D Hughes" To: Cc: "FBIPFW" 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 U2V0dXAgYW5kIGtlZXAtc3RhdGUgYXJlIGluIHByZXR0eSBtdWNoIGV2ZXJ5IHJ1bGUuIEkgdGhp bmsgeW91ciBpc3N1ZSBpcyB0aGF0IHlvdSdyZSB0cnlpbmcgdG8gdXNlIGluIHZpYS9vdXQgdmlh LiBUcnkganVzdCB1c2luZyB2aWEgIGFuZCBzZWUgaWYgdGhhdCB3b3Jrcy4gVGhlcmUgYXJlIHBs YWNlcyB0byB1c2UgdGhvc2UsIGJ1dCBmb3IgZ2VuZXJhbCBydWxlcyB5b3UganVzdCB3YW50IHRv IG1ha2Ugc3VyZSBhIHBhY2tldCBpcyBwYXNzaW5nIHRocm91Z2ggYSBwYXRpY3VsYXIgaW50ZXJm YWNlLiBXaGVuIHRoYXQgcGFja2V0IGNvbWVzIGJhY2ssIGl0IHN0aWxsIGhhcyB0byBwYXNzIHRo cm91Z2ggdGhhdCBzYW1lIGludGVyZmFjZSwgYnV0IHdpbGwgbm8gbG9uZ2VyIG1hdGNoIGR1ZSB0 byB0aGUgImluIiBvciAib3V0IiBzdGF0ZW1lbnRzIHlvdSd2ZSB1c2VkLiBUaGF0J3MgcHJvYmFi bHkgd2hhdCdzIGNhdXNpbmcgeW91ciBydWxlcyB0byBmYWlsLiBSZW1lbWJlciwgaXBmdyBnb2Vz IHVudGlsIGl0IGhpdHMgYSBtYXRjaCwgd2hldGhlciBpdCdzIGEgcGFzcyBvciBkZW55LCB0aGVu IHN0b3BzLiBJZiB5b3UgcmVjb21waWxlZCB5b3VyIGtlcm5lbCB3aXRoIHRoZSBERUZBVUxUX1RP X0FDQ0VQVCBvcHRpb24sIHlvdSdkIGdldCBnb2JzIG9mIHBhY2tldHMgbWF0Y2hpbmcgb24gaXQu DQogDQpBbmQgdWgsIHRoYXQncyB3aHkgSSBkbyBydWxlcyB0aGUgd2F5IEkgZG8sIGJlY2F1c2Ug SSB0cmllZCBpdCB5b3VyIHdheSBhbmQgaXQgZGlkbid0IHdvcmsuDQogDQpTYW1wbGUgcnVsZXM6 DQogDQogICAgICAgIGNhc2UgJHtuYXRkX2VuYWJsZX0gaW4NCiAgICAgICAgW1l5XVtFZV1bU3Nd KQ0KICAgICAgICAgICAgICAgIGlmIFsgLW4gIiR7bmF0ZF9pbnRlcmZhY2V9IiBdOyB0aGVuDQog ICAgICAgICAgICAgICAgICAgICAgICAke2Z3Y21kfSBhZGQgZGl2ZXJ0IG5hdGQgYWxsIGZyb20g YW55IHRvIGFueSB2aWEgJHtuYXRkX2ludGVyZmFjZX0NCiAgICAgICAgICAgICAgICBmaQ0KICAg ICAgICAgICAgICAgIDs7DQogICAgICAgIGVzYWMNCiANCiAgICAgICAgIyBTdG9wIFJGQzE5MTgg bmV0cyBvbiB0aGUgb3V0c2lkZSBpbnRlcmZhY2UNCiAgICAgICAgJHtmd2NtZH0gYWRkIGRlbnkg YWxsIGZyb20gMTAuMC4wLjAvOCB0byBhbnkgdmlhICR7b2lmfQ0KICAgICAgICAke2Z3Y21kfSBh ZGQgZGVueSBhbGwgZnJvbSAxNzIuMTYuMC4wLzEyIHRvIGFueSB2aWEgJHtvaWZ9DQogICAgICAg ICR7ZndjbWR9IGFkZCBkZW55IGFsbCBmcm9tIDE5Mi4xNjguMC4wLzE2IHRvIGFueSB2aWEgJHtv aWZ9DQogICAgICAgICAjQ2hlY2sgc3RhdGUgaW5mbyBhbmQgcGFzcyBlc3RhYmxpc2hlZCB0cmFm ZmljDQogICAgICAgICR7ZndjbWR9IGFkZCBjaGVjay1zdGF0ZQ0KIA0KICAgICAgICAjIEFsbG93 IFRDUCB0aHJvdWdoIGlmIHNldHVwIHN1Y2NlZWRlZA0KICAgICAgICAke2Z3Y21kfSBhZGQgcGFz cyB0Y3AgZnJvbSBhbnkgdG8gYW55IGVzdGFibGlzaGVkDQogDQogICAgICAgICMgQWxsb3cgSVAg ZnJhZ21lbnRzIHRvIHBhc3MgdGhyb3VnaA0KICAgICAgICAke2Z3Y21kfSBhZGQgcGFzcyBhbGwg ZnJvbSBhbnkgdG8gYW55IGZyYWcNCg0KICAgICAgICAke2Z3Y21kfSBhZGQgcGFzcyB1ZHAgZnJv bSBhbnkgNjctNjggdG8gYW55IDY3LTY4IHZpYSAke29pZn0NCiANCiAgICAgICAgI1NTSCBydWxl cyB0byBmaXJld2FsbCBhbmQgb3RoZXJzDQogICAgICAgICR7ZndjbWR9IGFkZCBwYXNzIHRjcCBm cm9tIGFueSB0byBtZSBzc2ggc2V0dXAga2VlcC1zdGF0ZSBpbg0KICAgICAgICAke2Z3Y21kfSBh ZGQgcGFzcyB0Y3AgZnJvbSBhbnkgdG8gbWUgc2Z0cCBzZXR1cCBrZWVwLXN0YXRlIGluDQogICAg ICAgICR7ZndjbWR9IGFkZCBwYXNzIHRjcCBmcm9tIGFueSB0byAke21hbmFnZXIyfSBzc2ggc2V0 dXAga2VlcC1zdGF0ZQ0KICAgICAgICAke2Z3Y21kfSBhZGQgcGFzcyB0Y3AgZnJvbSBhbnkgdG8g JHttYW5hZ2VyMn0gc2Z0cCBzZXR1cCBrZWVwLXN0YXRlDQogDQogICAgICAgICMgQWxsb3cgYWNj ZXNzIHRvIG91ciBETlMNCiAgICAgICAgJHtmd2NtZH0gYWRkIHBhc3MgdGNwIGZyb20gYW55IHRv IG1lIDUzIGtlZXAtc3RhdGUgc2V0dXAgaW4NCiAgICAgICAgJHtmd2NtZH0gYWRkIHBhc3MgdWRw IGZyb20gYW55IHRvIG1lIDUzIGtlZXAtc3RhdGUgaW4NCiAgICAgICAgJHtmd2NtZH0gYWRkIHBh c3MgdGNwIGZyb20gbWUgNTMgdG8gYW55IGtlZXAtc3RhdGUgc2V0dXAgb3V0DQogICAgICAgICR7 ZndjbWR9IGFkZCBwYXNzIHVkcCBmcm9tIG1lIDUzIHRvIGFueSBrZWVwLXN0YXRlIG91dA0KICAg ICAgICAjIEFsbG93IGFjY2VzcyB0byBvdXIgV1dXDQogICAgICAgICMgQWxsb3cgc2V0dXAgb2Yg aW5jb21pbmcgZW1haWwNCiAgICAgICAgJHtmd2NtZH0gYWRkIHBhc3MgdGNwIGZyb20gbWUgdG8g YW55IDI1IHNldHVwIGtlZXAtc3RhdGUgb3V0DQogICAgICAgICR7ZndjbWR9IGFkZCBwYXNzIHRj cCBmcm9tIGFueSB0byBtZSAyNSBzZXR1cCBrZWVwLXN0YXRlIGluDQogICAgICAgICR7ZndjbWR9 IGFkZCBwYXNzIHRjcCBmcm9tIGFueSB0byAke3d3dzF9IDgwIHNldHVwIHZpYSAke29pZn0NCiAg ICAgICAgJHtmd2NtZH0gYWRkIHBhc3MgdGNwIGZyb20gYW55IHRvICR7d3d3MX0gNDQzIHNldHVw DQogICAgICAgICR7ZndjbWR9IGFkZCBwYXNzIHRjcCBmcm9tIGFueSB0byBhbnkgMzg5IHNldHVw IHZpYSBhbnkNCiANCiAgICAgICAgI1NwZWNpYWwgc2VjdGlvbiB0byBhbGxvdyBkZW1vIGFjY2Vz cyB0byB0aGUgTk5NIHN5c3RlbQ0KICAgICAgICAke2Z3Y21kfSBhZGQgcGFzcyB0Y3AgZnJvbSBh bnkgdG8gJHt3d3cyfSA4ODgwIHNldHVwDQogICAgICAgICR7ZndjbWR9IGFkZCBwYXNzIHRjcCBm cm9tIGFueSB0byAke3d3dzJ9IDI5NTMgc2V0dXANCiAgICAgICAgJHtmd2NtZH0gYWRkIHBhc3Mg dGNwIGZyb20gYW55IHRvICR7d3d3Mn0gMjk1NCBzZXR1cA0KIA0KQW5kIG9uIGFuZCBvbiBmb3Ig YSB0b3RhbCBvZiBhcm91bmQgYSBodW5kcmVkIHJ1bGVzLCBib3RoIGJlZm9yZSBhbmQgYWZ0ZXIg dGhpcyBzYW1wbGUuDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBKb2Ug JiBGaGUgQmFyYmlzaCBbbWFpbHRvOmJhcmJpc2hAYTFwb3dlcnVzZXIuY29tXSANCglTZW50OiBU aHUgOC8xLzIwMDIgMjo0OSBQTSANCglUbzogUm9iZXJ0IEQgSHVnaGVzIA0KCUNjOiBGQklQRlcg DQoJU3ViamVjdDogUkU6IG5hdGQgJiBrZWVwLXN0YXRlDQoJDQoJDQoNCglCb2IsIHRoYW5rcyB2 ZXJ5IG11Y2ggZm9yIHlvdXIgb2ZmZXIuDQoJDQoJSWYgeW91ciBydWxlcyBmaWxlIGhhcyBrZWVw LXN0YXRlIHJ1bGVzIGluIGl0LCBJIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gc2VlaW5nIGl0Lg0K CQ0KCVRoZSBwcm9ibGVtIGlzIG5hdGQgd2l0aCBpcGZ3IGtlZXAtc3RhdGUgcnVsZXMgICBub3Qg ICBpcGZ3IHdpdGggbmF0ZC4NCgkNCglUaGlzIGJlaW5nIHRoZSBsaXN0IHdoZXJlIElQRlcgaW50 ZXJuYWxzIGFuZCBkZXNpZ24gcHJvYmxlbXMgYXJlIHRhbGtlZCBvdmVyLA0KCUkgcmVhbGx5IHdh bnQgYSBleHBlcmllbmNlZCBwZXJzb24gbGlrZSB5b3UgIHRvIHByb3ZpZGUgaW5kZXBlbmRlbnQg dmVyaWZpY2F0aW9uIA0KCXRoYXQgdGhlcmUgaXMgYSBidWcgaW4gbmF0ZCB3aXRoIGlwZncga2Vl cC1zdGF0ZSBydWxlcy4NCgkNCglKdXN0IGh1bW9yIG1lIGFuZCB0ZXN0IHRoZSBzaW1wbGUgcnVs ZXMgZmlsZSBJIHByb3ZpZGVkIGluIG15IG9yaWdpbmFsIHBvc3QgYW5kDQoJbWFrZSBpdCB3b3Jr IG9uIHlvdXIgYm94LiAgSSBiZXQgeW91IGNhbiBub3QgZ2V0IGl0IHRvIHdvcmsuIA0KCQ0KCUkg c2F5IHRoZXJlJ3MgYSBidWcgaW4gbmF0ZCBhbmQgbmVlZCBoZWxwIGJyaW5nIGl0IHRvIGxpZ2h0 IGJlZm9yZSB0aGlzIGxpc3QgZ3JvdXAuDQoJDQoJQ2FuIHlvdSBoZWxwIGluIHRoaXMgZWZmb3J0 Pw0KCQ0KCVRoYW5rcw0KCUpvZQ0KCQ0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJRnJv bTogb3duZXItZnJlZWJzZC1pcGZ3QEZyZWVCU0QuT1JHIFttYWlsdG86b3duZXItZnJlZWJzZC1p cGZ3QEZyZWVCU0QuT1JHXU9uIEJlaGFsZiBPZiBSb2JlcnQgRCBIdWdoZXMNCglTZW50OiBUaHVy c2RheSwgQXVndXN0IDAxLCAyMDAyIDI6NDUgUE0NCglUbzogRkJJUEZXDQoJU3ViamVjdDogUkU6 IG5hdGQgJiBrZWVwLXN0YXRlDQoJDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCglGcm9t OiBKb2UgJiBGaGUgQmFyYmlzaCBbbWFpbHRvOmJhcmJpc2hAYTFwb3dlcnVzZXIuY29tXQ0KCVNl bnQ6IFdlZCA3LzMxLzIwMDIgOTowNyBQTQ0KCVRvOiBGQklQRlcNCglDYzoNCglTdWJqZWN0OiBu YXRkICYga2VlcC1zdGF0ZQ0KCQ0KCQ0KCQ0KCSAgICAgICAgSVBGVyBsaXN0IG1lbWJlcnMNCgkg ICAgICANCgkgICAgICAgIEFkdmFuY2VkIFN0YXRlZnVsIGV4dGVuc2lvbnMgd2VyZSBpbnRyb2R1 Y2VkIGluIEZCU0QgNC4wLiBXaGVuIHRoZXkNCgkgICAgICAgIGZpcnN0IGNhbiBvdXQgSSBjaGFu Z2VkIG15IGlwZncgcnVsZXMgZnJvbSBzdGF0ZWxlc3MgYW5kIHNpbXBsZQ0KCSAgICAgICAgc3Rh dGVmdWwgdG8gdXNpbmcgb25seSBBZHZhbmNlZCBTdGF0ZWZ1bCBydWxlcyBmb3IgbXkgdXNlcg0K CSAgICAgICAgcHBwIC1uYXQgSVNQIGNvbm5lY3Rpb24uIFRoZSBpcGZ3IHJ1bGUgc2V0IHRoYXQg d29ya3Mgd2l0aCB1c2VyDQoJICAgICAgDQoJDQoJICAgICAgICBJdCBtaWdodCBoZWxwIGlmIHlv dSBkZXNjcmliZWQgaW4gbW9yZSBkZXRhaWwgd2hhdCBwcm9ibGVtcyB5b3UncmUgaGF2aW5nLiBJ J20gcnVubmluZyBhIHJhdGhlciBtdWNoIG1vcmUgY29tcGxleCBydWxlIHNldCB0aGF0IHdvcmtz IHVzaW5nIGZpbmUgaXBmdyBhbmQgbmF0ZCwgaW5jbHVkaW5nIHBvcnQgcmVkaXJlY3RzLCBwYXNz aXZlIGFuZCBhY3RpdmUgZnRwLCBldGMuIFdvdWxkIHlvdSBsaWtlIHRvIGxvb2sgYXQgbXkgcnVs ZSBzZXQ/DQoJDQoJICAgICAgICBSb2INCgkNCglOcnogdmZqOnY/FgUNCgkbcnkgeXt5Pw0KCQ0K CQ0KDQo= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 1 15: 9: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 2B22137B400 for ; Thu, 1 Aug 2002 15:09:50 -0700 (PDT) Received: from relay03.esat.net (relay03.esat.net [193.95.141.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EFD043E6E for ; Thu, 1 Aug 2002 15:09:49 -0700 (PDT) (envelope-from phil@ipac.ie) Received: from ipac-gw.cr001.ddm.esat.net (mail.rfc-networks.ie) [193.95.188.30] by relay03.esat.net with esmtp id 17aO8i-0007Pa-00; Thu, 01 Aug 2002 23:09:48 +0100 Received: from tear.domain (unknown [10.0.1.254]) by mail.rfc-networks.ie (Postfix) with ESMTP id 247B654834 for ; Thu, 1 Aug 2002 22:13:49 +0100 (IST) Received: by tear.domain (Postfix, from userid 1000) id 165C92113F; Thu, 1 Aug 2002 23:10:35 +0000 (GMT) Date: Thu, 1 Aug 2002 23:10:35 +0000 From: Philip Reynolds To: freebsd-ipfw@freebsd.org Subject: Re: "ipfw fwd" not working without static route? Message-ID: <20020801231035.B31318@rfc-networks.ie> Reply-To: philip.reynolds@rfc-networks.ie References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from mailing@novaconnect.net on Thu, Aug 01, 2002 at 11:33:52AM -0400 X-Operating-System: FreeBSD 4.6-RC X-URL: http://www.rfc-networks.ie 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 Matt Abraham 21 lines of wisdom included: > I'm trying to forward all packets from a privately addressed > machine (172.17.1.5) to a gateway via a FreeBSD box running > ipfw. Here's the ipfw directive: > > fwd 192.168.215.15 log logamount 10000 ip from 172.17.1.5 to > any > > Now when I ping public address a.b.c.d from 172.17.1.5, I > get a "Destination Host Unreachable." When I try to ping > this same address from the FreeBSD box, I get a "No route to > host" message. Adding a static route, however, solves the > problem: > > route add -net a.b.c.d 192.169.215.15 > > ...so now I can ping from both 172.17.1.5 and my FreeBSD > firewall! Of course, having to add routes, sort of defeats > the ipfw fwd command, doesn't it? a ``route'' is basically a road from one destination to another (i.e. a way of getting from A to B). Take this scenario, a meeting point in building A has been moved to building B. You have been designated to tell everyone that is coming to building A to go to building B. However, for this to happen there has to be a route (you can see where I'm going now I hope) from building A to building B. perhaps you need to set your default route? OR you need to either add in these static routes, or setup your network and interfaces in such a way as the routes are obvious (subnets, netmasks that kind of thing). Regards, -- Philip Reynolds | Technical Director philip.reynolds@rfc-networks.ie | RFC Networks Ltd. http://www.rfc-networks.ie | +353 (0)1 8832063 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Aug 2 6:56: 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 424B037B400 for ; Fri, 2 Aug 2002 06:55:56 -0700 (PDT) Received: from novaconnect.net (ns.novaconnect.net [205.150.191.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73CB943E81 for ; Fri, 2 Aug 2002 06:55:55 -0700 (PDT) (envelope-from mailing@novaconnect.net) Received: from [64.229.118.242] (account ) by novaconnect.net (CommuniGate Pro WebUser 3.5b5) with HTTP id 45259 for ; Fri, 02 Aug 2002 09:53:28 -0400 From: "Matt Abraham" Subject: Re: "ipfw fwd" not working without static route? To: freebsd-ipfw@freebsd.org X-Mailer: CommuniGate Pro Web Mailer v.3.5b5 Date: Fri, 02 Aug 2002 09:53:28 -0400 Message-ID: In-Reply-To: <20020801231035.B31318@rfc-networks.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit 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 See inline... On Thu, 1 Aug 2002 23:10:35 +0000 Philip Reynolds wrote: > *This message was transferred with a trial version of > CommuniGate(tm) Pro* > Matt Abraham 21 lines of wisdom > included: > > I'm trying to forward all packets from a privately > addressed > > machine (172.17.1.5) to a gateway via a FreeBSD box > running > > ipfw. Here's the ipfw directive: > > > > fwd 192.168.215.15 log logamount 10000 ip from > 172.17.1.5 to > > any > > > > Now when I ping public address a.b.c.d from 172.17.1.5, > I > > get a "Destination Host Unreachable." When I try to > ping > > this same address from the FreeBSD box, I get a "No > route to > > host" message. Adding a static route, however, solves > the > > problem: > > > > route add -net a.b.c.d 192.169.215.15 > > > > ...so now I can ping from both 172.17.1.5 and my > FreeBSD > > firewall! Of course, having to add routes, sort of > defeats > > the ipfw fwd command, doesn't it? > > a ``route'' is basically a road from one destination to > another > (i.e. a way of getting from A to B). > > Take this scenario, a meeting point in building A has > been moved to > building B. You have been designated to tell everyone > that is coming > to building A to go to building B. However, for this to > happen there > has to be a route (you can see where I'm going now I > hope) from > building A to building B. > I think in my case, a better scenario would be that I still want to have the meeting point in building A for everyone EXCEPT those from say, the Purchasing department; those indiviuals should go over to building B. > perhaps you need to set your default route? > > OR > > you need to either add in these static routes, or setup > your network > and interfaces in such a way as the routes are obvious > (subnets, > netmasks that kind of thing). > Now the use of static routes become problematic because the route now only applies to packets that match a certain criteria, namely having a source address of 172.17.1.5. If I modify the netmasks on the box (and not use ipfw fwd), I change the behaviour for all packets coming through...not what I want to do. Matt Abraham mailling@novaconnect.net > Regards, > -- > Philip Reynolds | Technical Director > philip.reynolds@rfc-networks.ie | RFC Networks Ltd. > http://www.rfc-networks.ie | +353 (0)1 8832063 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the > message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Aug 2 23:35: 7 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 40D3E37B401 for ; Fri, 2 Aug 2002 23:35:01 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94A6B43E42 for ; Fri, 2 Aug 2002 23:35:00 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020803063459.TNAI221.sccrmhc02.attbi.com@blossom.cjclark.org>; Sat, 3 Aug 2002 06:34: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 g736YwJK048071; Fri, 2 Aug 2002 23:34: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 g736YwcU048070; Fri, 2 Aug 2002 23:34:58 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Fri, 2 Aug 2002 23:34:57 -0700 From: "Crist J. Clark" To: Matt Abraham Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: "ipfw fwd" not working without static route? Message-ID: <20020803063457.GB47529@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <20020801231035.B31318@rfc-networks.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Fri, Aug 02, 2002 at 09:53:28AM -0400, Matt Abraham wrote: > On Thu, 1 Aug 2002 23:10:35 +0000 > Philip Reynolds wrote: > > Matt Abraham 21 lines of wisdom > > included: > > > I'm trying to forward all packets from a privately > > addressed > > > machine (172.17.1.5) to a gateway via a FreeBSD box > > running > > > ipfw. Here's the ipfw directive: > > > > > > fwd 192.168.215.15 log logamount 10000 ip from > > 172.17.1.5 to > > > any > > > > > > Now when I ping public address a.b.c.d from 172.17.1.5, > > I > > > get a "Destination Host Unreachable." When I try to > > ping > > > this same address from the FreeBSD box, I get a "No > > route to > > > host" message. Adding a static route, however, solves > > the > > > problem: > > > > > > route add -net a.b.c.d 192.169.215.15 > > > > > > ...so now I can ping from both 172.17.1.5 and my > > FreeBSD > > > firewall! Of course, having to add routes, sort of > > defeats > > > the ipfw fwd command, doesn't it? [snip] > Now the use of static routes become problematic because the > route now only applies to packets that match a certain > criteria, namely having a source address of 172.17.1.5. If I > modify the netmasks on the box (and not use ipfw fwd), I > change the behaviour for all packets coming through...not > what I want to do. I believe you can do what you want to do. The 'fwd' directive will override the routing for a packet, BUT there must be a valid route for the packet too. The issue is where ipfw(8) and the routing decision occur in the network stack. The routing decision is made before the packet gets sent to ipfw(8). Since there is no route for the packet, the kernel gives the 'no route to host.' The 'fwd' routing would have later clobbered the original routing choice, but you need to have a route before you get this far. You can just add a bogus route (e.g. default route that goes anywhere as long as it leaves the machine), and your 'fwd' should work how you want. -- 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 Sat Aug 3 0: 3:53 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 726B937B400 for ; Sat, 3 Aug 2002 00:03:50 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 119ED43E42 for ; Sat, 3 Aug 2002 00:03:46 -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 <20020803070342.HNBL19356.rwcrmhc51.attbi.com@blossom.cjclark.org>; Sat, 3 Aug 2002 07:03:42 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g7373fJK048147; Sat, 3 Aug 2002 00:03:41 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g7373eKD048146; Sat, 3 Aug 2002 00:03:40 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Sat, 3 Aug 2002 00:03:40 -0700 From: "Crist J. Clark" To: Joe & Fhe Barbish Cc: FBIPFW Subject: Re: natd & keep-state Message-ID: <20020803070339.GC47529@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Jul 31, 2002 at 10:07:59PM -0400, Joe & Fhe Barbish wrote: > IPFW list members > > Advanced Stateful extensions were introduced in FBSD 4.0. When they > first can out I changed my ipfw rules from stateless and simple > stateful to using only Advanced Stateful rules for my user > ppp -nat ISP connection. The ipfw rule set that works with user > ppp -nat is posted below. I have tried to get this same rules file to > function exchanging user ppp -nat for ipfw natd. There was always > problems with natd ip address and the dynamic rules table getting > mismatches so I went back to user ppp -nat. Every new version of FBSD > I would try again to use natd hopping there may have been some fixes > to natd, but no such luck. Each new version still failed. Each time I > would post questions to the FBSD questions list, but most of the > replies were from people who were having the same problems with natd > and keep-state rules that I was. Well now I am forced to address the > problem again because I now have cable access to the internet and I > can no longer use the -nat function of user ppp. So this time I joined > this ipfw list hoping my post will be read by a larger group of people > who have an very technical understanding of IPFW/NATD and the Advanced > Stateful extensions check-state / keep-state who will be able to > Provide a solution or come to the realization that there is a bug > that needs fixing. Deja vu. I think we've been through this before, http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2858187+0+archive/2002/freebsd-questions/20020217.freebsd-questions There is not a bug. ipfw(8) and natd(8) both work as intended. It happens that 'keep-state' and natd(8) tend not to work very well together without some serious rule gymnastics. But as I think I have mentioned to you before, when you use stateless ipfw(8) rules in combination with natd(8), you can end up with a stateful firewall. It may be easier to do that than try to pound 'keep-state' and natd(8) into submission. -- 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 Sat Aug 3 1:26: 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 475E637B400 for ; Sat, 3 Aug 2002 01:26:01 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1CDD43E5E for ; Sat, 3 Aug 2002 01:26:00 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020803082600.SSPG22139.rwcrmhc52.attbi.com@blossom.cjclark.org> for ; Sat, 3 Aug 2002 08:26:00 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g738Q0JK048600 for ; Sat, 3 Aug 2002 01:26:00 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g738Q01Q048599 for ipfw@freebsd.org; Sat, 3 Aug 2002 01:26:00 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Sat, 3 Aug 2002 01:25:59 -0700 From: "Crist J. Clark" To: ipfw@freebsd.org Subject: CTLFLAG_SECURE patch for ip_fw.c Message-ID: <20020803082559.GF47529@blossom.cjclark.org> Reply-To: "Crist J. Clark" 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 You've asked for patches to ipfw@ in MAINTAINERS, luigi. To kill off PR kern/39396 finally, just secure all of the read-write ipfw(8)-related sysctl(8)s I can find. I've only included the one, but I've got 'em for ip_fw2.c too; the patch is pretty much identical. I'll putt them in both ip_fw{,2}.c in -CURRENT for a couple of days before an MFC to -STABLE. Index: ip_fw.c =================================================================== RCS file: /export/freebsd/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.188 diff -u -r1.188 ip_fw.c --- ip_fw.c 22 Jun 2002 11:51:02 -0000 1.188 +++ ip_fw.c 12 Jul 2002 05:59:29 -0000 @@ -94,19 +94,19 @@ MALLOC_DEFINE(M_IPFW, "IpFw/IpAcct", "IpFw/IpAcct chain's"); #ifdef SYSCTL_NODE -SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW, +SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW | CTLFLAG_SECURE, 0, "Firewall"); +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, enable, CTLFLAG_RW | CTLFLAG_SECURE, &fw_enable, 0, "Enable ipfw"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO,one_pass,CTLFLAG_RW | CTLFLAG_SECURE, &fw_one_pass, 0, "Only do a single pass through ipfw when using dummynet(4)"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, debug, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, debug, CTLFLAG_RW | CTLFLAG_SECURE, &fw_debug, 0, "Enable printing of debug ip_fw statements"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, verbose, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, verbose, CTLFLAG_RW | CTLFLAG_SECURE, &fw_verbose, 0, "Log matches to ipfw rules"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, verbose_limit, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, verbose_limit, CTLFLAG_RW | CTLFLAG_SECURE, &fw_verbose_limit, 0, "Set upper limit of matches of ipfw rules logged"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, permanent_rules, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, permanent_rules, CTLFLAG_RW | CTLFLAG_SECURE, &fw_permanent_rules, 0, "Set rule number, below which rules are permanent"); /* @@ -175,27 +175,27 @@ static u_int32_t dyn_count = 0 ; /* # of dynamic rules */ static u_int32_t dyn_max = 1000 ; /* max # of dynamic rules */ -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_buckets, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_buckets, CTLFLAG_RW | CTLFLAG_SECURE, &dyn_buckets, 0, "Number of dyn. buckets"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, curr_dyn_buckets, CTLFLAG_RD, &curr_dyn_buckets, 0, "Current Number of dyn. buckets"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_count, CTLFLAG_RD, &dyn_count, 0, "Number of dyn. rules"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_max, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_max, CTLFLAG_RW | CTLFLAG_SECURE, &dyn_max, 0, "Max number of dyn. rules"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, static_count, CTLFLAG_RD, &static_count, 0, "Number of static rules"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_ack_lifetime, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_ack_lifetime, CTLFLAG_RW | CTLFLAG_SECURE, &dyn_ack_lifetime, 0, "Lifetime of dyn. rules for acks"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_syn_lifetime, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_syn_lifetime, CTLFLAG_RW | CTLFLAG_SECURE, &dyn_syn_lifetime, 0, "Lifetime of dyn. rules for syn"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_fin_lifetime, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_fin_lifetime, CTLFLAG_RW | CTLFLAG_SECURE, &dyn_fin_lifetime, 0, "Lifetime of dyn. rules for fin"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_rst_lifetime, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_rst_lifetime, CTLFLAG_RW | CTLFLAG_SECURE, &dyn_rst_lifetime, 0, "Lifetime of dyn. rules for rst"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_udp_lifetime, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_udp_lifetime, CTLFLAG_RW | CTLFLAG_SECURE, &dyn_udp_lifetime, 0, "Lifetime of dyn. rules for UDP"); -SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_short_lifetime, CTLFLAG_RW, +SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_short_lifetime, CTLFLAG_RW | CTLFLAG_SECURE, &dyn_short_lifetime, 0, "Lifetime of dyn. rules for other situations"); SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_grace_time, CTLFLAG_RD, &dyn_grace_time, 0, "Grace time for dyn. rules"); -- 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 Sat Aug 3 2: 9: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 B20AA37B645; Sat, 3 Aug 2002 02:09:34 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1C7F44031; Sat, 3 Aug 2002 02:03:12 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g738pFX94144; Sat, 3 Aug 2002 01:51:15 -0700 (PDT) (envelope-from rizzo) Date: Sat, 3 Aug 2002 01:51:15 -0700 From: Luigi Rizzo To: "Crist J. Clark" Cc: ipfw@FreeBSD.ORG Subject: Re: CTLFLAG_SECURE patch for ip_fw.c Message-ID: <20020803015114.A94060@iguana.icir.org> References: <20020803082559.GF47529@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: <20020803082559.GF47529@blossom.cjclark.org>; from crist.clark@attbi.com on Sat, Aug 03, 2002 at 01:25:59AM -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 Thanks, but I have a few comments here: * ip_fw.c in -current is basically dead, so you can leave it untouched. * There are two more related variables, one in net/bridge.c and the other one in net/if_ethersubr.c, which control ipfw filtering of bridged and layer-2 packets, they should be updated as well; * net.inet.ip.fw.debug should be left alone, it does not do anything critical; * maybe net.inet.ip.fw.verbose_limit should be left unsecured as well, as i believe there might be cases where you want to change it to a different value e.g. under attack. * all dyn_* variables should be unsecured, because again you might want to tune them dynamically. thanks luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 8: 6: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 04FA037B400 for ; Sat, 3 Aug 2002 08:06:14 -0700 (PDT) Received: from moscow.plug-it.com (moscow.plug-it.com [62.212.108.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3681743E3B for ; Sat, 3 Aug 2002 08:06:10 -0700 (PDT) (envelope-from eberkut@minithins.net) Received: from funel (AC946DF8.ipt.aol.com [172.148.109.248]) (authenticated bits=0) by moscow.plug-it.com (8.12.5/8.12.5) with ESMTP id g73EvUR1004410 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 3 Aug 2002 16:58:58 +0200 Reply-To: From: "eberkut" To: Subject: timeout Date: Sat, 3 Aug 2002 17:06:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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, Is there any chances to see the lifetime patch integrated into freebsd ? This patch is very useful to enforce timeout for connections and there is a version for IPFW2 against -stable. http://www.aarongifford.com/computers/ipfwpatch.html Also there is a type of timeout features which could be useful both for security or state track tuning, those similar to Cisco's CBAC global timeouts or the pf.conf's set timeout options (see http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secu r_c/scprt3/scdcbac.htm#xtocid27 and pf.conf(5) readable on openbsd.org). Specially, CBAC does a great work against syn flood & co. Some options may also be useful against scan. And one can use state timeout to agressively drop unresponsive/congested/slow connections. just a few feature suggestions ;) --eberkut Semper ego auditor tantum ? Nunquamne reponam ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 9: 5:29 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 01E0C37B400 for ; Sat, 3 Aug 2002 09:05:24 -0700 (PDT) Received: from apex.dp.ua (bagira.apex.dp.ua [195.24.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68BEF43E4A for ; Sat, 3 Aug 2002 09:05:18 -0700 (PDT) (envelope-from valik@apex.dp.ua) Received: from zhome (zaretsky.apex.dp.ua [212.3.110.34] (may be forged)) by apex.dp.ua (8.11.6/8.11.6) with SMTP id g73G5Ck95305; Sat, 3 Aug 2002 19:05:13 +0300 (EEST) (envelope-from valik@apex.dp.ua) Message-ID: <007601c23b07$8c667550$226e03d4@zhome> From: "Valentine Zaretsky" To: Cc: "Luigi Rizzo" Subject: ipfw2 & dummynet Date: Sat, 3 Aug 2002 19:05:08 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01C23B20.AF580A10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 FL-Build: Fidolook Express 2000 UIExt. BuildID: 3BC00FAD (7/10/2001 11:17:49). 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 This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C23B20.AF580A10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Playing with ipfw2 in -stable (last time cvsup'ed yesterday), I found a = bug when using dummynet pipes and queues Here is the simplest example to repeat it: ipfw pipe 1 config bw 20KBytes/s ipfw add 400 pipe 1 ip from any to me The first packet matching rule 400 leads to kernel panic caused by = "division by zero" Analyzing crashdump with gdb, I found that it happens in the following = code in /usr/src/sys/netinet/ip_dummynet.c: (lines 1198-1205) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D if (DN_KEY_GT(q->S, q->F)) { /* means timestamps are invalid */ q->S =3D pipe->V ; pipe->sum +=3D fs->weight ; /* add weight of new queue */ } else { heap_extract(&(pipe->idle_heap), q); q->S =3D MAX64(q->F, pipe->V ) ; } q->F =3D q->S + ( len<weight; =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D So the weight is 0 when it should be 1.=20 And it's not quite understood why should this code execute at all? There = is no queues (only simple pipe, so "is_pipe" should be 1) Adding dumb "if(fs->weight=3D=3D0) fs->weight=3D1;" before the code = above, fixes this kernel panic. I think it could/should be fixed a little smarter ;) -- With best regards, Valentine Zaretsky ------=_NextPart_000_0073_01C23B20.AF580A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Playing with ipfw2 in -stable (last time cvsup'ed = yesterday),=20 I found a bug when using dummynet pipes and queues
 
Here is the simplest example to repeat = it:
 
ipfw pipe 1 config bw 20KBytes/s
ipfw add 400 pipe 1 ip from any to me
 
The first packet matching rule 400 leads to = kernel=20 panic caused by "division by zero"
 
Analyzing crashdump with gdb, I found that it = happens in the=20 following code in /usr/src/sys/netinet/ip_dummynet.c:
(lines 1198-1205)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
        if=20 (DN_KEY_GT(q->S, q->F)) { /* means timestamps are invalid=20 */
            = q->S=20 =3D pipe->V=20 ;
           =20 pipe->sum +=3D fs->weight ; /* add weight of new queue=20 */
        } else=20 {
           =20 heap_extract(&(pipe->idle_heap),=20 q);
           = =20 q->S =3D MAX64(q->F, pipe->V )=20 ;
       =20 }
        q->F =3D q->S + (=20 len<<MY_M )/(u_int64_t) = fs->weight;     =20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
 
So the weight is 0 when it should be 1. =
And it's not quite understood why should this=20 code execute at all? There is no queues (only simple = pipe, so=20 "is_pipe" should be 1)
 
Adding dumb "if(fs->weight=3D=3D0) = fs->weight=3D1;"=20 before the code above, fixes this kernel panic.
 
I think it could/should be fixed a = little=20 smarter ;)
 
--
With best regards, Valentine Zaretsky
 
 
------=_NextPart_000_0073_01C23B20.AF580A10-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 10: 0: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 10C3037B401 for ; Sat, 3 Aug 2002 10:00:26 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 310FF43E5E for ; Sat, 3 Aug 2002 10:00:25 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g73H09i01121; Sat, 3 Aug 2002 10:00:09 -0700 (PDT) (envelope-from rizzo) Date: Sat, 3 Aug 2002 10:00:09 -0700 From: Luigi Rizzo To: Valentine Zaretsky Cc: ipfw@FreeBSD.ORG Subject: Re: ipfw2 & dummynet Message-ID: <20020803100008.A98813@iguana.icir.org> References: <007601c23b07$8c667550$226e03d4@zhome> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <007601c23b07$8c667550$226e03d4@zhome>; from valik@apex.dp.ua on Sat, Aug 03, 2002 at 07:05:08PM +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 good catch :) The problem was in fact a missing #include "opt_ipdn.h" to let us know whether we are being compiled for the old ipfw or for IPFW2. Without that, compilation defaulted to ipfw, resulting in a number of erroneous manipulations of data. Just committed a fix, thanks luigi On Sat, Aug 03, 2002 at 07:05:08PM +0300, Valentine Zaretsky wrote: > Hi, > > Playing with ipfw2 in -stable (last time cvsup'ed yesterday), I found a bug when using dummynet pipes and queues > > Here is the simplest example to repeat it: > > ipfw pipe 1 config bw 20KBytes/s > ipfw add 400 pipe 1 ip from any to me > > The first packet matching rule 400 leads to kernel panic caused by "division by zero" > > Analyzing crashdump with gdb, I found that it happens in the following code in /usr/src/sys/netinet/ip_dummynet.c: > (lines 1198-1205) > ============================== > if (DN_KEY_GT(q->S, q->F)) { /* means timestamps are invalid */ > q->S = pipe->V ; > pipe->sum += fs->weight ; /* add weight of new queue */ > } else { > heap_extract(&(pipe->idle_heap), q); > q->S = MAX64(q->F, pipe->V ) ; > } > q->F = q->S + ( len<weight; > ============================== > > So the weight is 0 when it should be 1. > And it's not quite understood why should this code execute at all? There is no queues (only simple pipe, so "is_pipe" should be 1) > > Adding dumb "if(fs->weight==0) fs->weight=1;" before the code above, fixes this kernel panic. > > I think it could/should be fixed a little smarter ;) > > -- > With best regards, Valentine Zaretsky > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 11:18:30 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 7CDCA37B400; Sat, 3 Aug 2002 11:18:19 -0700 (PDT) Received: from smtp.a1poweruser.com (oh-chardon6a-62.clvhoh.adelphia.net [68.65.175.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB4DB43E4A; Sat, 3 Aug 2002 11:18:17 -0700 (PDT) (envelope-from barbish@a1poweruser.com) Received: from barbish (lanwin1 [10.0.10.6]) by smtp.a1poweruser.com (Postfix) with SMTP id BF8B12E; Sat, 3 Aug 2002 14:22:10 -0400 (EDT) Reply-To: From: "Joe & Fhe Barbish" To: "Crist J. Clark" Cc: "FBIPFW" , , , , , , , , Subject: RE: natd & keep-state Date: Sat, 3 Aug 2002 14:18:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020803070339.GC47529@blossom.cjclark.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 So Crist we meet again. And yes you and I have been over this subject before in the FBSD-questions list. All you do is state your personal opinion that natd and keep-state works and not accept the possibility that you may be wrong. I have proven it does not by examples I have sent you in the past. You explained very nicely in http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2858187+0+archive/2002/freebsd- questions/20020217.freebsd-questions exactly what natd's problem is. I have gotten the ipfw rule set posted in the original post which started this thread to work with user ppp -nat ,ipnat and on a FBSD firewall box with no lan behind it. But it will not work with NATD. One does not have to be a genus to see that this proves there is something wrong with NATD. Crist I quote you "There is not a bug. ipfw(8) and natd(8) both work as intended. It happens that 'keep-state' and natd(8) tend not to work very well together without some serious rule gymnastics. But as I think I have mentioned to you before, when you use stateless ipfw(8) rules in combination with natd(8), you can end up with a stateful firewall. It may be easier to do that than try to pound 'keep-state' and natd(8) into submission." End quote. Let me point out to you Crist. My rule set does not use any stateless Rules or any kind of rule gymnastics to work as documented by the man pages when user ppp -nat or ipnat is used, or when there is no lan behind the IPFW firewall needing NAT services. It just does not make logical sense that natd should not function in the same manner. In my opinion, what you have stated above proves NATD does indeed contain bugs when it encounters keep-state rules and further supports my cause. The author of the keep-state option saw the need in ipfw to provide a more complete security protection of the bi-directional exchange of packets during the session conversation so fraudulent packets could not be inserted into the session conversation undetected. There was never any intent to accomplish this function with the assistance of stateless rules or rule gymnastics. That fact is proven by my keep-state rules only based rules file working when natd is not used. The evidence and even your own words conflicts with your personal opinion. On this subject your opinion has no creditable in my eyes. I have posted to this list group seeking help from a wider audience of people who are suppose to have expertise in the internals of ipfw/natd. I am of the opinion ipfw keep-state rules on individual selection rules do not function when used with the IPFW's built in natd function. Ipfw is continuously being released to the general public with out adequately being tested or this would have been found and fixed all ready. You write a lot of words, which is suppose to back up your position, but all they do is clarify my position. You have never made the effort to test my rules file for your self and provide me with a working rule set without stateless rules or coding gymnastics to prove your point that natd & keep-state rules work and I am wrong. That's what's it's going to take to get me to drop this subject. I stand on this point, prove me wrong in the form of an working rule set or admit natd is not functioning correctly and create a bug report to get it fixed. I have previous posted a bug report on this problem and you were the one who serviced that bug report and decided that this is not a problem. I think your lack of comprehending the impact this problem has on the effort to move keep-state only firewalls into the mainline of the user community to provide them with the maximum level of protection is a dis-service to the FBSD community. As I told you before, I believe cutting the natd code out of the parent ipfw program and making it an stand-a-lone function so it gets control at the same time user ppp -nat and ipnat does is the solution to this problem. It will also remove all the confusion surrounding the divert natd rule and felicitate the standardization on keep-state ipfw firewall rule sets. There is far to much emphasizes put on stateless rules and rules files coding logic based on the setup/established flags as simple stateful rules. Would like to see these two rule concepts documented as deprecated and the Advanced Stateful extensions check-state / keep-state rule concept being emphasized as the preferred ipfw rule method. IPFILTER/IPNAT all ready provides the users this level of protection. Can YOU rise to the challenge? Now don't go off the deep end, this is not a flame. I am just stating my own observations and opinions. Opinions are like assholes, everybody has one. The freedom to voice our opinions and to disagree with other peoples opinions is what this list group is all about. This is where we the FBSD user community are chartered to discuss this type of subject. More heads besides just mine and yours Crist have to address this problem. Help me get the people you know who maintain natd & ipfw to participate. They have to look into the ipfw/natd source code to design a solution. Maybe this change can be combined/included with the ipfw2 effort. I want to provoke participation by the authors of natd. Get agreement natd has a bug. Get it fixed for version 5.0. What harm is there in those goals? Joe Below is my original post for those who are just now join this thread. IPFW list members Advanced Stateful extensions were introduced in FBSD 4.0. When they first can out I changed my ipfw rules from stateless and simple stateful to using only Advanced Stateful rules for my user ppp -nat ISP connection. The ipfw rule set that works with user ppp -nat is posted below. I have tried to get this same rules file to function exchanging user ppp -nat for ipfw natd. There was always problems with natd ip address and the dynamic rules table getting mismatches so I went back to user ppp -nat. Every new version of FBSD I would try again to use natd hopping there may have been some fixes to natd, but no such luck. Each new version still failed. Each time I would post questions to the FBSD questions list, but most of the replies were from people who were having the same problems with natd and keep-state rules that I was. Well now I am forced to address the problem again because I now have cable access to the internet and I can no longer use the -nat function of user ppp. So this time I joined this ipfw list hoping my post will be read by a larger group of people who have an very technical understanding of IPFW/NATD and the Advanced Stateful extensions check-state / keep-state who will be able to Provide a solution or come to the realization that there is a bug that needs fixing. The following posted rules are the rules file that works just fine using user ppp -nat. As you can see it is very basic but demonstrates the logic flow of only allowing selected functions to be started for access to the public internet and selected functions originating from the public internet to be started for access to the local network. To use these rules for NATD I change xif="tun0" to xif="rl0" which is the Nic card cabled to the cable modem. odns1 & odns2 to the ip address of the cable providers dns servers. And add the $cmd 200 divert natd all from any to any via $xif as rule number 200 so it gets positioned before the check-state statement. The positioning of the divert statement is patterned after the /etc/rc.firewall sample. Be assured that the rc.conf and kernel options are in place to activate NATD. I an now using FBSD version 4.6. I have read and reread the ipfw man pages until I an blue in the face. I am not a newbe to FBSD or IPFW and post this in hopes of achieving a real solution in the way of a working ipfw/natd rules file based on my rules file below. I have chosen functions which should be easy for you to test on your own systems. Thanks for your help in this matter Joe # Flush out the list before we begin. /sbin/ipfw -q -f flush # Set rules command prefix # The -q option on the command is for quite mode. # Do not display rules as they load. Remove during development to see. #cmd="/sbin/ipfw -q add" cmd="/sbin/ipfw add" # Set defaults # set these to your external interface network xif="tun0" odns1="218.216.115.111" # ISP's dns server 1 IP address odns2="218.216.115.112" # ISP's dns server 2 IP address # Set these to your inside interface network iif="xl0" # Nic card # Internal gateway housekeeping $cmd 100 allow all from any to any via lo0 # allow all localhost $cmd 150 deny all from any to 127.0.0.0/8 # deny use of localhost IP $cmd 160 deny all from 127.0.0.0/8 to any # deny use of localhost IP $cmd 180 allow all from any to any via $iif # allow all local LAN ######## control section ############################################ $cmd 500 check-state # Deny & log all fragments as bogus packets $cmd 502 deny log all from any to any frag via $xif # Deny & log ACK packets that did not match the dynamic rule table $cmd 501 deny log tcp from any to any established via $xif ######## outbound section ########################################### # Interrogate packets originating from behind the firewall, private net. # Upon a rule match, it's keep-state option will create a dynamic rule. # Allow out www function $cmd 600 allow tcp from any to any 80 out via $xif setup keep-state # Allow out access to my ISP's Domain name server. $cmd 610 allow tcp from any to $odns1 53 out via $xif setup keep-state $cmd 611 allow udp from any to $odns1 53 out via $xif keep-state $cmd 615 allow tcp from any to $odns2 53 out via $xif setup keep-state $cmd 616 allow udp from any to $odns2 53 out via $xif keep-state # Allow out send & get email function $cmd 630 allow tcp from any to any 25,110 out via $xif setup keep-state # Allow out & in FBSD (make install & CVSUP) functions # Basically give user id root "GOD" privileges. $cmd 640 allow tcp from me to any out via $xif setup keep-state uid root # Allow out ping $cmd 650 allow icmp from any to any out via $xif keep-state # Allow out TELNET $cmd 660 allow tcp from any to any 23 out via $xif setup keep-state ############ passive FTP rules for LAN PC FTP to public Internet ###### # Allow passive FTP control channel 21 & data high ports $cmd 700 allow tcp from any to any 21 out via $xif setup keep-state $cmd 710 allow tcp from any to any 10000-65000 out via $xif setup keep-state ##### End of passive FTP rules for LAN PC FTP to public Internet ###### ######## inbound section ############################################ # Allow in www $cmd 800 allow tcp from any to any 80 in via $xif setup limit src-addr 4 # Allow in ssh function $cmd 820 allow log tcp from any to me 22 in via $xif setup limit src-addr 4 # Allow in Telnet $cmd 830 allow tcp from any to any 23 in via $xif setup limit src-addr 4 #$cmd 830 allow tcp from any to any 23 in via $xif setup keep-state ######## catch all section ############################################ # Stop & log external redirect requests. $cmd 845 deny log icmp from any to any icmptype 5 in via $xif # Stop & log spoofing Attack attempts. $cmd 850 deny log ip from me to me in via $xif # Stop & log ping echo attacks # stop echo reply (ICMP type 0), and echo request (type 8). $cmd 860 deny log icmp from any to me icmptype 0,8 in via $xif # Reject & Log all setup of incoming connections from the outside $cmd 900 deny log tcp from any to any setup in via $xif # Everything else is denied by default # deny and log all packets that fall through to see what they are $cmd 910 deny log logamount 500 all from any to any ####################################################################### -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Crist J. Clark Sent: Saturday, August 03, 2002 3:04 AM To: Joe & Fhe Barbish Cc: FBIPFW Subject: Re: natd & keep-state On Wed, Jul 31, 2002 at 10:07:59PM -0400, Joe & Fhe Barbish wrote: > IPFW list members > > Advanced Stateful extensions were introduced in FBSD 4.0. When they > first can out I changed my ipfw rules from stateless and simple > stateful to using only Advanced Stateful rules for my user > ppp -nat ISP connection. The ipfw rule set that works with user > ppp -nat is posted below. I have tried to get this same rules file to > function exchanging user ppp -nat for ipfw natd. There was always > problems with natd ip address and the dynamic rules table getting > mismatches so I went back to user ppp -nat. Every new version of FBSD > I would try again to use natd hopping there may have been some fixes > to natd, but no such luck. Each new version still failed. Each time I > would post questions to the FBSD questions list, but most of the > replies were from people who were having the same problems with natd > and keep-state rules that I was. Well now I am forced to address the > problem again because I now have cable access to the internet and I > can no longer use the -nat function of user ppp. So this time I joined > this ipfw list hoping my post will be read by a larger group of people > who have an very technical understanding of IPFW/NATD and the Advanced > Stateful extensions check-state / keep-state who will be able to > Provide a solution or come to the realization that there is a bug > that needs fixing. Deja vu. I think we've been through this before, http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2858187+0+archive/2002/freebsd- questions/20020217.freebsd-questions There is not a bug. ipfw(8) and natd(8) both work as intended. It happens that 'keep-state' and natd(8) tend not to work very well together without some serious rule gymnastics. But as I think I have mentioned to you before, when you use stateless ipfw(8) rules in combination with natd(8), you can end up with a stateful firewall. It may be easier to do that than try to pound 'keep-state' and natd(8) into submission. -- 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 12:21: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 4288037B400 for ; Sat, 3 Aug 2002 12:21:13 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 8D30143E3B for ; Sat, 3 Aug 2002 12:21:01 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 15672 invoked from network); 3 Aug 2002 19:21:00 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 3 Aug 2002 19:21:00 -0000 Message-ID: <3D4C2D1C.5020900@tenebras.com> Date: Sat, 03 Aug 2002 12:21:00 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020717 X-Accept-Language: en-us, en, fr-fr, ru MIME-Version: 1.0 To: barbish@a1poweruser.com Cc: "Crist J. Clark" , FBIPFW , archie@whistle.com, cmott@scientech.com, perhaps@yes.no, suutari@iki.fi, dnelson@redwoodsoft.com, brian@awfulhak.org, ru@FreeBSD.org, rizzo@icir.org Subject: Re: natd & keep-state References: 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 Joe & Fhe Barbish wrote: > So Crist we meet again. [scads of drivel deleted] As Crist stated, ipfw stateful rules and natd aren't inherently compatible, but it is possible to use them together. This is facilitated by using at least two IP addresses on the outside interface, and some non-intuitive rules. A brief snippet: # fw="/sbin/ipfw -q" ipaddr1="145.X.X.12" ipaddr2="145.X.X.14" # some rules skipped for this example #note the asymmetry $fw add 02000 divert natd ip from any to $ipaddr2 in recv $oif $fw add 02000 divert natd ip from any to any out xmit $oif $fw add 02400 check-state $fw add 02500 allow icmp from any to any icmptype 0,3,8,11 # natd is invoked with 'deny_incoming' $fw add 02620 allow ip from $ipaddr2 to any $fw add 02630 allow ip from any to $ipaddr2 $fw add 05800 allow udp from $ipaddr1 to any keep-state $fw add 05900 allow tcp from $ipaddr1 to any setup keep-state $fw add 65000 deny ip from any to any ~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 12:58: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 C9C6937B400; Sat, 3 Aug 2002 12:58:49 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74D8F43E42; Sat, 3 Aug 2002 12:58:49 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g73Jwlr02402; Sat, 3 Aug 2002 12:58:47 -0700 (PDT) (envelope-from rizzo) Date: Sat, 3 Aug 2002 12:58:47 -0700 From: Luigi Rizzo To: Joe & Fhe Barbish Cc: "Crist J. Clark" , FBIPFW , archie@whistle.com, cmott@scientech.com, perhaps@yes.no, suutari@iki.fi, dnelson@redwoodsoft.com, brian@awfulhak.org, ru@FreeBSD.ORG Subject: Re: natd & keep-state Message-ID: <20020803125847.B2239@iguana.icir.org> References: <20020803070339.GC47529@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: ; from barbish@a1poweruser.com on Sat, Aug 03, 2002 at 02:18:14PM -0400 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 tried to stay out of this pointless thread, but given that I have been indirectly mentioned > ... > The author of the keep-state option saw the need in ipfw to provide a > more complete security protection of the bi-directional exchange of > packets during the session conversation so fraudulent packets could not > ... stateful rules do, in terms of filtering, pretty much the same work that natd and "ppp -alias" do (the latter two using the same library, namely libalias). You may want them when you don't use natd/ppp-alias, and you certainly don't want them when you use natd/ppp-alias. I see no point in trying to write ipfw rulesets to make keep-state and natd work together, as it gives you absolutely no additional protection. Nor i see any obligation for anyone to prove or disprove that they can work together. It can be done, it is non trivial, and you need to have a very good understanding on how packets flow through the protocol stack. It is slightly easier to make stateful ipfw rules work together with "ppp -alias" because the latter does not reinject packets into the protocol stack as natd does. But other than that, there is no bug in ipfw or natd related to this issue. If what you are claiming is that we need in-kernel nat functionality, yes we do, so would you like to write one ? Otherwise just be quiet and patient and wait until someone comes up with one. > Help me get the people you know who maintain natd & ipfw to participate. > They have to look into the ipfw/natd source code to design a solution. > Maybe this change can be combined/included with the ipfw2 effort. Continuously posting the same email to the list is just going to provoke the opposite of what you want. And you have already succeeded with me. out of this thread. luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 13:15: 6 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 52B1837B400; Sat, 3 Aug 2002 13:15:01 -0700 (PDT) Received: from smtp.a1poweruser.com (oh-chardon6a-62.clvhoh.adelphia.net [68.65.175.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id C490B43E65; Sat, 3 Aug 2002 13:14:59 -0700 (PDT) (envelope-from barbish@a1poweruser.com) Received: from barbish (lanwin1 [10.0.10.6]) by smtp.a1poweruser.com (Postfix) with SMTP id AF12A2E; Sat, 3 Aug 2002 16:18:53 -0400 (EDT) Reply-To: From: "Joe & Fhe Barbish" To: "Michael Sierchio" Cc: "Crist J. Clark" , "FBIPFW" , , , , , , , , Subject: RE: natd & keep-state Date: Sat, 3 Aug 2002 16:14:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3D4C2D1C.5020900@tenebras.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 Michael You give an example based on having two ip addresses on my outside interface. The outside address is that single ip address assigned by my ISP. Your keep-state rules are generic allowing no selection by port number or the direction the packet is traveling, IE. entering my private network from the public internet or leaving my private network for the public internet. I need selection control allowing only certain types of packets. Please clarify what you are talking about and make your changes to my posted rules file so we stay on the same page when discussing solutions. Thanks Joe -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Michael Sierchio Sent: Saturday, August 03, 2002 3:21 PM To: barbish@a1poweruser.com Cc: Crist J. Clark; FBIPFW; archie@whistle.com; cmott@scientech.com; perhaps@yes.no; suutari@iki.fi; dnelson@redwoodsoft.com; brian@awfulhak.org; ru@FreeBSD.org; rizzo@icir.org Subject: Re: natd & keep-state Joe & Fhe Barbish wrote: > So Crist we meet again. [scads of drivel deleted] As Crist stated, ipfw stateful rules and natd aren't inherently compatible, but it is possible to use them together. This is facilitated by using at least two IP addresses on the outside interface, and some non-intuitive rules. A brief snippet: # fw="/sbin/ipfw -q" ipaddr1="145.X.X.12" ipaddr2="145.X.X.14" # some rules skipped for this example #note the asymmetry $fw add 02000 divert natd ip from any to $ipaddr2 in recv $oif $fw add 02000 divert natd ip from any to any out xmit $oif $fw add 02400 check-state $fw add 02500 allow icmp from any to any icmptype 0,3,8,11 # natd is invoked with 'deny_incoming' $fw add 02620 allow ip from $ipaddr2 to any $fw add 02630 allow ip from any to $ipaddr2 $fw add 05800 allow udp from $ipaddr1 to any keep-state $fw add 05900 allow tcp from $ipaddr1 to any setup keep-state $fw add 65000 deny ip from any to any ~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 14:29:15 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 A478237B400; Sat, 3 Aug 2002 14:29:05 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id E96F543E65; Sat, 3 Aug 2002 14:29:04 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020803212904.TTDL22139.rwcrmhc52.attbi.com@blossom.cjclark.org>; Sat, 3 Aug 2002 21:29:04 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g73LT2JK056103; Sat, 3 Aug 2002 14:29: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 g73LSt0U056102; Sat, 3 Aug 2002 14:28:55 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Sat, 3 Aug 2002 14:28:54 -0700 From: "Crist J. Clark" To: Joe & Fhe Barbish Cc: FBIPFW , archie@whistle.com, cmott@scientech.com, perhaps@yes.no, suutari@iki.fi, dnelson@redwoodsoft.com, brian@awfulhak.org, ru@FreeBSD.ORG, rizzo@icir.org Subject: Re: natd & keep-state Message-ID: <20020803212854.GA55652@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020803070339.GC47529@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Sat, Aug 03, 2002 at 02:18:14PM -0400, Joe & Fhe Barbish wrote: > So Crist we meet again. And yes you and I have been over this subject > before in the FBSD-questions list. All you do is state your personal > opinion that natd and keep-state works and not accept the possibility > that you may be wrong. I have proven it does not by examples I have sent > you in the past. You explained very nicely in > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2858187+0+archive/2002/freebsd- > questions/20020217.freebsd-questions exactly what natd's problem is. > > I have gotten the ipfw rule set posted in the original post which > started this thread to work with user ppp -nat ,ipnat and on a FBSD > firewall box with no lan behind it. > But it will not work with NATD. One does not have to be a genus > to see that this proves there is something wrong with NATD. Right, I told you to use 'ppp -nat' since it you don't run into this problem. The problem is, as I have shown over and over, that when you use natd(8), the source or destination of a NATed packet change mid-way through a set of firewall rules. This is how natd(8) works. This is how natd(8), using divert(4) is _supposed_ to work. However, the fact that addresses change and how they change depends on the direction (in or out of the firewall) makes this _feature_ (not bug) of natd(8)-divert(4)-ipfw(8) interaction not play well with 'keep-state' rules. But when you use 'ppp -nat' the NAT step no longer takes place in the firewall rules at all. The rules, the 'keep-state' rules in particular, always see the packets with internal addresses still on them. Thus, 'keep-state' rules work with no problems. (Note that this is also how IPFilter works. All of the NAT takes place before or after the packets go through the filter rules.) > Crist I quote you > "There is not a bug. ipfw(8) and natd(8) both work as intended. It > happens that 'keep-state' and natd(8) tend not to work very well > together without some serious rule gymnastics. > > But as I think I have mentioned to you before, when you use stateless > ipfw(8) rules in combination with natd(8), you can end up with a > stateful firewall. It may be easier to do that than try to pound > 'keep-state' and natd(8) into submission." End quote. > > Let me point out to you Crist. My rule set does not use any stateless > Rules or any kind of rule gymnastics to work as documented by the man > pages when user ppp -nat or ipnat is used, or when there is no lan > behind the IPFW firewall needing NAT services. Right, for the reasons I have explained several times. > It just does not make logical sense that natd should not function in > the same manner. In my opinion, what you have stated above proves NATD > does indeed contain bugs when it encounters keep-state rules and > further supports my cause. Again, everything is working how is was designed to. The _designs_ of doing NAT with natd(8)-divert(4)-ipfw(8) and using 'keep-state' rules do not work well. It's not a bug in the program. The systems were never designed with compatibility in mind. > The author of the keep-state option saw the need in ipfw to provide a > more complete security protection of the bi-directional exchange of > packets during the session conversation so fraudulent packets could not > be inserted into the session conversation undetected. Sure you can. Anyone who can sniff a connection can insert stuff into a vanilla TCP session. There is no way to stop that with firewall rules. 'keep-state' rules prevent packets not associated with a particular TCP session from passing the firewall. That is, I cannot pass a random ACK packet through a firewall using 'keep-state' rules. > There was never > any intent to accomplish this function with the assistance of stateless > rules or rule gymnastics. And there was no intent to make any special features to get it to work with natd(8). > That fact is proven by my keep-state rules > only based rules file working when natd is not used. Yep, they work as intended. > The evidence and even your own words conflicts with your personal opinion. I don't see how. > On this subject your opinion has no creditable in my eyes. Fine, whatever. But the ipfw(8) and natd(8) developers seem to hold the same opinion. Maybe if you proposed some possible way for natd(8) and 'keep-state' rules to work well together someone could do it. > I have posted to this list group seeking help from a wider audience of > people who are suppose to have expertise in the internals of ipfw/natd. > > I am of the opinion ipfw keep-state rules on individual selection rules > do not function when used with the IPFW's built in natd function. > Ipfw is continuously being released to the general public with out > adequately being tested or this would have been found and fixed all > ready. See the archive. People post with this problem/question several times per month. And they get the same answer you do. > You write a lot of words, which is suppose to back up your position, > but all they do is clarify my position. You have never made the effort > to test my rules file for your self I don't have to. I can read them and see that, like you say, they wouldn't work. > and provide me with a working rule > set without stateless rules or coding gymnastics to prove your point that > natd & keep-state rules work and I am wrong. The following partial ruleset shows what worked fine for me for years, add divert natd ip from any to any add tcp from any to any 80 keep-state out via $xif add tcp from any to any 80 keep-state in via $iif But this won't work right for everyone or for every service. It does pretty well for something like HTTP. > That's what's it's going to take to get me to drop this subject. For someone else to write your ruleset for you? And for them to not write a ruleset that merely applies your security policy properly, but applies your policy _and_ tries to use certain features purely for the sake of using them? > I stand on this point, prove me wrong in the form of an working rule > set or admit natd is not functioning correctly and create a bug report > to get it fixed. *sigh* ONE MORE TIME. natd(8)-diver(4)-ipfw(8) works as designed, so there is no bug. ipfw(8) 'keep-state' works as designed, so there is no bug. The two WERE NEVER DESIGNED TO BE USED TOGETHER, so there is no bug. No one ever told you that they would work well together. My PC's CDROM doesn't play DVDs. I would like it to, but it is not a bug because of that. It was not designed to play DVDs, and no one ever told me that it would. > I have previous posted a bug report on this problem and you were the > one who serviced that bug report and decided that this is not a problem. > I think your lack of comprehending the impact this problem has on the > effort to move keep-state only firewalls into the mainline of the user > community to provide them with the maximum level of protection is a > dis-service to the FBSD community. Talk to luigi, the ipfw(8) maintainer, or ru, the natd(8) maintainer, and see what they say then. As I said before, if you or someone else has thought of a good way to get 'keep-state' and natd(8) to work well together, send in the patches or the plan. > As I told you before, I believe cutting the natd code out of the > parent ipfw program This is just it, natd(8) really has no direct ties to ipfw(8) at all. natd(8) is a daemon that runs out in userland. ipfw(8) is a command that tinkers with the firewall ruleset in the kernel. The firewall ruleset and natd(8) really don't have any interaction except for passing data (the raw packets) back and forth over a divert(4) socket. This fundamental lack of understanding makes it clear why you don't understand how I can say that everything works as designed. > and making it an stand-a-lone function so it gets > control at the same time user ppp -nat and ipnat does is the > solution to this problem. It will also remove all the confusion > surrounding the divert natd rule and felicitate the standardization > on keep-state ipfw firewall rule sets. But it would not be natd(8) anymore. It would have to be some completely new mechanism that does NAT in the kernel. Either that or you would need hooks out to userland somewhere else (like ppp(8) has). Yeah, it'd be cool to have that. You can (a) write the code up to do this yourself, (b) pay someone else to write the code up, or (c) find someone to volunteer to do (a) or (b). Just wishing for it will not make it happen. Sending long winded messages to mail lists trying to label your desired new features as an existing bug will not necessarily do it either. > There is far to much emphasizes > put on stateless rules and rules files coding logic based on the > setup/established flags as simple stateful rules. Would like to see > these two rule concepts documented as deprecated and the Advanced > Stateful extensions check-state / keep-state rule concept being > emphasized as the preferred ipfw rule method. IPFILTER/IPNAT all ready > provides the users this level of protection. > > Can YOU rise to the challenge? I could, but I don't need to. I don't need to write new code to do what I want with firewalls. Everything I need is there. Maybe if hadn't gotten back to fulltime work, I could do it for kicks, but not when I sit at a computer dealing with networking and firewalls all day at work. > Now don't go off the deep end, this is not a flame. I am just stating > my own observations and opinions. Opinions are like assholes, everybody > has one. The freedom to voice our opinions and to disagree with other > peoples opinions is what this list group is all about. This is where we > the FBSD user community are chartered to discuss this type of subject. > More heads besides just mine and yours Crist have to address this problem. > > Help me get the people you know who maintain natd & ipfw to participate. *wave* Hi, ru. Hi, luigi. > They have to look into the ipfw/natd source code to design a solution. They _have to?_ > Maybe this change can be combined/included with the ipfw2 effort. If you put NAT in ipfw(8), you wouldn't need natd(8) at all. There are some new rule types and features you could add to ipfw(8) to make rule gymnastics easier, but you would still need gymnastics (e.g. a rule action that establishes a dynamic rule, but does not accept the packet and lets it continue through the ruleset might help). > I want to provoke participation by the authors of natd. > Get agreement natd has a bug. You want to depricate natd(8). > Get it fixed for version 5.0. > What harm is there in those goals? Harm? Introducing new code is usually somewhat of a security hazard. The question is actually, "What is the benefit versus the cost? And who is willing to pay the cost?" -- 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 Sat Aug 3 14:29:45 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 8CF2A37B400; Sat, 3 Aug 2002 14:29:40 -0700 (PDT) Received: from smtp.a1poweruser.com (oh-chardon6a-62.clvhoh.adelphia.net [68.65.175.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id E983443E5E; Sat, 3 Aug 2002 14:29:38 -0700 (PDT) (envelope-from barbish@a1poweruser.com) Received: from barbish (lanwin1 [10.0.10.6]) by smtp.a1poweruser.com (Postfix) with SMTP id C360A2E; Sat, 3 Aug 2002 17:33:33 -0400 (EDT) Reply-To: From: "Joe & Fhe Barbish" To: "Luigi Rizzo" Cc: "Crist J. Clark" , "FBIPFW" , , , , , , , Subject: RE: natd & keep-state Date: Sat, 3 Aug 2002 17:29:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020803125847.B2239@iguana.icir.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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 First of all my intention was never to provoke any kind of hard feelings. I do not understand why keep-state and natd behave the way they do. I interpret your statement, stateful rules do, in terms of filtering, pretty much the same work that natd and "ppp -alias" do (the latter two using the same library, namely libalias). You may want them when you don't use natd/ppp-alias, and you certainly don't want them when you use natd/ppp-alias. To mean that The Keep-state option is intended to only be used when the natd function is not used. That natd combined with stateless rules result in the same level of session conversation statefullness as the keep-state option achieves when used with out natd. If this is the correct interpretation, then the man page info on the keep-state option needs to be changed to point out this limitation about the correct usage of the keep-state option. And in the same light the natd man page info needs to be changed to come right out an say that natd combined with stateless rules result in a IPFW firewall being totally aware of the statefullness of the complete bi-directional packet exchange of the session conversation so fraudulent packets can not be inserted into the session conversation undetected. Do you agree? -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Luigi Rizzo Sent: Saturday, August 03, 2002 3:59 PM To: Joe & Fhe Barbish Cc: Crist J. Clark; FBIPFW; archie@whistle.com; cmott@scientech.com; perhaps@yes.no; suutari@iki.fi; dnelson@redwoodsoft.com; brian@awfulhak.org; ru@FreeBSD.ORG Subject: Re: natd & keep-state I have tried to stay out of this pointless thread, but given that I have been indirectly mentioned > ... > The author of the keep-state option saw the need in ipfw to provide a > more complete security protection of the bi-directional exchange of > packets during the session conversation so fraudulent packets could not > ... stateful rules do, in terms of filtering, pretty much the same work that natd and "ppp -alias" do (the latter two using the same library, namely libalias). You may want them when you don't use natd/ppp-alias, and you certainly don't want them when you use natd/ppp-alias. I see no point in trying to write ipfw rulesets to make keep-state and natd work together, as it gives you absolutely no additional protection. Nor i see any obligation for anyone to prove or disprove that they can work together. It can be done, it is non trivial, and you need to have a very good understanding on how packets flow through the protocol stack. It is slightly easier to make stateful ipfw rules work together with "ppp -alias" because the latter does not reinject packets into the protocol stack as natd does. But other than that, there is no bug in ipfw or natd related to this issue. If what you are claiming is that we need in-kernel nat functionality, yes we do, so would you like to write one ? Otherwise just be quiet and patient and wait until someone comes up with one. > Help me get the people you know who maintain natd & ipfw to participate. > They have to look into the ipfw/natd source code to design a solution. > Maybe this change can be combined/included with the ipfw2 effort. Continuously posting the same email to the list is just going to provoke the opposite of what you want. And you have already succeeded with me. out of this thread. luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 17:18: 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 68E5937B400 for ; Sat, 3 Aug 2002 17:18:02 -0700 (PDT) Received: from relay03.esat.net (relay03.esat.net [193.95.141.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id C09F543E42 for ; Sat, 3 Aug 2002 17:18:01 -0700 (PDT) (envelope-from phil@ipac.ie) Received: from ipac-gw.cr001.ddm.esat.net (mail.rfc-networks.ie) [193.95.188.30] by relay03.esat.net with esmtp id 17b95p-0001Be-00; Sun, 04 Aug 2002 01:17:57 +0100 Received: from tear.domain (unknown [10.0.1.254]) by mail.rfc-networks.ie (Postfix) with ESMTP id C2DB054834 for ; Sun, 4 Aug 2002 00:21:55 +0100 (IST) Received: by tear.domain (Postfix, from userid 1000) id CC5E421146; Sun, 4 Aug 2002 01:19:00 +0000 (GMT) Date: Sun, 4 Aug 2002 01:19:00 +0000 From: Philip Reynolds To: freebsd-ipfw@freebsd.org Subject: Re: timeout Message-ID: <20020804011900.A1711@rfc-networks.ie> Reply-To: philip.reynolds@rfc-networks.ie References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from eberkut@minithins.net on Sat, Aug 03, 2002 at 05:06:12PM +0200 X-Operating-System: FreeBSD 4.6-STABLE X-URL: http://www.rfc-networks.ie 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 eberkut 28 lines of wisdom included: > I can't comment on this obviously. > Also there is a type of timeout features which could be > useful both for security or state track tuning, those similar > to Cisco's CBAC global timeouts or the pf.conf's set timeout > options (see > http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secu > r_c/scprt3/scdcbac.htm#xtocid27 > and pf.conf(5) readable on openbsd.org). Specially, CBAC > does a great work against syn flood & co. Some options may > also be useful against scan. And one can use state timeout > to agressively drop unresponsive/congested/slow connections. > > just a few feature suggestions ;) Without reading the detailed description of CBAC, from what you mention there aren't, the sysctl variables: - net.inet.ip.fw.dyn_ack_lifetime - net.inet.ip.fw.dyn_syn_lifetime etc. etc. What you're looking for? -- Philip Reynolds | Technical Director philip.reynolds@rfc-networks.ie | RFC Networks Ltd. http://www.rfc-networks.ie | +353 (0)1 8832063 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 17:21:14 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 CB94837B400 for ; Sat, 3 Aug 2002 17:21:12 -0700 (PDT) Received: from relay04.esat.net (relay04.esat.net [193.95.141.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51FA643E4A for ; Sat, 3 Aug 2002 17:21:12 -0700 (PDT) (envelope-from phil@ipac.ie) Received: from ipac-gw.cr001.ddm.esat.net (mail.rfc-networks.ie) [193.95.188.30] by relay04.esat.net with esmtp id 17b98x-0001P0-00; Sun, 04 Aug 2002 01:21:11 +0100 Received: from tear.domain (unknown [10.0.1.254]) by mail.rfc-networks.ie (Postfix) with ESMTP id 51E6954834 for ; Sun, 4 Aug 2002 00:25:09 +0100 (IST) Received: by tear.domain (Postfix, from userid 1000) id 9524121146; Sun, 4 Aug 2002 01:22:14 +0000 (GMT) Date: Sun, 4 Aug 2002 01:22:14 +0000 From: Philip Reynolds To: freebsd-ipfw@freebsd.org Subject: Re: "ipfw fwd" not working without static route? Message-ID: <20020804012214.B1711@rfc-networks.ie> Reply-To: philip.reynolds@rfc-networks.ie References: <20020801231035.B31318@rfc-networks.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from mailing@novaconnect.net on Fri, Aug 02, 2002 at 09:53:28AM -0400 X-Operating-System: FreeBSD 4.6-STABLE X-URL: http://www.rfc-networks.ie 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 Matt Abraham 87 lines of wisdom included: > I think in my case, a better scenario would be that I still > want to have the meeting point in building A for everyone > EXCEPT those from say, the Purchasing department; those > indiviuals should go over to building B. OK, however there is currently no route from A to B, so noone can get through. > Now the use of static routes become problematic because the > route now only applies to packets that match a certain > criteria, namely having a source address of 172.17.1.5. If I > modify the netmasks on the box (and not use ipfw fwd), I > change the behaviour for all packets coming through...not > what I want to do. I still think you can do what do you want to do by using subnetting your network properly. Crist did suggest an alternative with a ``dummy'' route. Perhaps more details (including interfaces, IP addresses, network addresses, subnets etc.) would allow us to look at the actual design of the network (which is where I feel the flaw is). -- Philip Reynolds | Technical Director philip.reynolds@rfc-networks.ie | RFC Networks Ltd. http://www.rfc-networks.ie | +353 (0)1 8832063 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 18:17: 3 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 8215937B400; Sat, 3 Aug 2002 18:17:01 -0700 (PDT) Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D59B43E3B; Sat, 3 Aug 2002 18:17:00 -0700 (PDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id g741rBf28592; Sat, 3 Aug 2002 20:53:11 -0500 (CDT) (envelope-from nick@rogness.net) Date: Sat, 3 Aug 2002 20:53:10 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: cjclark@alum.mit.edu Cc: Joe & Fhe Barbish , FBIPFW , archie@whistle.com, cmott@scientech.com, perhaps@yes.no, suutari@iki.fi, dnelson@redwoodsoft.com, brian@awfulhak.org, ru@FreeBSD.ORG, rizzo@icir.org Subject: Re: natd & keep-state In-Reply-To: <20020803212854.GA55652@blossom.cjclark.org> Message-ID: 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 On Sat, 3 Aug 2002, Crist J. Clark wrote: [SNIP] > Fine, whatever. But the ipfw(8) and natd(8) developers seem to hold > the same opinion. Maybe if you proposed some possible way for natd(8) > and 'keep-state' rules to work well together someone could do it. FWIW, you can modify the behavior of "check-state" to "JUMP TO RULE NUMBER XXX on stateful match" and solve most of the problems associated with natd & stateful inspection. Right now, if check-state finds a match it stops...we need it to optionally JUMP_TO RULE XXX. Kinda like "skipto" functionality. I talked to Luigi about this and he didn't understand what I meant (which is my fault). But I believe the concept is still sound. Nick Rogness - Don't mind me...I'm just sniffing your packets To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 21:20:54 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 9AC6937B400 for ; Sat, 3 Aug 2002 21:20:52 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 578C343E3B for ; Sat, 3 Aug 2002 21:20:52 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g744Ko905355; Sat, 3 Aug 2002 21:20:50 -0700 (PDT) (envelope-from rizzo) Date: Sat, 3 Aug 2002 21:20:50 -0700 From: Luigi Rizzo To: Nick Rogness Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: natd & keep-state Message-ID: <20020803212050.A5279@iguana.icir.org> References: <20020803212854.GA55652@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: ; from nick@rogness.net on Sat, Aug 03, 2002 at 08:53:10PM -0500 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 still do not follow... isn't this exactly what you want ? ipfw add skipto 5000 keep-state check-state does not stop, it just executes whatever action is specified for the original rule from which the state was created. So if that one is a skipto you have a skipto. cheers luigi On Sat, Aug 03, 2002 at 08:53:10PM -0500, Nick Rogness wrote: ... > > FWIW, you can modify the behavior of "check-state" to "JUMP TO > RULE NUMBER XXX on stateful match" and solve most of the problems > associated with natd & stateful inspection. Right now, > if check-state finds a match it stops...we need it to optionally > JUMP_TO RULE XXX. Kinda like "skipto" functionality. > > I talked to Luigi about this and he didn't understand what I > meant (which is my fault). But I believe the concept is still > sound. > > > Nick Rogness > - Don't mind me...I'm just sniffing your packets > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 21:46: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 A5D0837B400 for ; Sat, 3 Aug 2002 21:46:51 -0700 (PDT) Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9F7343E42 for ; Sat, 3 Aug 2002 21:46:50 -0700 (PDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id g745N5n30585; Sun, 4 Aug 2002 00:23:05 -0500 (CDT) (envelope-from nick@rogness.net) Date: Sun, 4 Aug 2002 00:23:05 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Luigi Rizzo Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: natd & keep-state In-Reply-To: <20020803212050.A5279@iguana.icir.org> Message-ID: 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 On Sat, 3 Aug 2002, Luigi Rizzo wrote: > I still do not follow... isn't this exactly what you want ? > > ipfw add skipto 5000 keep-state > > check-state does not stop, it just executes whatever action is > specified for the original rule from which the state was created. So > if that one is a skipto you have a skipto. Yes, that is exactly what I want. I tried that exact rule, but it did not work for some reason :-( In versions prior to 4.6 (forgot what versions specifically)...all of them didn't work. Haven't tried with your ipfw2 or post 4.6 yet...will try and let you know. Nick Rogness - Don't mind me...I'm just sniffing your packets To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Aug 3 22:13:58 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 C704F37B400 for ; Sat, 3 Aug 2002 22:13:56 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8559A43E42 for ; Sat, 3 Aug 2002 22:13:56 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g745Ds405704; Sat, 3 Aug 2002 22:13:54 -0700 (PDT) (envelope-from rizzo) Date: Sat, 3 Aug 2002 22:13:54 -0700 From: Luigi Rizzo To: Nick Rogness Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: natd & keep-state Message-ID: <20020803221354.B5279@iguana.icir.org> References: <20020803212050.A5279@iguana.icir.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: ; from nick@rogness.net on Sun, Aug 04, 2002 at 12:23:05AM -0500 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 Sun, Aug 04, 2002 at 12:23:05AM -0500, Nick Rogness wrote: ... > > I still do not follow... isn't this exactly what you want ? > > > > ipfw add skipto 5000 keep-state > > > > check-state does not stop, it just executes whatever action is > > specified for the original rule from which the state was created. So > > if that one is a skipto you have a skipto. > > Yes, that is exactly what I want. I tried that exact rule, but it > did not work for some reason :-( In versions prior to 4.6 (forgot > what versions specifically)...all of them didn't work. Haven't > tried with your ipfw2 or post 4.6 yet...will try and let you know. seems to work here with ipfw2. The code in ip_fw.c seems to do a similar thing, and i do not remember doing any change in that area. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message