From owner-freebsd-questions@FreeBSD.ORG Mon Jan 19 21:49:26 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C38FD16A4CE for ; Mon, 19 Jan 2004 21:49:26 -0800 (PST) Received: from lakemtao07.cox.net (lakemtao07.cox.net [68.1.17.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1E6F43D69 for ; Mon, 19 Jan 2004 21:48:58 -0800 (PST) (envelope-from micheal@tsgincorporated.com) Received: from dredster ([68.12.79.37]) by lakemtao07.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040120054857.JGIF2432.lakemtao07.cox.net@dredster>; Tue, 20 Jan 2004 00:48:57 -0500 Message-ID: <1d85e01c3df19$2fd63610$0201a8c0@dredster> From: "Micheal Patterson" To: "Ken Bolingbroke" , "fbsd_user" References: <20040119201738.B30318@fremont.bolingbroke.com> Date: Mon, 19 Jan 2004 23:49:33 -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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-questions@freebsd.org Subject: Re: ipfw/nated stateful rules example X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2004 05:49:27 -0000 ----- Original Message ----- From: "Ken Bolingbroke" To: "fbsd_user" Cc: Sent: Monday, January 19, 2004 10:28 PM Subject: RE: ipfw/nated stateful rules example > > On Mon, 19 Jan 2004, fbsd_user wrote: > > > That's a play on words. And still does not prove stateful rules work on > > the interface facing the public internet. There is no documentation that > > says keep-state and limit only works on the interface facing the private > > Lan network. And the implied meaning is they are to be used on the > > interface facing the public internet. > > I just jumped in the middle here, so I may be out of context. > > But, stateful rules don't play nice with NAT. Consider non-NAT, a public > IP address contacting an Internet address: > > 67.161.59.61 -> 66.218.71.91 > > A rule is created for 66.218.71.91 coming to 67.161.59.61. When > 66.218.71.91 replies, the stateful rule lets it in. This is good. > > > But consider NAT: > > 10.0.0.10 changed to 67.161.59.61 -> 66.218.71.91 > > If you do a keep-state before NAT, you have a rule to allow 66.218.71.91 > to 10.0.0.10, but the return incoming packet will be 66.218.71.91 -> > 67.161.59.61, so the rule doesn't match. > > If you do a keep-state after NAT, then you have a rule to allow > 66.218.71.91 to 67.161.59.61. The return incoming packet matches that > rule, but it accepts the packet and packet processing stops, so it's never > passed through NAT, and never makes it back to 10.0.0.10. > > > So as it stands now, I don't see that you can use stateful connections > with NAT, unless check-state is changed to allow a packet to be passed > through NAT. > > Ken Bolingbroke Ken, try this one. This is what I use here at home and it does indeed work: Launch NATD with natd -interface ep0 -s -m -u (Only RFC1918 packets get altered) ## Divert everything to NAT. ipfw add 1 divert natd ip from any to any via ep0 #Prevent inbound spoof attempts for my lan range ipfw add 10 deny ip from 192.168.1.0/24 to any in via ep0 #Check State Rules ipfw add 20 check state #LAN Allow Stateful ipfw add 31 allow ip from 192.168.1.0/24 to any keep-state #Allow Outbound Stateful. ipfw add 40 allow ip from 68.12.xx.xx to any keep-state NAT keeps a seperate table of it's translations to provide a back channel. Traffic comes in, generates a dynamic ruleset, gets translated, heads out and creates the 2nd dynamic for the packet. You'll end up with something like this ipfw -d list ## Dynamic rules: 00040 4 692 (T 18, slot 215) <-> tcp, 68.12.xx.xx3777<-> 216.239.57.99 80 00031 35 20374 (T 10, slot 219) <-> udp, 192.168.1.3 4986<-> 198.247.231.41 27019 00031 3 216 (T 1, slot 483) <-> tcp, 192.168.1.1 22<-> 192.168.1.2 3574 00031 16 11902 (T 298, slot 752) <-> tcp, 192.168.1.2 3777<-> 216.239.57.99 80 Granted, you'll end up with a dual entry for each packet in stateful space, but it does work. Perhaps not as intended with a single match but you can use statful with NAT. -- Micheal Patterson Network Administration TSG Incorporated 405-917-0600