From owner-freebsd-ipfw@FreeBSD.ORG Sun May 30 17:05:18 2004 Return-Path: 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 D5C0C16A4CE for ; Sun, 30 May 2004 17:05:18 -0700 (PDT) Received: from hotmail.com (bay12-f80.bay12.hotmail.com [64.4.35.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6AFF43D31 for ; Sun, 30 May 2004 17:05:18 -0700 (PDT) (envelope-from jackass_wasa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 30 May 2004 17:05:14 -0700 Received: from 200.52.188.105 by by12fd.bay12.hotmail.msn.com with HTTP; Mon, 31 May 2004 00:05:13 GMT X-Originating-IP: [200.52.188.105] X-Originating-Email: [jackass_wasa@hotmail.com] X-Sender: jackass_wasa@hotmail.com From: "El DaEm0n" To: freebsd-ipfw@freebsd.org Date: Mon, 31 May 2004 00:05:13 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 31 May 2004 00:05:14.0028 (UTC) FILETIME=[F27F1EC0:01C446A2] Subject: newbie question X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 00:05:19 -0000 hi guys, i have a question how can i made with IPW show portscan that my system is down? _________________________________________________________________ MSN Fotos: la forma más fácil de compartir e imprimir fotos. http://photos.msn.es/support/worldwide.aspx From owner-freebsd-ipfw@FreeBSD.ORG Mon May 31 09:47:01 2004 Return-Path: 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 D6F4216A4CE for ; Mon, 31 May 2004 09:47:01 -0700 (PDT) Received: from out010.verizon.net (out010pub.verizon.net [206.46.170.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 857B643D1D for ; Mon, 31 May 2004 09:47:01 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] ([68.161.84.3]) by out010.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040531164611.YPUO15848.out010.verizon.net@[192.168.1.3]>; Mon, 31 May 2004 11:46:11 -0500 Message-ID: <40BB6153.5050604@mac.com> Date: Mon, 31 May 2004 12:46:11 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: El DaEm0n References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out010.verizon.net from [68.161.84.3] at Mon, 31 May 2004 11:46:11 -0500 cc: freebsd-ipfw@freebsd.org Subject: Re: newbie question X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 16:47:01 -0000 El DaEm0n wrote: > hi guys, i have a question how can i made with IPW show portscan that > my system is down? Disconnect the ethernet cable? "ipfw add 10 deny ip from any to any" ...a little more context would help us give a more useful answer. -- -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Mon May 31 10:23:38 2004 Return-Path: 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 DC46316A4CE for ; Mon, 31 May 2004 10:23:38 -0700 (PDT) Received: from hotmail.com (bay12-f77.bay12.hotmail.com [64.4.35.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id C185643D64 for ; Mon, 31 May 2004 10:23:38 -0700 (PDT) (envelope-from jackass_wasa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 31 May 2004 10:22:37 -0700 Received: from 200.34.223.10 by by12fd.bay12.hotmail.msn.com with HTTP; Mon, 31 May 2004 17:22:36 GMT X-Originating-IP: [200.34.223.10] X-Originating-Email: [jackass_wasa@hotmail.com] X-Sender: jackass_wasa@hotmail.com From: "El DaEm0n" To: freebsd-ipfw@freebsd.org Date: Mon, 31 May 2004 17:22:36 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 31 May 2004 17:22:37.0203 (UTC) FILETIME=[DE51E630:01C44733] Subject: Re: newbie question X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 17:23:39 -0000 ok my problem is when i made a portscan to my server in another pc it revealed my open ports, so all i wanna do is when i made a ports scan from another pc to my server mi IPFW show to portscan that my system appears down, i see this in other systems using PF but i wanna know how to make using IPFW can you help? thanks! >El DaEm0n wrote: >>hi guys, i have a question how can i made with IPW show portscan that my >>system is down? > >Disconnect the ethernet cable? >"ipfw add 10 deny ip from any to any" > >...a little more context would help us give a more useful answer. > >-- >-Chuck _________________________________________________________________ MSN Fotos: la forma más fácil de compartir e imprimir fotos. http://photos.msn.es/support/worldwide.aspx From owner-freebsd-ipfw@FreeBSD.ORG Mon May 31 10:58:11 2004 Return-Path: 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 9A5DC16A4CE for ; Mon, 31 May 2004 10:58:11 -0700 (PDT) Received: from out012.verizon.net (out012pub.verizon.net [206.46.170.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C54343D1D for ; Mon, 31 May 2004 10:58:11 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] ([68.161.84.3]) by out012.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040531175800.YFXX2198.out012.verizon.net@[192.168.1.3]>; Mon, 31 May 2004 12:58:00 -0500 Message-ID: <40BB7228.904@mac.com> Date: Mon, 31 May 2004 13:58:00 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: El DaEm0n References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out012.verizon.net from [68.161.84.3] at Mon, 31 May 2004 12:58:00 -0500 cc: freebsd-ipfw@freebsd.org Subject: Re: newbie question X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 17:58:11 -0000 El DaEm0n wrote: > ok my problem is when i made a portscan to my server in another pc it > revealed my open ports, so all i wanna do is when i made a ports scan > from another pc to my server mi IPFW show to portscan that my system > appears down, You probably want to use something like this, from "man ipfw": The typical use of dynamic rules is to keep a closed firewall configura- tion, but let the first TCP SYN packet from the inside network install a dynamic rule for the flow so that packets belonging to that session will be allowed through the firewall: ipfw add check-state ipfw add allow tcp from my-subnet to any setup keep-state ipfw add deny tcp from any to any Going beyond these examples to a meaningful firewall configuration involves thinking about your security policy, considering roles and required services, etc.... -- -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Mon May 31 11:02:38 2004 Return-Path: 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 73FE716A4CF for ; Mon, 31 May 2004 11:02:38 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F28543D49 for ; Mon, 31 May 2004 11:02:38 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i4VI26OS023080 for ; Mon, 31 May 2004 11:02:06 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4VI26eA023074 for ipfw@freebsd.org; Mon, 31 May 2004 11:02:06 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 31 May 2004 11:02:06 -0700 (PDT) Message-Id: <200405311802.i4VI26eA023074@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2004 18:02:38 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/12/27] kern/46557 ipfw ipfw pipe show fails with lots of queues o [2003/04/22] kern/51274 ipfw ipfw2 create dynamic rules with parent nu f [2003/04/24] kern/51341 ipfw ipfw rule 'deny icmp from any to any icmp o [2004/03/03] misc/63724 ipfw IPFW2 Queues dont t work o [2004/03/13] kern/64240 ipfw IPFW tee terminates rule processing 5 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw Add an option to ipfw to log gid/uid of w o [2002/12/07] kern/46080 ipfw [PATCH] logamount in ipfw2 does not defau o [2002/12/10] kern/46159 ipfw ipfw dynamic rules lifetime feature o [2002/12/27] kern/46564 ipfw IPFilter and IPFW processing order is not o [2003/02/11] kern/48172 ipfw ipfw does not log size and flags o [2003/03/10] kern/49086 ipfw [patch] Make ipfw2 log to different syslo o [2003/03/12] bin/49959 ipfw ipfw tee port rule skips parsing next rul o [2003/04/09] bin/50749 ipfw ipfw2 incorrectly parses ports and port r o [2003/08/25] kern/55984 ipfw [patch] time based firewalling support fo o [2003/12/29] kern/60719 ipfw ipfw: Headerless fragments generate cryp o [2004/01/12] kern/61259 ipfw [patch] make "ipfw tee" work as intended o [2004/02/09] kern/62598 ipfw no logging on ipfw loadable module o [2004/03/08] kern/63961 ipfw ipfw2 uid matching doesn't work correctly 13 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Jun 1 21:35:37 2004 Return-Path: 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 A871A16A4CE; Tue, 1 Jun 2004 21:35:37 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A51B943D3F; Tue, 1 Jun 2004 21:35:37 -0700 (PDT) (envelope-from csjp@freebsd.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) i524ZbfW047609; Tue, 1 Jun 2004 21:35:37 -0700 (PDT) (envelope-from csjp@freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i524Zb9S047608; Tue, 1 Jun 2004 21:35:37 -0700 (PDT) (envelope-from csjp@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: csjp set sender to csjp@freebsd.org using -f Date: Tue, 1 Jun 2004 21:35:37 -0700 From: "Christian S.J. Peron" To: hackers@freebsd.org Message-ID: <20040602043537.GA42327@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: ipfw@freebsd.org Subject: ipfw cached ucred patch X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 04:35:37 -0000 All, Currently, when you have any rules which contain UID/GID constraints, ipfw will lock the pcb hash and do a lookup to find the pcb associated with that packet -- One for each constraint. I have written a patch in attempt to minimize the impact of PCB related lookups for these type of firewall rules. This patch will have the following effects on firewalls which contain UID/GID constraints: o Greatly reduce the locking contention associated with PCB lookups. o Increase the performance of firewall in general by making PCB lookups O(1) rather than O(n) (where n represents number of UID/GID constraints in the ruleset) It would be greatly appriciated if people who are running ipfw rules sets containing UID/GID constraints tested this patch and reported any success or failures. The patch can be downloaded from: http://people.freebsd.org/~csjp/ip_fw2_cached_ucred.patch NOTE: It also appears that ip_output passes a reference to the PCB. Perhaps we can hold a reference to the ucred stored in that entry and do away with lookups on outgoing packets all-together? -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 02:26:30 2004 Return-Path: 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 6457416A4CE for ; Wed, 2 Jun 2004 02:26:30 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8660B43D39 for ; Wed, 2 Jun 2004 02:26:29 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 77616 invoked from network); 2 Jun 2004 09:26:27 -0000 Received: from unknown (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 2 Jun 2004 09:26:27 -0000 Message-ID: <40BD9D3F.7090100@freebsd.org> Date: Wed, 02 Jun 2004 11:26:23 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20040602043537.GA42327@freefall.freebsd.org> In-Reply-To: <20040602043537.GA42327@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: ipfw@freebsd.org Subject: Re: ipfw cached ucred patch X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 09:26:30 -0000 Christian S.J. Peron wrote: > All, > > Currently, when you have any rules which contain UID/GID > constraints, ipfw will lock the pcb hash and do a lookup > to find the pcb associated with that packet -- > One for each constraint. > > I have written a patch in attempt to minimize the impact > of PCB related lookups for these type of firewall rules. > > This patch will have the following effects on firewalls which > contain UID/GID constraints: > > o Greatly reduce the locking contention associated > with PCB lookups. > > o Increase the performance of firewall in general by making > PCB lookups O(1) rather than O(n) (where n represents > number of UID/GID constraints in the ruleset) > > It would be greatly appriciated if people who are running ipfw > rules sets containing UID/GID constraints tested this patch > and reported any success or failures. > > The patch can be downloaded from: > > http://people.freebsd.org/~csjp/ip_fw2_cached_ucred.patch You can optimize it even further by directly copying the uid/gid from the ucred while you hold the INP_LOCK. There is no need to hold on to the entire ucred. It should be sufficient to do the ucred lookup only once per packet in the ipfw code. If you don't find an INPCB for the packet you'll do a negative lookup for every uid/gid rule. > It also appears that ip_output passes a reference to the PCB. > Perhaps we can hold a reference to the ucred stored in that > entry and do away with lookups on outgoing packets all-together? Yes, that would be possible but that weaves ipfw even tighter with ip_output and I'm currently converting it to go through the pfil_hooks mechanism. Pfil_hooks does not allow such additional information to be passed along directly. What you could do is to pass a m_tag with the numerical uid/gid along with locally generated packets to get the same effect. Here it would be good to co-ordinate with pf/ipfilter guys so that they can use this m_tag too. However for a first step just redo the lookup once per packet if neccessary. -- Andre From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 06:51:55 2004 Return-Path: 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 6A0CB16A4CE; Wed, 2 Jun 2004 06:51:55 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F49843D4C; Wed, 2 Jun 2004 06:51:55 -0700 (PDT) (envelope-from csjp@freebsd.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) i52DpteE031886; Wed, 2 Jun 2004 06:51:55 -0700 (PDT) (envelope-from csjp@freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i52DptCx031885; Wed, 2 Jun 2004 06:51:55 -0700 (PDT) (envelope-from csjp@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: csjp set sender to csjp@freebsd.org using -f Date: Wed, 2 Jun 2004 06:51:55 -0700 From: "Christian S.J. Peron" To: Andre Oppermann Message-ID: <20040602135155.GA31642@freefall.freebsd.org> References: <20040602043537.GA42327@freefall.freebsd.org> <40BD9D3F.7090100@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BD9D3F.7090100@freebsd.org> User-Agent: Mutt/1.4.1i cc: hackers@freebsd.org cc: ipfw@freebsd.org Subject: Re: ipfw cached ucred patch X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 13:51:55 -0000 On 2 Jun 2004 Andre Oppermann wrote: > Christian S.J. Peron wrote: > >All, > > > >Currently, when you have any rules which contain UID/GID > >constraints, ipfw will lock the pcb hash and do a lookup > >to find the pcb associated with that packet -- > >One for each constraint. > > > >I have written a patch in attempt to minimize the impact > >of PCB related lookups for these type of firewall rules. > > > >This patch will have the following effects on firewalls which > >contain UID/GID constraints: > > > > o Greatly reduce the locking contention associated > > with PCB lookups. > > > > o Increase the performance of firewall in general by making > > PCB lookups O(1) rather than O(n) (where n represents > > number of UID/GID constraints in the ruleset) > > > >It would be greatly appriciated if people who are running ipfw > >rules sets containing UID/GID constraints tested this patch > >and reported any success or failures. > > > >The patch can be downloaded from: > > > >http://people.freebsd.org/~csjp/ip_fw2_cached_ucred.patch > > You can optimize it even further by directly copying the uid/gid > from the ucred while you hold the INP_LOCK. There is no need to > hold on to the entire ucred. It should be sufficient to do the > ucred lookup only once per packet in the ipfw code. If you don't > find an INPCB for the packet you'll do a negative lookup for every > uid/gid rule. I thought about this to, however in order to implement GID contraints properly, we need to use groupmember(9) which requires the entire cr_groups[16] located in the ucred. I thought it was more elegant and cheaper to avoid the memcpy(sizeof(gid_t) * NGROUPS) and stick with the mutex. Anyone else have other ideas? -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 13:11:00 2004 Return-Path: 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 A684F16A4CE for ; Wed, 2 Jun 2004 13:11:00 -0700 (PDT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76A5943D39 for ; Wed, 2 Jun 2004 13:11:00 -0700 (PDT) (envelope-from freebsd-ipfw.20.openmacews@spamgourmet.com) Received: (qmail 20905 invoked from network); 2 Jun 2004 20:11:00 -0000 Received: from ns1.presence-group.net (HELO [172.30.11.6]) (blakers@[216.27.177.134]) )encrypted SMTP for ; 2 Jun 2004 20:10:59 -0000 Date: Wed, 02 Jun 2004 13:10:57 -0700 From: OpenMacNews To: freebsd-ipfw Message-ID: <33760B5BC85169CE97B0219F@[172.30.11.6]> X-Mailer: Mulberry/3.1.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: help with multiple-public-to-multiple-natd mappings/rules/logic? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: OpenMacNews List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 20:11:00 -0000 hi all, [I tried doing al this via "fwbuilder" (www.fwbuilder.org) only to, unfortunately, find out that _it_ doesn't support ipfw + natd rule generation ... so back to "manual", and my questions below ...] I've read through as many examples on the web I could find, but as none were exactly the config I'm attempting here. As a result of trying to cobble together the examples I *did* find, I've gotten myself thoroughly confused about a couple of issues re: my "to be" ipfw firewall configuration ... specifically, since I have *multiple* EXTERNAL ip's that need to map THROUGH a single INTERNAL interface to *multiple* INTERNAL (NATd) ip's. as far as a "policy" goes, my goal is: (1) outbound: ALLOW, then DENY, specifically blocking outbound services access, e.g. "chat", allowing STATEFUL rules (2) inbound: DENY, then ALLOW (3) process 'general' fw rules 1st (e.g., "pest rules" such as 'DENY from "timbuktu IP" to ANY') (4) provide specific, service-based mappings from external "public" IPs to various internal "private" IPs via NAT to do, this however, I think I need (1) multiple NATd instances (one for each external IP) (2) some combination of DIVERT, SKIPTO and FORWARD rules to do all the necessary in/out mapping and firewall processing which is where my confusion begins !! with ONE natd instance, and ONE external IP address, i've got everything pretty much working ... but the MULTIPLE-TO-MULTIPLE logic has got me "blindly trying stuff" ... SOOOOOOOOOOO, any/all insights/comment, or pointers to existing examples -- or general _relevant_ logic, for that matter -- would be much appreciated! in particular, the in/out rules for httpd, smtp & dns via these multiple interfaces are eluding me for now. to help get started, here's my config: | | [public internet] | | [cable modem] 2 fixed IP addresses: A.A.A.A A.A.A.B ISP's DNS servers: A.A.A.XX A.A.A.YY ISP's Gateway: A.A.A.GG | | [firewall box, server 1] hw: 2 NIC cards card 1 ("external"): multihomed A.A.A.A A.A.A.B card 2 ("internal"): 10.0.0.1 sw: ipfw dhcp natd smtpd listens on mail1.domain.com | | | | |------------------ [server 2] | hw: | 1 NIC card | multihomed | 10.0.0.2 | 10.0.0.21 | sw: | httpd, public access | listens on 10.0.0.2 for www.domain2.com | listens on 10.0.0.21 for www.domain21.com | | |------------------ [server 3] | hw: | 1 NIC card | 10.0.0.3 | sw: | smtpd, public access | listens on mail3.domain.com | dns, public access | (a) provides primary DNS for multiple domains, | zone transfers ONLY to named external secondaries | (b) serves as internal/LAN DNS for all machines | on 10.0.0.x LAN | (c) forwards some requests to ISP's DNS @ A.A.A.XX & | A.A.A.YY | | |------------------ [server 4] | hw: | 1 NIC card | multihomed | 10.0.0.4 | 10.0.0.41 | sw: | httpd, public access | listens on 10.0.0.4 for www.domain4.com | listens on 10.0.0.41 for www.domain41.com | | |------------------ [workstation 5] 1 NIC card 10.0.0.5 sw: usual client apps ... where, "public"/"external" IP allocations/assignments are: A.A.A.A --> reverse IP == domain.com A.A.A.B --> reserse IP == domain2.com mail1.domain.com --> A.A.A.B mail3.domain.com --> A.A.A.A www.domain2.com --> A.A.A.A www.domain21.com --> A.A.A.B www.domain4.com --> A.A.A.A www.domain41.com --> A.A.A.B thanks! richard From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 14:23:08 2004 Return-Path: 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 2948516A4CF for ; Wed, 2 Jun 2004 14:23:08 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CA1D43D5D for ; Wed, 2 Jun 2004 14:23:07 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 88195 invoked from network); 2 Jun 2004 21:23:06 -0000 Received: from unknown (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 2 Jun 2004 21:23:06 -0000 Message-ID: <40BE4536.4050905@freebsd.org> Date: Wed, 02 Jun 2004 23:23:02 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20040602043537.GA42327@freefall.freebsd.org> <40BD9D3F.7090100@freebsd.org> <20040602135155.GA31642@freefall.freebsd.org> In-Reply-To: <20040602135155.GA31642@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: ipfw@freebsd.org Subject: Re: ipfw cached ucred patch X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 21:23:08 -0000 Christian S.J. Peron wrote: > On 2 Jun 2004 Andre Oppermann wrote: > >>Christian S.J. Peron wrote: >> >>>All, >>> >>>Currently, when you have any rules which contain UID/GID >>>constraints, ipfw will lock the pcb hash and do a lookup >>>to find the pcb associated with that packet -- >>>One for each constraint. >>> >>>I have written a patch in attempt to minimize the impact >>>of PCB related lookups for these type of firewall rules. >>> >>>This patch will have the following effects on firewalls which >>>contain UID/GID constraints: >>> >>>o Greatly reduce the locking contention associated >>> with PCB lookups. >>> >>>o Increase the performance of firewall in general by making >>> PCB lookups O(1) rather than O(n) (where n represents >>> number of UID/GID constraints in the ruleset) >>> >>>It would be greatly appriciated if people who are running ipfw >>>rules sets containing UID/GID constraints tested this patch >>>and reported any success or failures. >>> >>>The patch can be downloaded from: >>> >>>http://people.freebsd.org/~csjp/ip_fw2_cached_ucred.patch >> >>You can optimize it even further by directly copying the uid/gid >>from the ucred while you hold the INP_LOCK. There is no need to >>hold on to the entire ucred. It should be sufficient to do the >>ucred lookup only once per packet in the ipfw code. If you don't >>find an INPCB for the packet you'll do a negative lookup for every >>uid/gid rule. > > I thought about this to, however in order to implement GID contraints > properly, we need to use groupmember(9) which requires the > entire cr_groups[16] located in the ucred. I thought it was more > elegant and cheaper to avoid the memcpy(sizeof(gid_t) * NGROUPS) > and stick with the mutex. I see. Hmmm... Actually I'm only concerned that someone later misses a crfree() call and starts to leak ucred structures. ipfw is not the first place you are going to look for it. The more you can keep together in one place the better it is. This kind of error has already happend once with the initial implementation of verrevpath in ifpw. The fuction did not correctly do the ref- counting leading to a hefty rtentry leak. -- Andre From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 14:35:15 2004 Return-Path: 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 D477D16A4CE; Wed, 2 Jun 2004 14:35:15 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8549843D3F; Wed, 2 Jun 2004 14:35:15 -0700 (PDT) (envelope-from csjp@freebsd.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) i52LZFEK091522; Wed, 2 Jun 2004 14:35:15 -0700 (PDT) (envelope-from csjp@freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i52LZFJr091521; Wed, 2 Jun 2004 14:35:15 -0700 (PDT) (envelope-from csjp@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: csjp set sender to csjp@freebsd.org using -f Date: Wed, 2 Jun 2004 14:35:15 -0700 From: "Christian S.J. Peron" To: Andre Oppermann Message-ID: <20040602213515.GA90619@freefall.freebsd.org> References: <20040602043537.GA42327@freefall.freebsd.org> <40BD9D3F.7090100@freebsd.org> <20040602135155.GA31642@freefall.freebsd.org> <40BE4536.4050905@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BE4536.4050905@freebsd.org> User-Agent: Mutt/1.4.1i cc: hackers@freebsd.org cc: ipfw@freebsd.org Subject: Re: ipfw cached ucred patch X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 21:35:16 -0000 Agreed, This was a concern for me as well, I was pretty carefull about managing the reference counts, I am currently testing this patch with a variety of rule types to check for ucred leaks. If/before this patch gets committed, I plan on doing another carefull scrutinization of the ipfw code to make sure there are no return, continues or breaks etc which could cause the ucred to be leaked. On 2 Jun 2004 Andre Oppermann wrote: > Christian S.J. Peron wrote: > >On 2 Jun 2004 Andre Oppermann wrote: > > > >>Christian S.J. Peron wrote: > >> > >>>All, > >>> > >>>Currently, when you have any rules which contain UID/GID > >>>constraints, ipfw will lock the pcb hash and do a lookup > >>>to find the pcb associated with that packet -- > >>>One for each constraint. > >>> > >>>I have written a patch in attempt to minimize the impact > >>>of PCB related lookups for these type of firewall rules. > >>> > >>>This patch will have the following effects on firewalls which > >>>contain UID/GID constraints: > >>> > >>>o Greatly reduce the locking contention associated > >>> with PCB lookups. > >>> > >>>o Increase the performance of firewall in general by making > >>> PCB lookups O(1) rather than O(n) (where n represents > >>> number of UID/GID constraints in the ruleset) > >>> > >>>It would be greatly appriciated if people who are running ipfw > >>>rules sets containing UID/GID constraints tested this patch > >>>and reported any success or failures. > >>> > >>>The patch can be downloaded from: > >>> > >>>http://people.freebsd.org/~csjp/ip_fw2_cached_ucred.patch > >> > >>You can optimize it even further by directly copying the uid/gid > >>from the ucred while you hold the INP_LOCK. There is no need to > >>hold on to the entire ucred. It should be sufficient to do the > >>ucred lookup only once per packet in the ipfw code. If you don't > >>find an INPCB for the packet you'll do a negative lookup for every > >>uid/gid rule. > > > >I thought about this to, however in order to implement GID contraints > >properly, we need to use groupmember(9) which requires the > >entire cr_groups[16] located in the ucred. I thought it was more > >elegant and cheaper to avoid the memcpy(sizeof(gid_t) * NGROUPS) > >and stick with the mutex. > > I see. Hmmm... Actually I'm only concerned that someone later > misses a crfree() call and starts to leak ucred structures. ipfw > is not the first place you are going to look for it. The more you > can keep together in one place the better it is. This kind > of error has already happend once with the initial implementation > of verrevpath in ifpw. The fuction did not correctly do the ref- > counting leading to a hefty rtentry leak. > > -- > Andre > -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 14:52:05 2004 Return-Path: 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 0B64A16A4CF for ; Wed, 2 Jun 2004 14:52:05 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 193EF43D5A for ; Wed, 2 Jun 2004 14:52:04 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 90081 invoked from network); 2 Jun 2004 21:52:02 -0000 Received: from unknown (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 2 Jun 2004 21:52:02 -0000 Message-ID: <40BE4BFE.70204@freebsd.org> Date: Wed, 02 Jun 2004 23:51:58 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20040602043537.GA42327@freefall.freebsd.org> <40BD9D3F.7090100@freebsd.org> <20040602135155.GA31642@freefall.freebsd.org> <40BE4536.4050905@freebsd.org> <20040602213515.GA90619@freefall.freebsd.org> In-Reply-To: <20040602213515.GA90619@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: ipfw@freebsd.org Subject: Re: ipfw cached ucred patch X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 21:52:05 -0000 Christian S.J. Peron wrote: > Agreed, > > This was a concern for me as well, I was pretty carefull about > managing the reference counts, I am currently testing this patch > with a variety of rule types to check for ucred leaks. If/before this patch > gets committed, I plan on doing another carefull scrutinization > of the ipfw code to make sure there are no return, continues or breaks > etc which could cause the ucred to be leaked. This is exactly the problem I try to avoid. If there is the need to double and triple check then I think there is a design error. If that happens to any work I do I start over again unless I'm constrained by external code. For example when I replied to your original email with the patch I read it and said you'd re-do the lookup every time when there is a miss. This is actually not the case. However it is not really obvious what is going on there, even less so from just reading the patch. And I'm well familiar with the ipfw2 code. Only after putting it next to the full ip_fw2.c code and reading it slowly I saw the roundabout of the function and how it does its thing. What I want to say is that it is not obvious how it works and the next one working on this code is almost certainly breaking it or leaking ucreds. I am fully certain that you have tested it in any way to make sure it is correct and I can tell you that it is correct now that I have checked all function returns as well. But this is not write once and let it be but write once, modify often and read all the time. I have stumbled across too many 'short-cuts' in the past year and it made and makes locking the network stack a real pain. I do not object to your patch. I'm just highlighting the grief it might cause later on. ;-) -- Andre From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 15:14:44 2004 Return-Path: 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 0F91116A4CE; Wed, 2 Jun 2004 15:14:44 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 078F943D49; Wed, 2 Jun 2004 15:14:44 -0700 (PDT) (envelope-from csjp@freebsd.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) i52MEhJp096572; Wed, 2 Jun 2004 15:14:43 -0700 (PDT) (envelope-from csjp@freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i52MEhAH096571; Wed, 2 Jun 2004 15:14:43 -0700 (PDT) (envelope-from csjp@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: csjp set sender to csjp@freebsd.org using -f Date: Wed, 2 Jun 2004 15:14:43 -0700 From: "Christian S.J. Peron" To: Andre Oppermann Message-ID: <20040602221443.GA92431@freefall.freebsd.org> References: <20040602043537.GA42327@freefall.freebsd.org> <40BD9D3F.7090100@freebsd.org> <20040602135155.GA31642@freefall.freebsd.org> <40BE4536.4050905@freebsd.org> <20040602213515.GA90619@freefall.freebsd.org> <40BE4BFE.70204@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40BE4BFE.70204@freebsd.org> User-Agent: Mutt/1.4.1i cc: hackers@freebsd.org cc: ipfw@freebsd.org Subject: Re: ipfw cached ucred patch X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 22:14:44 -0000 I understand what you are saying. The only real other choice would be to copy out the entire cr_groups array. Do you know if this copy would be more expensive then the mutex lock/unlock associated with grabbing a reference to the ucred? -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 15:29:47 2004 Return-Path: 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 A5A3816A4CE; Wed, 2 Jun 2004 15:29:47 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90A8E43D2F; Wed, 2 Jun 2004 15:29:47 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i52MTlgd017656; Wed, 2 Jun 2004 15:29:47 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i52MTl9i017655; Wed, 2 Jun 2004 15:29:47 -0700 (PDT) (envelope-from rizzo) Date: Wed, 2 Jun 2004 15:29:47 -0700 From: Luigi Rizzo To: "Christian S.J. Peron" Message-ID: <20040602152947.B17332@xorpc.icir.org> References: <20040602043537.GA42327@freefall.freebsd.org> <20040602135155.GA31642@freefall.freebsd.org> <20040602213515.GA90619@freefall.freebsd.org> <40BE4BFE.70204@freebsd.org> <20040602221443.GA92431@freefall.freebsd.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: <20040602221443.GA92431@freefall.freebsd.org>; from csjp@freebsd.org on Wed, Jun 02, 2004 at 03:14:43PM -0700 cc: hackers@freebsd.org cc: Andre Oppermann cc: ipfw@freebsd.org Subject: Re: ipfw cached ucred patch X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 22:29:47 -0000 On Wed, Jun 02, 2004 at 03:14:43PM -0700, Christian S.J. Peron wrote: > > I understand what you are saying. The only real other choice > would be to copy out the entire cr_groups array. Do you know > if this copy would be more expensive then the mutex lock/unlock > associated with grabbing a reference to the ucred? i bet the copy it would be cheaper almost on any architecture -- it is only 64 bytes anyways, with these sizes what kills you in memory accesses is the latency, not the throughput. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 15:34:02 2004 Return-Path: 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 7FFEC16A4CE for ; Wed, 2 Jun 2004 15:34:02 -0700 (PDT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E73443D49 for ; Wed, 2 Jun 2004 15:34:02 -0700 (PDT) (envelope-from freebsd-ipfw.20.openmacews@spamgourmet.com) Received: (qmail 32357 invoked from network); 2 Jun 2004 22:34:01 -0000 Received: from ns1.presence-group.net (HELO [172.30.11.6]) (blakers@[216.27.177.134]) )encrypted SMTP for ; 2 Jun 2004 22:34:01 -0000 Date: Wed, 02 Jun 2004 15:33:58 -0700 From: OpenMacNews To: freebsd-ipfw Message-ID: X-Mailer: Mulberry/3.1.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: OpenMacNews List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 22:34:02 -0000 In continued digging for some guidance w.r.t. my earlier post, I came across the following list comment ... > The real show stopper is ipfw with stateful rules using the 'keep state' > option does not work when used with the divert/nated legacy sub-routine. > What this means is ipfw with stateful rules can only be used if > 'user ppp -nat' is how you connect to the public internet. Is this in fact true? If using NATd, am I relegated to a _static_ ruleset, w/ no ability to use stateful rules? Richard From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 15:41:42 2004 Return-Path: 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 5025216A4CE for ; Wed, 2 Jun 2004 15:41:42 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B08043D2D for ; Wed, 2 Jun 2004 15:41:42 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i52Mfegd018122; Wed, 2 Jun 2004 15:41:40 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i52MfeAk018121; Wed, 2 Jun 2004 15:41:40 -0700 (PDT) (envelope-from rizzo) Date: Wed, 2 Jun 2004 15:41:40 -0700 From: Luigi Rizzo To: OpenMacNews Message-ID: <20040602154140.A17902@xorpc.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: ; at 03:33:58PM -0700 cc: freebsd-ipfw Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 22:41:42 -0000 On Wed, Jun 02, 2004 at 03:33:58PM -0700, OpenMacNews wrote: > In continued digging for some guidance w.r.t. my earlier post, I came across the following list comment ... > > > The real show stopper is ipfw with stateful rules using the 'keep state' > > option does not work when used with the divert/nated legacy sub-routine. > > What this means is ipfw with stateful rules can only be used if > > 'user ppp -nat' is how you connect to the public internet. > > Is this in fact true? > If using NATd, am I relegated to a _static_ ruleset, w/ no ability to use stateful rules? just about every sentence above is false. nothing prevents you from using stateful ipfw rules with natd, _but_ you must understand very well the packet's flow and how addresses are transformed or you won't get what you want. personally i see almost always only disadvantages (basically, it is much easier to screw up your configuration) in using both because nat is already stateful cheers luigi > Richard > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 15:47:24 2004 Return-Path: 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 B3F1516A4D0 for ; Wed, 2 Jun 2004 15:47:24 -0700 (PDT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B67143D46 for ; Wed, 2 Jun 2004 15:47:24 -0700 (PDT) (envelope-from freebsd-ipfw.20.openmacews@spamgourmet.com) Received: (qmail 18977 invoked from network); 2 Jun 2004 22:47:24 -0000 Received: from ns1.presence-group.net (HELO [172.30.11.6]) (blakers@[216.27.177.134]) )encrypted SMTP for ; 2 Jun 2004 22:47:23 -0000 Date: Wed, 02 Jun 2004 15:47:21 -0700 From: OpenMacNews To: freebsd-ipfw Message-ID: <7D7540B64898043C025AFB23@[172.30.11.6]> In-Reply-To: <20040602154140.A17902@xorpc.icir.org> References: <20040602154140.A17902@xorpc.icir.org> X-Mailer: Mulberry/3.1.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: Luigi Rizzo Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: OpenMacNews List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 22:47:24 -0000 > just about every sentence above is false. > > nothing prevents you from using stateful ipfw rules with natd, > _but_ you must understand very well the packet's flow and how > addresses are transformed or you won't get what you want. > > personally i see almost always only disadvantages (basically, it is much > easier to screw up your configuration) in using both because nat is > already stateful well, since I'm "not getting what I want" because I'm probably "screw(ing) up my configuration", I suppose this is good news ;-) thanks for the clarification! now, back to slogging through my config problems ... richard From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 16:52:13 2004 Return-Path: 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 941D116A4CE for ; Wed, 2 Jun 2004 16:52:13 -0700 (PDT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C06C43D48 for ; Wed, 2 Jun 2004 16:52:13 -0700 (PDT) (envelope-from freebsd-ipfw.20.openmacews@spamgourmet.com) Received: (qmail 22638 invoked from network); 2 Jun 2004 23:52:12 -0000 Received: from ns1.presence-group.net (HELO [172.30.11.6]) (blakers@[216.27.177.134]) )encrypted SMTP for ; 2 Jun 2004 23:52:12 -0000 Date: Wed, 02 Jun 2004 16:52:09 -0700 From: OpenMacNews To: freebsd-ipfw Message-ID: <183AEFC8C407F14A0032B498@[172.30.11.6]> X-Mailer: Mulberry/3.1.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: any ipfw + nat gurus out there? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: OpenMacNews List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2004 23:52:13 -0000 hi all, i've gotten no "bites" so far on my 1st "i'm SO confused!" email, so I'll try a narrower example/question ... in the simple case of [public internet] | | [ISP's gateway router] external IP = R.R.R.R | | ====FIREWALL============================ NIC card 1 ("exif"), multihomed external IP = A.A.A.1 external IP = A.A.A.2 | | ipfw natd1 on external IP A.A.A.1 natd2 on external IP A.A.A.2 | | NIC card 3, internal IP = 10.0.0.B =========================================== | | | | | =====WORKSTATION=========================== NIC card 1, internal IP = 10.0.0.C =========================================== using SSH as a service example, i'd like to: allow a public internet address, IP = C.C.C.1, to ssh to WORKSTATION *only* via EXTERNAL ip = A.A.A.1 allow a public internet address, IP = C.C.C.2, to ssh to WORKSTATION *only* via EXTERNAL ip = A.A.A.2 allow ssh from WORKSTATION to ANY internal/external IP primarily via A.A.A.1, except ssh traffic TO C.C.C.2 should be OUT via A.A.A.2 deny all other ssh traffic to do this, I can understand that i'm going to have to "remember" some state .... unfortunately, I've only gotten the following figured out ... 1st, I enable IP forwarding: /usr/sbin/sysctl -w net.inet.ip.forwarding=1 > /dev/null then I launch a NATd instance on EACH of the firewall box's external interfaces, exipA & exipB, and enable redirection to WORKSTATION # variables exipA = "A.A.A.1" exipB = "A.A.A.2" inip = "10.0.0.B" gateway = "R.R.R.R" natd_portA_in= "8668" natd_portA_out= "8669" natd_portB_in= "8670" natd_portB_out= "8671" # natd instances /usr/sbin/natd \ -alias_address ${exipA} \ -in_port ${natd_portA_in} \ -out_port ${natd_portA_out} \ -dynamic -use_sockets -same_ports -unregistered_only -log -log_denied \ -redirect_port tcp ${WORKSTATION}:22 22 /usr/sbin/natd \ -alias_address ${exipB} \ -in_port ${natd_portB_in} \ -out_port ${natd_portB_out} \ -dynamic -use_sockets -same_ports -unregistered_only -log -log_denied \ -redirect_port tcp ${WORKSTATION}:22 22 Now the rest is what I need some guidance on ... 1st, for the single-case ssh traffic from WORKSTATION to public internet address = C.C.C.2, which MUST travel via A.A.A.2, I think ${fwcmd} add 10000 divert ${natd_portB_out} ip from ${inip} to C.C.C.2 22 out xmit ${exif} does the trick. however, my understanding is that, after natd, the ip packet's src will be rewritten to IP of exipB, so I may need to send via fwd the packet to next-hop -- i.e., the ISP's gateway router, using ${fwcmd} add 10005 fwd ${gateway} ip from ${exipA} to any 2nd, for the catch-all outbound ssh case, outbound must travel via A.A.A.1 ${fwcmd} add 11000 divert ${natd_portA_out} ip from ${inip} to any out xmit ${exif} and again, ${fwcmd} add 11005 fwd ${gateway} ip from ${exipB} to any and last, general INBOUND catch all traffic via public internet to EITHER exipA or exipB ${fwcmd} add 12000 divert ${natd_portA_in} ip from any to any in via ${exifA} ${fwcmd} add 12010 skipto 50000 ip from any to any ${fwcmd} add 13000 divert ${natd_portB_ip} ip from any to any in via ${exifA} ${fwcmd} add 13010 skipto 50000 ip from any to any # 50000 ( ... continue processing ... ) which, in summary, looks like: ${fwcmd} add 10000 divert ${natd_portB_out} ip from ${inip} to C.C.C.2 22 out xmit ${exif} ${fwcmd} add 10005 fwd ${gateway} ip from ${exipA} to any ${fwcmd} add 11000 divert ${natd_portA_out} ip from ${inip} to any out xmit ${exif} ${fwcmd} add 11005 fwd ${gateway} ip from ${exipB} to any ${fwcmd} add 12000 divert ${natd_portA_in} ip from any to any in via ${exifA} ${fwcmd} add 12010 skipto 50000 ip from any to any ${fwcmd} add 13000 divert ${natd_portB_ip} ip from any to any in via ${exifA} ${fwcmd} add 13010 skipto 50000 ip from any to any # 50000 ( ... continue processing ... ) i am NOT at all sure that I'm accomplishing what I want/need here ... AND if/where I stick any necessary DENY rules (on EXTERNAL or INTERNAL addresses?) any help is much appreciated !! richard From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 17:39:19 2004 Return-Path: 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 2B9B616A4CE for ; Wed, 2 Jun 2004 17:39:19 -0700 (PDT) Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id C37B543D1F for ; Wed, 2 Jun 2004 17:39:18 -0700 (PDT) (envelope-from Barbish3@adelphia.net) Received: from barbish ([67.20.101.71]) by mta11.adelphia.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040603003918.CWDF21898.mta11.adelphia.net@barbish>; Wed, 2 Jun 2004 20:39:18 -0400 From: "JJB" To: "Luigi Rizzo" , "OpenMacNews" Date: Wed, 2 Jun 2004 20:39:16 -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.6604 (9.0.2911.0) In-Reply-To: <20040602154140.A17902@xorpc.icir.org> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal cc: freebsd-ipfw Subject: RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Barbish3@adelphia.net List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 00:39:19 -0000 Luigi, Your statement is very generic and so easy to make, when there is no proof given to back it up. There is no documentation that backs up your statement that says that stateful rules will work in an nated environment. Better yet, here is an stateful rule set that works with no lan behind the firewall machine. I would like to see just how you would change it to get it to work in an nated environment. I think once you start trying to get it to work you will come to realize the problem ipfw has using stateful rules in an nated environment first hand. The problem is the content of the dynamic table is always different no matter where you position the divert rule in the rule set which causes the dynamic table content to never match. ################ Start of IPFW rules file ############################### # Flush out the list before we begin. ipfw -q -f flush # Set rules command prefix cmd="ipfw -q add" pif="dc0" # public interface name of Nic card # facing the public internet ################################################################# # No restrictions on Loopback Interface ################################################################# $cmd 00010 allow all from any to any via lo0 ################################################################# # Allow the packet through if it has previous been added to the # the "dynamic" rules table by an allow keep-state statement. ################################################################# $cmd 00015 check-state ################################################################# # Interface facing Public internet (Outbound Section) # Interrogate session start requests originating from this gateway server # destine for the public internet. ################################################################# # Allow out access to my ISP's Domain name server. # x.x.x.x must be the IP address of your ISP's DNS $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state # Allow out access to my ISP's DHCP server for cable/DSL configurations. #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state # Allow out non-secure standard www function $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state # Allow out secure www function https over TLS SSL $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state # Allow out send & get email function $cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state # Allow out FBSD (make install & CVSUP) functions # Basically give user root "GOD" privileges. $cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root # Allow out ping $cmd 00250 allow icmp from any to any out via $pif keep-state # Allow out Time $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state # Allow out nntp news (IE: news groups) $cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state # Allow out secure FTP, Telnet, and SCP # This function is using SSH (secure shell) $cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state # Allow out whois $cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state # deny and log everything else that's trying to get out. # This rule enforces the block all by default logic. $cmd 00299 deny log all from any to any out via $pif ################################################################# # Interface facing Public internet (Inbound Section) # Interrogate packets originating from the public internet # destine for this gateway server ################################################################# # Deny all inbound traffic from non-routable reserved address spaces $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP $cmd 00301 deny all from 172.16.0.0/12 to anyin via $pif #RFC 1918 private IP $cmd 00302 deny all from 10.0.0.0/8 to anyin via $pif #RFC 1918 private IP $cmd 00303 deny all from 127.0.0.0/8 to anyin via $pif #loopback $cmd 00304 deny all from 0.0.0.0/8 to anyin via $pif #loopback $cmd 00305 deny all from 169.254.0.0/16 to anyin via $pif #DHCP auto-config $cmd 00306 deny all from 192.0.2.0/24 to anyin via $pif #reserved for doc's $cmd 00307 deny all from 204.152.64.0/23 to anyin via $pif #Sun cluster interconnect $cmd 00308 deny all from 224.0.0.0/3 to anyin via $pif #Class D & E multicast # Deny public pings $cmd 00310 deny icmp from any to anyin via $pif # Deny ident $cmd 00315 deny tcp from any to any 113in via $pif # Deny all Netbios service. 137=name, 138=datagram, 139=session # Netbios is MS/Windows sharing services. # Block MS/Windows hosts2 name server requests 81 $cmd 00320 deny tcp from any to any 137in via $pif $cmd 00321 deny tcp from any to any 138in via $pif $cmd 00322 deny tcp from any to any 139in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Deny any late arriving packets $cmd 00330 deny all from any to any frag in via $pif # Deny ACK packets that did not match the dynamic rule table $cmd 00332 deny tcp from any to any established in via $pif # Allow traffic in from ISP's DHCP server. This rule must contain # the IP address of your ISP's DHCP server as it's the only # authorized source to send this packet type. $cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state # Allow in standard www function because I have apache server $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Allow in secure FTP, Telnet, and SCP from public Internet $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Allow in non-secure Telnet session from public Internet # labeled non-secure because ID & PW are passed over public # internet as clear text. $cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Reject & Log all incoming connections from the outside $cmd 00499 deny log all from any to any in via $pif # Everything else is denied by default # deny and log all packets that fell through to see what they are $cmd 00999 deny log all from any to any ################ End of IPFW rules file ############################### -----Original Message----- From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd-ipfw@freebsd.org]On Behalf Of Luigi Rizzo Sent: Wednesday, June 02, 2004 6:42 PM To: OpenMacNews Cc: freebsd-ipfw Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? On Wed, Jun 02, 2004 at 03:33:58PM -0700, OpenMacNews wrote: > In continued digging for some guidance w.r.t. my earlier post, I came across the following list comment ... > > > The real show stopper is ipfw with stateful rules using the 'keep state' > > option does not work when used with the divert/nated legacy sub-routine. > > What this means is ipfw with stateful rules can only be used if > > 'user ppp -nat' is how you connect to the public internet. > > Is this in fact true? > If using NATd, am I relegated to a _static_ ruleset, w/ no ability to use stateful rules? just about every sentence above is false. nothing prevents you from using stateful ipfw rules with natd, _but_ you must understand very well the packet's flow and how addresses are transformed or you won't get what you want. personally i see almost always only disadvantages (basically, it is much easier to screw up your configuration) in using both because nat is already stateful cheers luigi > Richard > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 19:13:13 2004 Return-Path: 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 5968616A4CF for ; Wed, 2 Jun 2004 19:13:13 -0700 (PDT) Received: from mail.1wisp.com (uslec-66-255-6-131.cust.uslec.net [66.255.6.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3686943D49 for ; Wed, 2 Jun 2004 19:13:12 -0700 (PDT) (envelope-from tscrum@1wisp.com) Received: from wolf (69-166-70-88.atlsfl.adelphia.net [69.166.70.88]) (authenticated) by mail.1wisp.com (8.11.6/8.11.6) with ESMTP id i532DCi16262 for ; Wed, 2 Jun 2004 22:13:12 -0400 From: "Thomas S. Crum - 1WISP, Inc." To: "'freebsd-ipfw'" Date: Wed, 2 Jun 2004 22:12:58 -0400 Message-ID: <00f901c44910$50cfb330$6466a8c0@wolf> 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, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2739.300 In-Reply-To: Subject: RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 02:13:13 -0000 The proof in Luigi's statement is the fact that it is signed Luigi. I must tell you my friend that there are some EXCELLENT sources from EXPERTS available to those willing to learn on this board. Experts who have personally contributed to writing IPFW and its packages. Your personal attacks reflect not only your inexperience, but also your inability to learn. Nobody owes anyone an answer on this board. Even an educated suggestion from those here should be humbly looked at as a gift. Best, Thomas S. Crum Senior Technical Associate tscrum@aaawebsolution.com Toll-free: (800) 834-0626 AAA Web Solution, Inc. 11924 W Forest Hill Boulevard Building 22 - Mailstop 200 Wellington, FL 33414 USA Providing full-service website design, maintenance, hosting, and marketing. No task is too small or enterprise too large for us to help you! ------------------------------------------------------------------------ ---- -----Original Message----- From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd-ipfw@freebsd.org] On Behalf Of JJB Sent: Wednesday, June 02, 2004 8:39 PM To: Luigi Rizzo; OpenMacNews Cc: freebsd-ipfw Subject: RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? Luigi, Your statement is very generic and so easy to make, when there is no proof given to back it up. There is no documentation that backs up your statement that says that stateful rules will work in an nated environment. Better yet, here is an stateful rule set that works with no lan behind the firewall machine. I would like to see just how you would change it to get it to work in an nated environment. I think once you start trying to get it to work you will come to realize the problem ipfw has using stateful rules in an nated environment first hand. The problem is the content of the dynamic table is always different no matter where you position the divert rule in the rule set which causes the dynamic table content to never match. ################ Start of IPFW rules file ############################### # Flush out the list before we begin. ipfw -q -f flush # Set rules command prefix cmd="ipfw -q add" pif="dc0" # public interface name of Nic card # facing the public internet ################################################################# # No restrictions on Loopback Interface ################################################################# $cmd 00010 allow all from any to any via lo0 ################################################################# # Allow the packet through if it has previous been added to the # the "dynamic" rules table by an allow keep-state statement. ################################################################# $cmd 00015 check-state ################################################################# # Interface facing Public internet (Outbound Section) # Interrogate session start requests originating from this gateway server # destine for the public internet. ################################################################# # Allow out access to my ISP's Domain name server. # x.x.x.x must be the IP address of your ISP's DNS $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state # Allow out access to my ISP's DHCP server for cable/DSL configurations. #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state # Allow out non-secure standard www function $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state # Allow out secure www function https over TLS SSL $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state # Allow out send & get email function $cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state # Allow out FBSD (make install & CVSUP) functions # Basically give user root "GOD" privileges. $cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root # Allow out ping $cmd 00250 allow icmp from any to any out via $pif keep-state # Allow out Time $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state # Allow out nntp news (IE: news groups) $cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state # Allow out secure FTP, Telnet, and SCP # This function is using SSH (secure shell) $cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state # Allow out whois $cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state # deny and log everything else that's trying to get out. # This rule enforces the block all by default logic. $cmd 00299 deny log all from any to any out via $pif ################################################################# # Interface facing Public internet (Inbound Section) # Interrogate packets originating from the public internet # destine for this gateway server ################################################################# # Deny all inbound traffic from non-routable reserved address spaces $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP $cmd 00301 deny all from 172.16.0.0/12 to anyin via $pif #RFC 1918 private IP $cmd 00302 deny all from 10.0.0.0/8 to anyin via $pif #RFC 1918 private IP $cmd 00303 deny all from 127.0.0.0/8 to anyin via $pif #loopback $cmd 00304 deny all from 0.0.0.0/8 to anyin via $pif #loopback $cmd 00305 deny all from 169.254.0.0/16 to anyin via $pif #DHCP auto-config $cmd 00306 deny all from 192.0.2.0/24 to anyin via $pif #reserved for doc's $cmd 00307 deny all from 204.152.64.0/23 to anyin via $pif #Sun cluster interconnect $cmd 00308 deny all from 224.0.0.0/3 to anyin via $pif #Class D & E multicast # Deny public pings $cmd 00310 deny icmp from any to anyin via $pif # Deny ident $cmd 00315 deny tcp from any to any 113in via $pif # Deny all Netbios service. 137=name, 138=datagram, 139=session # Netbios is MS/Windows sharing services. # Block MS/Windows hosts2 name server requests 81 $cmd 00320 deny tcp from any to any 137in via $pif $cmd 00321 deny tcp from any to any 138in via $pif $cmd 00322 deny tcp from any to any 139in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Deny any late arriving packets $cmd 00330 deny all from any to any frag in via $pif # Deny ACK packets that did not match the dynamic rule table $cmd 00332 deny tcp from any to any established in via $pif # Allow traffic in from ISP's DHCP server. This rule must contain # the IP address of your ISP's DHCP server as it's the only # authorized source to send this packet type. $cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state # Allow in standard www function because I have apache server $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Allow in secure FTP, Telnet, and SCP from public Internet $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Allow in non-secure Telnet session from public Internet # labeled non-secure because ID & PW are passed over public # internet as clear text. $cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Reject & Log all incoming connections from the outside $cmd 00499 deny log all from any to any in via $pif # Everything else is denied by default # deny and log all packets that fell through to see what they are $cmd 00999 deny log all from any to any ################ End of IPFW rules file ############################### -----Original Message----- From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd-ipfw@freebsd.org]On Behalf Of Luigi Rizzo Sent: Wednesday, June 02, 2004 6:42 PM To: OpenMacNews Cc: freebsd-ipfw Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? On Wed, Jun 02, 2004 at 03:33:58PM -0700, OpenMacNews wrote: > In continued digging for some guidance w.r.t. my earlier post, I came across the following list comment ... > > > The real show stopper is ipfw with stateful rules using the 'keep state' > > option does not work when used with the divert/nated legacy sub-routine. > > What this means is ipfw with stateful rules can only be used if > > 'user ppp -nat' is how you connect to the public internet. > > Is this in fact true? > If using NATd, am I relegated to a _static_ ruleset, w/ no ability to use stateful rules? just about every sentence above is false. nothing prevents you from using stateful ipfw rules with natd, _but_ you must understand very well the packet's flow and how addresses are transformed or you won't get what you want. personally i see almost always only disadvantages (basically, it is much easier to screw up your configuration) in using both because nat is already stateful cheers luigi > Richard > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 19:20:32 2004 Return-Path: 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 9384B16A4CE for ; Wed, 2 Jun 2004 19:20:32 -0700 (PDT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C6EC43D1D for ; Wed, 2 Jun 2004 19:20:32 -0700 (PDT) (envelope-from freebsd-ipfw.20.openmacews@spamgourmet.com) Received: (qmail 12588 invoked from network); 3 Jun 2004 02:20:21 -0000 Received: from ns1.presence-group.net (HELO [172.30.11.6]) (blakers@[216.27.177.134]) )encrypted SMTP for ; 3 Jun 2004 02:20:21 -0000 Date: Wed, 02 Jun 2004 19:20:19 -0700 From: OpenMacNews To: freebsd-ipfw Message-ID: In-Reply-To: <00f901c44910$50cfb330$6466a8c0@wolf> References: <00f901c44910$50cfb330$6466a8c0@wolf> X-Mailer: Mulberry/3.1.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: "Thomas S. Crum - 1WISP, Inc." Subject: RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: OpenMacNews List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 02:20:32 -0000 > Your personal attacks reflect not only your inexperience, but also your > inability to learn. Nobody owes anyone an answer on this board. Even an > educated suggestion from those here should be humbly looked at as a > gift. ok, now. no "uppity hijacking" of my thread! i'm just trying to do a little learnin' ! just so y'all all clear *I* didn't start the "shooting", or question anybody's skill/experience/expertise/etc. and that I'm still confused over here ... cheers, richard From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 20:16:31 2004 Return-Path: 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 BD96816A4CE for ; Wed, 2 Jun 2004 20:16:31 -0700 (PDT) Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3582843D1F for ; Wed, 2 Jun 2004 20:16:31 -0700 (PDT) (envelope-from Barbish3@adelphia.net) Received: from barbish ([67.20.101.71]) by mta10.adelphia.net (InterMail vM.5.01.06.08 201-253-122-130-108-20031117) with SMTP id <20040603031630.XYBR8065.mta10.adelphia.net@barbish>; Wed, 2 Jun 2004 23:16:30 -0400 From: "JJB" To: "Thomas S. Crum - 1WISP, Inc." , "'freebsd-ipfw'" Date: Wed, 2 Jun 2004 23:16:29 -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.6604 (9.0.2911.0) In-Reply-To: <00f901c44910$50cfb330$6466a8c0@wolf> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal Subject: RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Barbish3@adelphia.net List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 03:16:31 -0000 Where do you get off calling my questioning of Luigi Rizzo's answer as an attack. I have heard that party line statement all to often over that last 4 years, with no backup proof. That party line canned answer may be sufficient for the original thread poster who has not invested the time yet to come to the realization that it doe's not work. My post to the tread was meant to bring this problem out so the experts can look into it and take corrective actions. I know that Luigi Rizzo has rewritten ipfw into ipfw2, but he did not address this problem of stateful rules and nated in his rewrite. He left the nated divert rule alone and concentrated on the main logic of ipfw which I do not fault him for. It's time to bring this problem to the person who can really do something about it now that ipfw/ipfw2 is stable. I am not the only person who has posted this problem over the years, without receiving an example showing it working. I gave an common stateful example for him or you for that matter to build an working nated example from. So quit trying to side line the main question by calling it an attack. I see right through what you are trying to accomplish by your post and it will not work as I can not be intimidated. And yes I know about the method of forcing it to work by putting the same stateful rules on the Lan interface so the dynamic rules table cross matches in what is technically an error. It's now time to address this problem so it can be fixed or at least have the documentation changed so it includes an example of how to code it correctly, or just come right out and put the statement in the documentation man ipfw info that stateful rules do not function when used with nated divert rule. -----Original Message----- From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd-ipfw@freebsd.org]On Behalf Of Thomas S. Crum - 1WISP, Inc. Sent: Wednesday, June 02, 2004 10:13 PM To: 'freebsd-ipfw' Subject: RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? The proof in Luigi's statement is the fact that it is signed Luigi. I must tell you my friend that there are some EXCELLENT sources from EXPERTS available to those willing to learn on this board. Experts who have personally contributed to writing IPFW and its packages. Your personal attacks reflect not only your inexperience, but also your inability to learn. Nobody owes anyone an answer on this board. Even an educated suggestion from those here should be humbly looked at as a gift. Best, Thomas S. Crum Senior Technical Associate tscrum@aaawebsolution.com Toll-free: (800) 834-0626 AAA Web Solution, Inc. 11924 W Forest Hill Boulevard Building 22 - Mailstop 200 Wellington, FL 33414 USA Providing full-service website design, maintenance, hosting, and marketing. No task is too small or enterprise too large for us to help you! -------------------------------------------------------------------- ---- ---- -----Original Message----- From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd-ipfw@freebsd.org] On Behalf Of JJB Sent: Wednesday, June 02, 2004 8:39 PM To: Luigi Rizzo; OpenMacNews Cc: freebsd-ipfw Subject: RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? Luigi, Your statement is very generic and so easy to make, when there is no proof given to back it up. There is no documentation that backs up your statement that says that stateful rules will work in an nated environment. Better yet, here is an stateful rule set that works with no lan behind the firewall machine. I would like to see just how you would change it to get it to work in an nated environment. I think once you start trying to get it to work you will come to realize the problem ipfw has using stateful rules in an nated environment first hand. The problem is the content of the dynamic table is always different no matter where you position the divert rule in the rule set which causes the dynamic table content to never match. ################ Start of IPFW rules file ############################### # Flush out the list before we begin. ipfw -q -f flush # Set rules command prefix cmd="ipfw -q add" pif="dc0" # public interface name of Nic card # facing the public internet ################################################################# # No restrictions on Loopback Interface ################################################################# $cmd 00010 allow all from any to any via lo0 ################################################################# # Allow the packet through if it has previous been added to the # the "dynamic" rules table by an allow keep-state statement. ################################################################# $cmd 00015 check-state ################################################################# # Interface facing Public internet (Outbound Section) # Interrogate session start requests originating from this gateway server # destine for the public internet. ################################################################# # Allow out access to my ISP's Domain name server. # x.x.x.x must be the IP address of your ISP's DNS $cmd 00110 allow tcp from any to x.x.x.x 53 out via $pif setup keep-state $cmd 00111 allow udp from any to x.x.x.x 53 out via $pif keep-state # Allow out access to my ISP's DHCP server for cable/DSL configurations. #$cmd 00120 allow udp from any to x.x.x.x 67 out via $pif keep-state # Allow out non-secure standard www function $cmd 00200 allow tcp from any to any 80 out via $pif setup keep-state # Allow out secure www function https over TLS SSL $cmd 00220 allow tcp from any to any 443 out via $pif setup keep-state # Allow out send & get email function $cmd 00230 allow tcp from any to any 25 out via $pif setup keep-state $cmd 00231 allow tcp from any to any 110 out via $pif setup keep-state # Allow out FBSD (make install & CVSUP) functions # Basically give user root "GOD" privileges. $cmd 00240 allow tcp from me to any out via $pif setup keep-state uid root # Allow out ping $cmd 00250 allow icmp from any to any out via $pif keep-state # Allow out Time $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state # Allow out nntp news (IE: news groups) $cmd 00270 allow tcp from any to any 119 out via $pif setup keep-state # Allow out secure FTP, Telnet, and SCP # This function is using SSH (secure shell) $cmd 00280 allow tcp from any to any 22 out via $pif setup keep-state # Allow out whois $cmd 00290 allow tcp from any to any 43 out via $pif setup keep-state # deny and log everything else that's trying to get out. # This rule enforces the block all by default logic. $cmd 00299 deny log all from any to any out via $pif ################################################################# # Interface facing Public internet (Inbound Section) # Interrogate packets originating from the public internet # destine for this gateway server ################################################################# # Deny all inbound traffic from non-routable reserved address spaces $cmd 00300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP $cmd 00301 deny all from 172.16.0.0/12 to anyin via $pif #RFC 1918 private IP $cmd 00302 deny all from 10.0.0.0/8 to anyin via $pif #RFC 1918 private IP $cmd 00303 deny all from 127.0.0.0/8 to anyin via $pif #loopback $cmd 00304 deny all from 0.0.0.0/8 to anyin via $pif #loopback $cmd 00305 deny all from 169.254.0.0/16 to anyin via $pif #DHCP auto-config $cmd 00306 deny all from 192.0.2.0/24 to anyin via $pif #reserved for doc's $cmd 00307 deny all from 204.152.64.0/23 to anyin via $pif #Sun cluster interconnect $cmd 00308 deny all from 224.0.0.0/3 to anyin via $pif #Class D & E multicast # Deny public pings $cmd 00310 deny icmp from any to anyin via $pif # Deny ident $cmd 00315 deny tcp from any to any 113in via $pif # Deny all Netbios service. 137=name, 138=datagram, 139=session # Netbios is MS/Windows sharing services. # Block MS/Windows hosts2 name server requests 81 $cmd 00320 deny tcp from any to any 137in via $pif $cmd 00321 deny tcp from any to any 138in via $pif $cmd 00322 deny tcp from any to any 139in via $pif $cmd 00323 deny tcp from any to any 81 in via $pif # Deny any late arriving packets $cmd 00330 deny all from any to any frag in via $pif # Deny ACK packets that did not match the dynamic rule table $cmd 00332 deny tcp from any to any established in via $pif # Allow traffic in from ISP's DHCP server. This rule must contain # the IP address of your ISP's DHCP server as it's the only # authorized source to send this packet type. $cmd 00360 allow udp from any to x.x.x.x 67 in via $pif keep-state # Allow in standard www function because I have apache server $cmd 00400 allow tcp from any to me 80 in via $pif setup limit src-addr 2 # Allow in secure FTP, Telnet, and SCP from public Internet $cmd 00410 allow tcp from any to me 22 in via $pif setup limit src-addr 2 # Allow in non-secure Telnet session from public Internet # labeled non-secure because ID & PW are passed over public # internet as clear text. $cmd 00420 allow tcp from any to me 23 in via $pif setup limit src-addr 2 # Reject & Log all incoming connections from the outside $cmd 00499 deny log all from any to any in via $pif # Everything else is denied by default # deny and log all packets that fell through to see what they are $cmd 00999 deny log all from any to any ################ End of IPFW rules file ############################### -----Original Message----- From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd-ipfw@freebsd.org]On Behalf Of Luigi Rizzo Sent: Wednesday, June 02, 2004 6:42 PM To: OpenMacNews Cc: freebsd-ipfw Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? On Wed, Jun 02, 2004 at 03:33:58PM -0700, OpenMacNews wrote: > In continued digging for some guidance w.r.t. my earlier post, I came across the following list comment ... > > > The real show stopper is ipfw with stateful rules using the 'keep state' > > option does not work when used with the divert/nated legacy sub-routine. > > What this means is ipfw with stateful rules can only be used if > > 'user ppp -nat' is how you connect to the public internet. > > Is this in fact true? > If using NATd, am I relegated to a _static_ ruleset, w/ no ability to use stateful rules? just about every sentence above is false. nothing prevents you from using stateful ipfw rules with natd, _but_ you must understand very well the packet's flow and how addresses are transformed or you won't get what you want. personally i see almost always only disadvantages (basically, it is much easier to screw up your configuration) in using both because nat is already stateful cheers luigi > Richard > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 20:35:44 2004 Return-Path: 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 B7CCA16A4CE for ; Wed, 2 Jun 2004 20:35:44 -0700 (PDT) Received: from www.nativenerds.com (host-12-49-220-24.midco.net [24.220.49.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC9B643D49 for ; Wed, 2 Jun 2004 20:35:43 -0700 (PDT) (envelope-from estover@nativenerds.com) Received: from [192.168.1.196] ([192.168.1.196]) by www.nativenerds.com (8.12.8p1/8.12.8) with ESMTP id i533hhLx051813 for ; Wed, 2 Jun 2004 21:43:43 -0600 (MDT) (envelope-from estover@nativenerds.com) From: Ed Stover To: freebsd-ipfw@freebsd.org In-Reply-To: <20040531190055.AE76716A4DB@hub.freebsd.org> References: <20040531190055.AE76716A4DB@hub.freebsd.org> Content-Type: text/plain; charset=UTF-8 Organization: Native Nerds Message-Id: <1086233744.12655.1477.camel@Macinlinuz> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5a) Date: 02 Jun 2004 21:35:45 -0600 Content-Transfer-Encoding: 8bit Subject: Re: freebsd-ipfw Digest, Vol 62, Issue 1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: estover@nativenerds.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 03:35:44 -0000 Me personally , I would implement black holing. Want to give the impression that you machine is not turned on. IPFW can deny the packets but black holing will completely drop them. 1. Edit your /etc/sysctl.conf a.add these lines net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 These will modify your OS fingerprint and only syn scans will work and they will work real slow. On Mon, 2004-05-31 at 13:00, freebsd-ipfw-request@freebsd.org wrote: > Send freebsd-ipfw mailing list submissions to > freebsd-ipfw@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > or, via email, send a message with subject or body 'help' to > freebsd-ipfw-request@freebsd.org > > You can reach the person managing the list at > freebsd-ipfw-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-ipfw digest..." > > > Today's Topics: > > 1. newbie question (El DaEm0n) > 2. Re: newbie question (Chuck Swiger) > 3. Re: newbie question (El DaEm0n) > 4. Re: newbie question (Chuck Swiger) > 5. Current problem reports assigned to you (FreeBSD bugmaster) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 31 May 2004 00:05:13 +0000 > From: "El DaEm0n" > Subject: newbie question > To: freebsd-ipfw@freebsd.org > Message-ID: > Content-Type: text/plain; charset=iso-8859-1; format=flowed > > hi guys, i have a question how can i made with IPW show portscan that my > system is down? > > _________________________________________________________________ > MSN Fotos: la forma más fácil de compartir e imprimir fotos. > http://photos.msn.es/support/worldwide.aspx > > > ------------------------------ > > Message: 2 > Date: Mon, 31 May 2004 12:46:11 -0400 > From: Chuck Swiger > Subject: Re: newbie question > To: El DaEm0n > Cc: freebsd-ipfw@freebsd.org > Message-ID: <40BB6153.5050604@mac.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > El DaEm0n wrote: > > hi guys, i have a question how can i made with IPW show portscan that > > my system is down? > > Disconnect the ethernet cable? > "ipfw add 10 deny ip from any to any" > > ...a little more context would help us give a more useful answer. > > -- > -Chuck > > > ------------------------------ > > Message: 3 > Date: Mon, 31 May 2004 17:22:36 +0000 > From: "El DaEm0n" > Subject: Re: newbie question > To: freebsd-ipfw@freebsd.org > Message-ID: > Content-Type: text/plain; charset=iso-8859-1; format=flowed > > ok my problem is when i made a portscan to my server in another pc it > revealed my open ports, so all i wanna do is when i made a ports scan from > another pc to my server mi IPFW show to portscan that my system appears > down, > > i see this in other systems using PF but i wanna know how to make using > IPFW > can you help? > > thanks! > > > >El DaEm0n wrote: > >>hi guys, i have a question how can i made with IPW show portscan that my > >>system is down? > > > >Disconnect the ethernet cable? > >"ipfw add 10 deny ip from any to any" > > > >...a little more context would help us give a more useful answer. > > > >-- > >-Chuck > > _________________________________________________________________ > MSN Fotos: la forma más fácil de compartir e imprimir fotos. > http://photos.msn.es/support/worldwide.aspx > > > ------------------------------ > > Message: 4 > Date: Mon, 31 May 2004 13:58:00 -0400 > From: Chuck Swiger > Subject: Re: newbie question > To: El DaEm0n > Cc: freebsd-ipfw@freebsd.org > Message-ID: <40BB7228.904@mac.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > El DaEm0n wrote: > > ok my problem is when i made a portscan to my server in another pc it > > revealed my open ports, so all i wanna do is when i made a ports scan > > from another pc to my server mi IPFW show to portscan that my system > > appears down, > > You probably want to use something like this, from "man ipfw": > > The typical use of dynamic rules is to keep a closed firewall configura- > tion, but let the first TCP SYN packet from the inside network install a > dynamic rule for the flow so that packets belonging to that session will > be allowed through the firewall: > > ipfw add check-state > ipfw add allow tcp from my-subnet to any setup keep-state > ipfw add deny tcp from any to any > > Going beyond these examples to a meaningful firewall configuration involves > thinking about your security policy, considering roles and required services, > etc.... From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 21:43:08 2004 Return-Path: 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 E5C7216A4CF for ; Wed, 2 Jun 2004 21:43:07 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAD7D43D41 for ; Wed, 2 Jun 2004 21:43:07 -0700 (PDT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i534h1gd056530; Wed, 2 Jun 2004 21:43:01 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i534h1sJ056529; Wed, 2 Jun 2004 21:43:01 -0700 (PDT) (envelope-from rizzo) Date: Wed, 2 Jun 2004 21:43:01 -0700 From: Luigi Rizzo To: JJB Message-ID: <20040602214301.A55108@xorpc.icir.org> References: <00f901c44910$50cfb330$6466a8c0@wolf> 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 Barbish3@adelphia.net on Wed, Jun 02, 2004 at 11:16:29PM -0400 cc: 'freebsd-ipfw' cc: "Thomas S. Crum - 1WISP, Inc." Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 04:43:08 -0000 On Wed, Jun 02, 2004 at 11:16:29PM -0400, JJB wrote: ... > I know that Luigi Rizzo has rewritten ipfw into ipfw2, but he did > not address this problem of stateful rules and nated in his rewrite. there is not any problem except the fact that making the two things work together is a difficult thing and highly dependent on the specific features that you need. Given that this is (to me) a useless thing to do, i am not going to waste time and provide a solution every time someone challenges me with his own specific example. Of course you are free not to trust my words no matter who i am. But you seem to raise another issue, namely the lack of in-kernel NAT for ipfw. Yes, this is a missing feature. In-kernel NAT support for well-designed protocols (e.g. ssh, http etc.) is trivial and i have already done it a few times, for ipfw1 and ipfw2. But replicating all of libalias is an immensely boring task, which i have not much interest in doing, and given that there are alternatives packet filters, i suggest people to use them if they are not happy with the performance of natd or the complexity of writing a working configuration with belt and suspenders this is all i have to say on the topic luigi > > # Reject & Log all incoming connections from the outside > $cmd 00499 deny log all from any to any in via $pif > > # Everything else is denied by default > # deny and log all packets that fell through to see what they are > $cmd 00999 deny log all from any to any > ################ End of IPFW rules file > ############################### > > > > -----Original Message----- > From: owner-freebsd-ipfw@freebsd.org > [mailto:owner-freebsd-ipfw@freebsd.org]On Behalf Of Luigi Rizzo > Sent: Wednesday, June 02, 2004 6:42 PM > To: OpenMacNews > Cc: freebsd-ipfw > Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ > keep-state? > > On Wed, Jun 02, 2004 at 03:33:58PM -0700, OpenMacNews wrote: > > In continued digging for some guidance w.r.t. my earlier post, I > came across the following list comment ... > > > > > The real show stopper is ipfw with stateful rules using > the 'keep state' > > > option does not work when used with the divert/nated > legacy sub-routine. > > > What this means is ipfw with stateful rules can only be > used if > > > 'user ppp -nat' is how you connect to the public > internet. > > > > Is this in fact true? > > If using NATd, am I relegated to a _static_ ruleset, w/ no ability > to use stateful rules? > > just about every sentence above is false. > > nothing prevents you from using stateful ipfw rules with natd, > _but_ you must understand very well the packet's flow and how > addresses are transformed or you won't get what you want. > > personally i see almost always only disadvantages (basically, it is > much > easier to screw up your configuration) in using both because nat is > already stateful > > cheers > luigi > > Richard > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to > "freebsd-ipfw-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 21:51:48 2004 Return-Path: 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 59DE416A4CE for ; Wed, 2 Jun 2004 21:51:48 -0700 (PDT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F98643D5A for ; Wed, 2 Jun 2004 21:51:48 -0700 (PDT) (envelope-from freebsd-ipfw.20.openmacews@spamgourmet.com) Received: (qmail 21699 invoked from network); 3 Jun 2004 04:51:47 -0000 Received: from ns1.presence-group.net (HELO [172.30.11.6]) (blakers@[216.27.177.134]) )encrypted SMTP for ; 3 Jun 2004 04:51:47 -0000 Date: Wed, 02 Jun 2004 21:51:45 -0700 From: OpenMacNews To: freebsd-ipfw Message-ID: <92234AFA11C59EC7B7F8B9F3@[172.30.11.6]> In-Reply-To: <20040602214301.A55108@xorpc.icir.org> References: <00f901c44910$50cfb330$6466a8c0@wolf> <20040602214301.A55108@xorpc.icir.org> X-Mailer: Mulberry/3.1.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: Luigi Rizzo Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: OpenMacNews List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 04:51:48 -0000 > and given that there are alternatives packet filters, > i suggest people to use them if they are not happy with the > performance of natd or the complexity of writing a working > configuration with belt and suspenders for *BSD, yes there are other options ... just fyi, ipfw is the only available in-kernel option on OSX (I'm also implementing there as well). rumor has it that Apple is considering a move to ipfw2, but for now that's all there is. but i'm happy to learn/work through getting it done w/ natd, etc. per your suggestion. hence, my _still_open_ questions to this list ... richard From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 22:42:24 2004 Return-Path: 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 A8AF216A4CE for ; Wed, 2 Jun 2004 22:42:24 -0700 (PDT) Received: from osku.suutari.iki.fi (osku.syncrontech.com [213.28.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD15F43D54 for ; Wed, 2 Jun 2004 22:42:22 -0700 (PDT) (envelope-from ari@suutari.iki.fi) Received: from coffee (coffee.syncrontech.com [62.71.8.37]) by osku.suutari.iki.fi (8.12.8p1/8.12.8) with SMTP id i535gHN9084331; Thu, 3 Jun 2004 08:42:19 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <030301c4492d$89962150$2508473e@sad.syncrontech.com> From: "Ari Suutari" To: "OpenMacNews" , "freebsd-ipfw" References: Date: Thu, 3 Jun 2004 08:42:17 +0300 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 05:42:24 -0000 Hi, > If using NATd, am I relegated to a _static_ ruleset, w/ no ability to use stateful rules? I'm running at least two machines with both natd and some stateful rules (for udp traffic) Works ok. The way I did is to have two rules, for example: check-state allow udp from internal_network/24 to any 53 keep-state allow udp from public-ip-address to any 53 keep-state I *don't* have a rule for my internal interface which passes all traffic (ie. 'pass ip from any to any via internal-interface-name' which seems to be common setup, I use the 'via' keyword of ipfw only on anti-spoofing rules at beginning of my ruleset, all other rules are then based on ip-addresses only). The setup above creates two dynamic rules when packets are going thru. One maches the packet before nat and one after. Ari S. From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 22:51:48 2004 Return-Path: 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 68CEB16A4CE for ; Wed, 2 Jun 2004 22:51:48 -0700 (PDT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4201F43D58 for ; Wed, 2 Jun 2004 22:51:48 -0700 (PDT) (envelope-from freebsd-ipfw.20.openmacews@spamgourmet.com) Received: (qmail 15283 invoked from network); 3 Jun 2004 05:51:47 -0000 Received: from ns1.presence-group.net (HELO [172.30.11.6]) (blakers@[216.27.177.134]) )encrypted SMTP for ; 3 Jun 2004 05:51:47 -0000 Date: Wed, 02 Jun 2004 22:51:44 -0700 From: OpenMacNews To: freebsd-ipfw Message-ID: <889522B08C907A6E653E1D2B@[172.30.11.6]> In-Reply-To: <030301c4492d$89962150$2508473e@sad.syncrontech.com> References: <030301c4492d$89962150$2508473e@sad.syncrontech.com> X-Mailer: Mulberry/3.1.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: OpenMacNews List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 05:51:48 -0000 hi! >> If using NATd, am I relegated to a _static_ ruleset, w/ no ability to use > stateful rules? > > I'm running at least two machines with both natd and some stateful rules > (for udp traffic) > Works ok. > > The way I did is to have two rules, for example: > > check-state > allow udp from internal_network/24 to any 53 keep-state > allow udp from public-ip-address to any 53 keep-state ok. this is the "dual rules" approach that I'd read about. is it IPFW that's "managing" state, then, or NATd, or both? i.e., check-state checks WHICH tables? > I *don't* have a rule for my internal interface which passes all traffic > (ie. 'pass ip from any to any via internal-interface-name' > which seems to be common setup, I use the 'via' keyword of ipfw > only on anti-spoofing rules at beginning of my ruleset, all other > rules are then based on ip-addresses only). > > The setup above creates two dynamic rules when packets are > going thru. One maches the packet before nat and one after. in your example, how have you setup your NAT divert statement? are you using any "fwd" statements in conjunction? i'm asking in relation to my _other_post: thanks for your reply! richard From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 2 23:04:26 2004 Return-Path: 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 DD1BA16A4CE for ; Wed, 2 Jun 2004 23:04:26 -0700 (PDT) Received: from osku.suutari.iki.fi (osku.syncrontech.com [213.28.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B4AA43D5D for ; Wed, 2 Jun 2004 23:04:26 -0700 (PDT) (envelope-from ari@suutari.iki.fi) Received: from coffee (coffee.syncrontech.com [62.71.8.37]) by osku.suutari.iki.fi (8.12.8p1/8.12.8) with SMTP id i5364NN9084361; Thu, 3 Jun 2004 09:04:24 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <03ef01c44930$9f0ddc00$2508473e@sad.syncrontech.com> From: "Ari Suutari" To: "OpenMacNews" , "freebsd-ipfw" References: <030301c4492d$89962150$2508473e@sad.syncrontech.com> <889522B08C907A6E653E1D2B@[172.30.11.6]> Date: Thu, 3 Jun 2004 09:04:22 +0300 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 06:04:27 -0000 Hi, > > check-state > > allow udp from internal_network/24 to any 53 keep-state > > allow udp from public-ip-address to any 53 keep-state > > ok. this is the "dual rules" approach that I'd read about. > > is it IPFW that's "managing" state, then, or NATd, or both? i.e., check-state checks WHICH tables? Well, both. 'check-state' checks ipfw's tables. Natd does it's own checking. > > > I *don't* have a rule for my internal interface which passes all traffic > > (ie. 'pass ip from any to any via internal-interface-name' > > which seems to be common setup, I use the 'via' keyword of ipfw > > only on anti-spoofing rules at beginning of my ruleset, all other > > rules are then based on ip-addresses only). > > > > The setup above creates two dynamic rules when packets are > > going thru. One maches the packet before nat and one after. > > in your example, how have you setup your NAT divert statement? are you using any "fwd" statements in conjunction? i'm asking in relation to my _other_post: My divert statement is very much like in the standard /etc/rc.firewall. Ari S. From owner-freebsd-ipfw@FreeBSD.ORG Thu Jun 3 00:03:13 2004 Return-Path: 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 A7ABF16A4CE for ; Thu, 3 Jun 2004 00:03:13 -0700 (PDT) Received: from mailhost.wsf.at (server202.serveroffice.com [217.196.72.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0A1543D54 for ; Thu, 3 Jun 2004 00:03:11 -0700 (PDT) (envelope-from tw@wsf.at) Received: from mailhost.wsf.at (root@localhost)i53705BY055278 for ; Thu, 3 Jun 2004 09:00:05 +0200 (CEST) (envelope-from tw@wsf.at) Received: from mailhost.wsf.at (http.wsf.at [217.196.72.203]) i53704dn055265; Thu, 3 Jun 2004 09:00:04 +0200 (CEST) (envelope-from tw@wsf.at) Date: Thu, 3 Jun 2004 07:00:04 -0000 To: Barbish3@adelphia.net, freebsd-ipfw@freebsd.org From: Thomas Wolf X-Mailer: twiggi 1.10.3 Message-ID: <20040603090004.fsp0rm3wehw0k8@.mailhost.wsf.at> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tw@wsf.at List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 07:03:13 -0000 JJB schrieb: > Where do you get off calling my questioning of Luigi Rizzo's answer > as an attack. > I have heard that party line statement all to often over that last 4 > years, with no backup proof. That party line canned answer may be > sufficient for the original thread poster who has not invested the > time yet to come to the realization that it doe's not work. > My post to the tread was meant to bring this problem out so the > experts can look into it and take corrective actions. This should work although some features are missing (loopback, anti-spoofing, identd..): #!/bin/sh log="log" cmd="ipfw add" allow="skipto 10000" oif=rl0 good_tcp="22,25,53,80,443,110" good_udp="53" good_icmp="icmptypes 0,3,8,11,12" ipfw -f flush $cmd 100 divert natd ip from any to any in via $oif $cmd 105 check-state $cmd 110 $allow icmp from any to any $good_icmp $cmd 120 $allow udp from any to any $good_udp out keep-state $cmd 130 $allow tcp from any to any $good_tcp out setup keep-state $cmd 140 deny $log ip from any to any $cmd 10000 divert natd ip from any to any out via $oif $cmd 10010 allow ip from any to any $cmd 10020 deny ip from any to any Thomas -- Thomas Wolf Wiener Software Fabrik Dubas u. Wolf GMBH 1050 Wien, Mittersteig 4 From owner-freebsd-ipfw@FreeBSD.ORG Fri Jun 4 05:21:56 2004 Return-Path: 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 7E6A316A4CE for ; Fri, 4 Jun 2004 05:21:56 -0700 (PDT) Received: from mail019.syd.optusnet.com.au (mail019.syd.optusnet.com.au [211.29.132.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FDC743D1D for ; Fri, 4 Jun 2004 05:21:55 -0700 (PDT) (envelope-from tfrank@optushome.com.au) Received: from marvin.home.local (c211-28-252-96.eburwd5.vic.optusnet.com.au [211.28.252.96])i54CLEc30642; Fri, 4 Jun 2004 22:21:14 +1000 Received: by marvin.home.local (Postfix, from userid 1001) id D5DFA1FBC6; Fri, 4 Jun 2004 22:21:13 +1000 (EST) Date: Fri, 4 Jun 2004 22:21:13 +1000 From: Tony Frank To: OpenMacNews Message-ID: <20040604122113.GA51783@marvin.home.local> References: <183AEFC8C407F14A0032B498@[172.30.11.6]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <183AEFC8C407F14A0032B498@[172.30.11.6]> User-Agent: Mutt/1.4.2.1i cc: freebsd-ipfw Subject: Re: any ipfw + nat gurus out there? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2004 12:21:56 -0000 Hi there, On Wed, Jun 02, 2004 at 04:52:09PM -0700, OpenMacNews wrote: > i've gotten no "bites" so far on my 1st "i'm SO confused!" email, so I'll > try a narrower example/question ... Up to now, I've been avoiding this due to my own time constraints. > in the simple case of Perhaps you are yet to realise this is perhaps not 'simple' ? :) > > [public internet] > | > | > [ISP's gateway router] > external IP = R.R.R.R > | > | > ====FIREWALL============================ > NIC card 1 ("exif"), multihomed > external IP = A.A.A.1 > external IP = A.A.A.2 > | > | > ipfw > natd1 on external IP A.A.A.1 > natd2 on external IP A.A.A.2 > | > | > NIC card 3, internal IP = 10.0.0.B > =========================================== > | > | > | > | > | > =====WORKSTATION=========================== > NIC card 1, internal IP = 10.0.0.C > =========================================== > > using SSH as a service example, i'd like to: > > > allow a public internet address, IP = C.C.C.1, to ssh to WORKSTATION > *only* via EXTERNAL ip = A.A.A.1 > allow a public internet address, IP = C.C.C.2, to ssh to WORKSTATION > *only* via EXTERNAL ip = A.A.A.2 > allow ssh from WORKSTATION to ANY internal/external IP > primarily via A.A.A.1, except ssh traffic TO C.C.C.2 should > be OUT via A.A.A.2 > deny all other ssh traffic > Ok, as a first cut on this without actually trying anything and reading your work so far, I would do the following: 1. Get the workstation to anywhere case working using the aaa1 address. Standard rc.firewall examples should get you going with regular natd. 2. Get the ccc1 to workstation working through aaa1. NATD port forward is obvious solution to me here. To restrict this port-forward to the flow ccc1 to aaa1:22 use an ipfw rule prior to the natd divert. 3. Get the ccc2 to workstation working through aaa2. Again, NATD port-forward should do the trick. Another ipfw rule to only permit ccc2 to aaa2:22 before natd should do it. 4. Get the workstation to ccc2 outbound using aaa2 going. I'm not totally sure what you want here? Do you just want workstation to support incoming from ccc2 via aaa2 or do you want workstation to be able to initiate outbound to ccc2 using aaa2 address? If the latter then you may need some special case divert rule specific for this flow. Does that help? If you're still stuck, I can setup the scenario in my lab over the weekend. If I dont get stuck on paid work anyways. :) Regards, Tony From owner-freebsd-ipfw@FreeBSD.ORG Fri Jun 4 05:35:33 2004 Return-Path: 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 083C516A4CE for ; Fri, 4 Jun 2004 05:35:33 -0700 (PDT) Received: from mail014.syd.optusnet.com.au (mail014.syd.optusnet.com.au [211.29.132.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 687C943D3F for ; Fri, 4 Jun 2004 05:35:31 -0700 (PDT) (envelope-from tfrank@optushome.com.au) Received: from marvin.home.local (c211-28-252-96.eburwd5.vic.optusnet.com.au [211.28.252.96])i54CZJ704034; Fri, 4 Jun 2004 22:35:19 +1000 Received: by marvin.home.local (Postfix, from userid 1001) id 6C0CD1FBC6; Fri, 4 Jun 2004 22:35:18 +1000 (EST) Date: Fri, 4 Jun 2004 22:35:18 +1000 From: Tony Frank To: JJB Message-ID: <20040604123518.GB51783@marvin.home.local> References: <20040602154140.A17902@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: Luigi Rizzo cc: freebsd-ipfw cc: OpenMacNews Subject: Re: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2004 12:35:33 -0000 Hi there, On Wed, Jun 02, 2004 at 08:39:16PM -0400, JJB wrote: > Luigi, Your statement is very generic and so easy to make, when > there is no proof given to back it up. There is no documentation > that backs up your statement that says that stateful rules will work > in an nated environment. I think the standard rc.firewall sample scripts show this behaviour as working. > Better yet, here is an stateful rule set > that works with no lan behind the firewall machine. I would like to > see just how you would change it to get it to work in an nated > environment. I think once you start trying to get it to work you > will come to realize the problem ipfw has using stateful rules in an > nated environment first hand. If you have no lan behind the firewall, why do you want to run NAT? Perhaps I have misunderstood your statement? > The problem is the content of the > dynamic table is always different no matter where you position the > divert rule in the rule set which causes the dynamic table content > to never match. Yes, this is an issue, hence correct building/ordering of ipfw rules is critical. [...full firewall ruleset removed ...] I think in your example I would add: $cmd 000014 divert natd all from any to any via $outside_if This would be placed before the ipfw check-state rule. Also your inbound rules probably need some 'keep-state' entries to work? Regards, Tony From owner-freebsd-ipfw@FreeBSD.ORG Fri Jun 4 09:53:32 2004 Return-Path: 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 1B04416A4CE for ; Fri, 4 Jun 2004 09:53:32 -0700 (PDT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id E538343D45 for ; Fri, 4 Jun 2004 09:53:31 -0700 (PDT) (envelope-from freebsd-ipfw.20.openmacews@spamgourmet.com) Received: (qmail 31235 invoked from network); 4 Jun 2004 16:53:30 -0000 Received: from ns1.presence-group.net (HELO [172.30.11.6]) (blakers@[216.27.177.134]) )encrypted SMTP for ; 4 Jun 2004 16:53:29 -0000 Date: Fri, 04 Jun 2004 09:53:27 -0700 From: OpenMacNews To: freebsd-ipfw Message-ID: <39F4B5716A612AA12BB2BCEA@[172.30.11.6]> In-Reply-To: <20040604122113.GA51783@marvin.home.local> References: <183AEFC8C407F14A0032B498@[172.30.11.6]> <20040604122113.GA51783@marvin.home.local> X-Mailer: Mulberry/3.1.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: Tony Frank Subject: Re: any ipfw + nat gurus out there? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: OpenMacNews List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2004 16:53:32 -0000 -- On Friday, June 4, 2004 10:21 PM +1000 Tony Frank wrote: Tony, > Up to now, I've been avoiding this due to my own time constraints. Thanks for your reply and your time! >> in the simple case of > > Perhaps you are yet to realise this is perhaps not 'simple' ? :) Nope. No more 'yet'. Got it. Not necessarily simple. People getting angry. Loud-n-clear. In over my head. Stateful? ... no flippin idea! ;-) Still, it *should* be ... > Ok, as a first cut on this without actually trying anything and reading your > work so far, I would do the following: great. i'll regurgitate/postulate in order ... first, the basics initialize the variables: fwcmd = "/sbin/ipfw" exipA = "A.A.A.1" exipB = "A.A.A.2" inip = "10.0.0.B" gateway = "R.R.R.R" natd_portA_in= "8668" natd_portA_out= "8669" natd_portB_in= "8670" natd_portB_out= "8671" the 'usual' start & finish rules ... # allow localhost traffic ${fwcmd} add 100 allow all from 127.0.0.1 to 127.0.0.1 # deny everything else ${fwcmd} add 65000 pass deny from any to any > 1. Get the workstation to anywhere case working using the aaa1 address. > Standard rc.firewall examples should get you going with regular natd. ok, but since my not-so-simple example has TWO external IPs (exipA=A.A.A.1 & exipB=A.A.A.2) that will BOTH be sending & receiving IP traffic, I'll set up TWO natd instances, one running on EACH external IP. BUT, > 2. Get the ccc1 to workstation working through aaa1. > 3. Get the ccc2 to workstation working through aaa2. > NATD port forward is obvious solution to me here. > To restrict this port-forward to the flow ccc1 to aaa1:22 use an ipfw rule prior to the natd divert. > > Again, NATD port-forward should do the trick. > Another ipfw rule to only permit ccc2 to aaa2:22 before natd should do it. this has me confused ... should this not be done with the -redirect_port tcp ${WORKSTATION}:22 22 natd config option? my understanding of this is "any/all traffic to this NATd instance's alias_address, port 22 is forwarded to WORKSTATION:22". i.e., /usr/sbin/natd \ -alias_address ${exipA} \ -in_port ${natd_portA_in} \ -out_port ${natd_portA_out} \ -dynamic -use_sockets -same_ports -unregistered_only -log -log_denied \ -redirect_port tcp ${WORKSTATION}:22 22 /usr/sbin/natd \ -alias_address ${exipB} \ -in_port ${natd_portB_in} \ -out_port ${natd_portB_out} \ -dynamic -use_sockets -same_ports -unregistered_only -log -log_denied \ -redirect_port tcp ${WORKSTATION}:22 22 am i misusing this? specifically, i'm not sure what your reasoning/intent is with the "use an ipfw rule PRIOR to the natd divert" instruction. # rather than the rc.firewall 'standard' ${fwcmd} add 2000 divert all from any to any via ed0 where ed0 is your EXTERNAL interface. the DIVERT statements I've used are: (a) ${fwcmd} add 10000 divert ${natd_portB_out} ip from ${inip} to C.C.C.2 22 out xmit ${exif} (b) ${fwcmd} add 11000 divert ${natd_portA_out} ip from ${inip} to any out xmit ${exif} (c) ${fwcmd} add 12000 divert ${natd_portA_in} ip from any to any in via ${exif} (d) ${fwcmd} add 13000 divert ${natd_portB_ip} ip from any to any in via ${exif} where the intent of each is: (a) all OUTBOUND traffic via the firewall's internal-LAN-ip (inip) & the External NIC (exif) specifically to C.C.C.2:22 **MUST** travel OUT via exipB=A.A.A.2, i.e., the SECOND NATD instance, above (b) all **OTHER** OUTBOUND traffic via inip **MUST** travel OUT via exipA=A.A.A.1, i.e., the FIRST NATD instance (c) all INBOUND traffic coming into the (exif) & addressed to exipA=A.A.A.1 gets diverted to the 1st NATd instance (d) all INBOUND traffic coming into the (exif) & addressed to exipB=A.A.A.2 gets diverted to the 2st NATd instance > 4. Get the workstation to ccc2 outbound using aaa2 going. > I'm not totally sure what you want here? > Do you just want workstation to support incoming from ccc2 via aaa2 or > do you want workstation to be able to initiate outbound to ccc2 using aaa2 address? > If the latter then you may need some special case divert rule specific for this flow. yes to both. DIVERT rule (a), above, is *intended* to do this. > Does that help? getting there. thanks! i'm still a bit unclear about the above ... i'm still a LOT unclear about the additional issue "that, after natd, the ip packet's src will be rewritten to IP of exipX, so I may need to send via fwd the packet to next-hop -- i.e., the ISP's gateway router, using ${fwcmd} add 10005 fwd ${gateway} ip from ${exipA} to any ${fwcmd} add 11005 fwd ${gateway} ip from ${exipB} to any" I **think** this has to do with state management, but not certain ... too many variable for my poor, feeble mind at the moment. > If you're still stuck, I can setup the scenario in my lab over the weekend. > If I dont get stuck on paid work anyways. :) once I get this all worked out -- with lots of help, clearly! -- my intent is to write it up and post as an example ... again, i've learned this is NOT as simple as it looks ... well, as I'd hoped anyway! and i will most certainly NOT "look a gift horse in the mouth", with all due respect ;-) thanks, richard From owner-freebsd-ipfw@FreeBSD.ORG Sat Jun 5 09:59:16 2004 Return-Path: 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 EE11016A4CE for ; Sat, 5 Jun 2004 09:59:16 -0700 (PDT) Received: from mail015.syd.optusnet.com.au (mail015.syd.optusnet.com.au [211.29.132.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id D107C43D3F for ; Sat, 5 Jun 2004 09:59:15 -0700 (PDT) (envelope-from tfrank@optushome.com.au) Received: from marvin.home.local (c211-28-252-96.eburwd5.vic.optusnet.com.au [211.28.252.96])i55GxAN26107; Sun, 6 Jun 2004 02:59:10 +1000 Received: by marvin.home.local (Postfix, from userid 1001) id 2501E1FBC4; Sun, 6 Jun 2004 02:59:09 +1000 (EST) Date: Sun, 6 Jun 2004 02:59:09 +1000 From: Tony Frank To: OpenMacNews Message-ID: <20040605165909.GA62366@marvin.home.local> References: <183AEFC8C407F14A0032B498@[172.30.11.6]> <20040604122113.GA51783@marvin.home.local> <39F4B5716A612AA12BB2BCEA@[172.30.11.6]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39F4B5716A612AA12BB2BCEA@[172.30.11.6]> User-Agent: Mutt/1.4.2.1i cc: freebsd-ipfw Subject: Re: any ipfw + nat gurus out there? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 16:59:17 -0000 Hi richard, On Fri, Jun 04, 2004 at 09:53:27AM -0700, OpenMacNews wrote: > >>in the simple case of > >Perhaps you are yet to realise this is perhaps not 'simple' ? :) > Nope. No more 'yet'. Got it. Not necessarily simple. People getting angry. > Loud-n-clear. In over my head. Stateful? ... no flippin idea! ;-) > Still, it *should* be ... Well, I will agree that you are making things overly complex. :) > great. i'll regurgitate/postulate in order ... > first, the basics > > initialize the variables: > > fwcmd = "/sbin/ipfw" > exipA = "A.A.A.1" > exipB = "A.A.A.2" Assumptions: 1. These addresses are static allocations to you from your ISP. 2. A.A.A.1 is primary address on your interface, A.A.A.2 is an alias. 3. ISP will route traffic for both A.A.A.1 and A.A.A.2 to you, and you will receive the traffic for both IP on your external interface. 4. You are using 4-STABLE or similar 4.x release (4.9 / 4.10) The answers likely will work equally well on a 5.x release but I have not tested/tried it. 5. External interface is fxp0, internal interface is fxp1 6. Everything is ethernet based and no extra ppp/gif/whatever is in use. After configuring, your firewall interfaces will look something like this in ifconfig(8) output: fxp0: flags=18843 mtu 1500 inet A.A.A.1 netmask 0xffffff00 broadcast A.A.A.255 inet A.A.A.2 netmask 0xffffffff broadcast A.A.A.2 ether aa:bb:cc:dd:ee:ff media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=18843 mtu 1500 inet 10.0.0.B netmask 0xffffff00 broadcast 10.0.0.255 ether aa:bb:cc:dd:ee:ff media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 > inip = "10.0.0.B" > gateway = "R.R.R.R" > > natd_portA_in= "8668" > natd_portA_out= "8669" > natd_portB_in= "8670" > natd_portB_out= "8671" I believe you have three too many natd ports there. See below. > > the 'usual' start & finish rules ... > > # allow localhost traffic > ${fwcmd} add 100 allow all from 127.0.0.1 to 127.0.0.1 > # deny everything else > ${fwcmd} add 65000 pass deny from any to any I'm not sure where you get those as 'usual' ? In my experience usual loopback rules (from /etc/rc.firewall) are: 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any Also your final rule will not work with both pass + deny, I assume this is just a typo. I will make another assumption here that you mean allow all default rule. 65000 allow ip from any to any > >1. Get the workstation to anywhere case working using the aaa1 address. > >Standard rc.firewall examples should get you going with regular natd. > > ok, but since my not-so-simple example has TWO external IPs (exipA=A.A.A.1 > & exipB=A.A.A.2) that will BOTH be sending & receiving IP traffic, I'll set > up TWO natd instances, one running on EACH external IP. I am sorry, but you are jumping ahead too far too quickly. I strongly recommend learning to crawl before trying to run. Step 1 is to get basic functionality working in a 'standard' setup with just a single IP address in use. Walk before running, crawl before walking... etc. I will now proceed through each of the steps with a more detailed config that should be sufficient to achieve each part. If you cannot match my results for each step, fix the problem before attempting to proceed. To achieve step 1 a very simple config should suffice. IPFW rules will be: 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01000 divert 8668 ip from any to any via fxp0 65000 allow ip from any to any natd can be started: /sbin/natd -n fxp0 or the /etc/rc.conf lines on your 'firewall' would be: ifconfig_fxp0="inet a.a.a.1 netmask 255.255.255.0" ifconfig_fxp0_alias0="inet a.a.a.2 netmask 255.255.255.255" ifconfig_fxp1="inet 10.0.0.B netmask 255.255.255.0" defaultrouter="R.R.R.R" gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="fxp0" etc /etc/rc.conf on 'workstation' would be: ifconfig_fxp0="inet 10.0.0.C netmask 255.255.255.0" defaultrouter="10.0.0.B" gateway_enable="NO" firewall_enable="YES" firewall_type="CLIENT" natd_enable="NO" sshd_enable="YES" etc Result should be that anything you route to the internet from internal network will be modified by natd in transit to appear to originate from A.A.A.1. Return traffic that matches natd tables will have their destination updated to match the original source. You can test this with a ping (or ssh) from workstation to c.c.c.1 etc. If you run natd with the verbose (-v) flag, you should get output to prove this, like so: Out [ICMP] [ICMP] 10.0.0.C -> C.C.C.1 8(0) aliased to [ICMP] a.a.a.1 -> C.C.C.1 8(0) In [ICMP] [ICMP] C.C.C.1 -> a.a.a.1 0(0) aliased to [ICMP] C.C.C.1 -> 10.0.0.C 0(0) etc > >2. Get the ccc1 to workstation working through aaa1. > >3. Get the ccc2 to workstation working through aaa2. > > >NATD port forward is obvious solution to me here. > >To restrict this port-forward to the flow ccc1 to aaa1:22 use an ipfw rule > >prior to the natd divert. > > > >Again, NATD port-forward should do the trick. > >Another ipfw rule to only permit ccc2 to aaa2:22 before natd should do it. > > this has me confused ... should this not be done with the > > -redirect_port tcp ${WORKSTATION}:22 22 > > natd config option? my understanding of this is "any/all traffic to this > NATd instance's alias_address, port 22 is forwarded to WORKSTATION:22". Yes, this is correct. To move from step 1 to step 2 all that should be needed is an expansion of the natd parameters, ie the -redirect_port parameter. /sbin/natd -n fxp0 -redirect_port tcp workstation:22 A.A.A.1:22 Now any tcp connection to port 22 on A.A.A.1 will be redirected by natd to workstation. This redirection will be done for any remote IP address at the moment. Verify this by attempting to connect from c.c.c.1 to a.a.a.1:22. It should work. If you run natd with verbose flag (-v) you should see something like: In [TCP] [TCP] C.C.C.1:1234 -> a.a.a.1:22 aliased to [TCP] C.C.C.1:1234 -> 10.0.0.C:22 Out [TCP] [TCP] 10.0.0.C:22 -> C.C.C.1:1234 aliased to [TCP] a.a.a.1:22 -> C.C.C.1:1234 etc Moving from step 2 to step 3, we add another redirect_port parameter to natd config. ie: /sbin/natd -n fxp0 -redirect_port tcp workstation:22 A.A.A.1:22 -redirect_port tcp workstation:22 A.A.A.2:22 Now any tcp connection to port 22 on A.A.A.1 or A.A.A.2 will be redirected by natd to workstation. Return traffic will be modified as appropriate, ie either a.a.a.1 or a.a.a.2 will be used depending on where the traffic was originally destined. Outgoing connections initiated from workstation still all use a.a.a.1 as the public address. > i.e., > > /usr/sbin/natd \ > -alias_address ${exipA} \ > -in_port ${natd_portA_in} \ > -out_port ${natd_portA_out} \ > -dynamic -use_sockets -same_ports -unregistered_only -log > -log_denied \ > -redirect_port tcp ${WORKSTATION}:22 22 > > /usr/sbin/natd \ > -alias_address ${exipB} \ > -in_port ${natd_portB_in} \ > -out_port ${natd_portB_out} \ > -dynamic -use_sockets -same_ports -unregistered_only -log > -log_denied \ > -redirect_port tcp ${WORKSTATION}:22 22 > > am i misusing this? specifically, i'm not sure what your reasoning/intent > is with the "use an ipfw rule PRIOR to the natd divert" instruction. Misusing this - yes, I think so. You dont need two natd, and personally I've never need to use the in_port / out_port options. [... snip ...] > where the intent of each is: > > (a) all OUTBOUND traffic via the firewall's internal-LAN-ip (inip) & > the External NIC (exif) specifically to C.C.C.2:22 **MUST** travel > OUT via exipB=A.A.A.2, i.e., the SECOND NATD instance, above > (b) all **OTHER** OUTBOUND traffic via inip **MUST** travel OUT via > exipA=A.A.A.1, i.e., the FIRST NATD instance > (c) all INBOUND traffic coming into the (exif) & addressed to > exipA=A.A.A.1 gets diverted to the 1st NATd instance > (d) all INBOUND traffic coming into the (exif) & addressed to > exipB=A.A.A.2 gets diverted to the 2st NATd instance Ok, with the setup I have described so far, step 1 achieves point b. step 2 gets you item c, and step 3 gets you item d. Obviously not exactly (ie my description does not use multiple natd etc) but I think the final intent is acheived if I understand your goals correctly. All that is left then is to ensure that any outgoing traffic initiated by your internal network is translated to a.a.a.2 rather than a.a.a.1. This is where things become a little more complex, hence my original question. With the setup described above in step 3, any tcp connection originating from c.c.c.2 destined to a.a.a.2:22 will be redirected to workstation:22. Any return traffic as a result of this connection will automatically be corrected in the outbound direction to use a.a.a.2 IP address. You can add security with extra ipfw rules to ensure only specific traffic flows are permitted and the rest are denied, eg only allow ccc1 to aaa1 and ccc2 to aaa2 etc. If I understand correctly, in addition to the above, you want to ensure that any outgoing connection initiated from workstation to c.c.c.2:22 uses a.a.a.2. This is where things are tricky/complex and may well require multiple natd instances. I would first question whether this cannot be achieved with a simpler approach? Eg you could perhaps use the natd option redirect_address and define two internal ip for workstation - one for use with ccc1 and the other for use with ccc2. A single natd process should then suffice and translate all traffic as needed. I started experimenting with a multiple natd setup and it quickly becomes very complex. If you add ipfw state-checking on top you then have ipfw keeping state plus natd keeping state. I might keep going tomorrow on this one if I get bored; but if a working configuration makes it out alive, it will not be pretty and I suspect it will be a nightmare to maintain. Hope the above helps, Tony From owner-freebsd-ipfw@FreeBSD.ORG Sat Jun 5 11:10:27 2004 Return-Path: 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 ED5AB16A4CE for ; Sat, 5 Jun 2004 11:10:27 -0700 (PDT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF41643D55 for ; Sat, 5 Jun 2004 11:10:27 -0700 (PDT) (envelope-from freebsd-ipfw.20.openmacews@spamgourmet.com) Received: (qmail 26101 invoked from network); 5 Jun 2004 18:10:27 -0000 Received: from ns1.presence-group.net (HELO [172.30.11.6]) (blakers@[216.27.177.134]) )encrypted SMTP for ; 5 Jun 2004 18:10:26 -0000 Date: Sat, 05 Jun 2004 11:10:23 -0700 From: OpenMacNews To: freebsd-ipfw Message-ID: <6D9F09210EC5D7E9112EF5DD@[172.30.11.6]> In-Reply-To: <20040605165909.GA62366@marvin.home.local> References: <183AEFC8C407F14A0032B498@[172.30.11.6]> <20040604122113.GA51783@marvin.home.local> <39F4B5716A612AA12BB2BCEA@[172.30.11.6]> <20040605165909.GA62366@marvin.home.local> X-Mailer: Mulberry/3.1.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: Tony Frank Subject: Re: any ipfw + nat gurus out there? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: OpenMacNews List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 18:10:28 -0000 Tony, Thanks for this! Short story: I've single instance NATd already humming along ... and am reinvestigating the need/benefit/how of multiple nat instances given some of your comments. i still think i need it to do what i want ... just fyi, while i ponder your comments further, take a look at: and, as examples of the mulit-nat discussion i'm slogging through ... cheers for a bit, richard -- On Sunday, June 6, 2004 2:59 AM +1000 Tony Frank wrote: > Hi richard, > > On Fri, Jun 04, 2004 at 09:53:27AM -0700, OpenMacNews wrote: >> >> in the simple case of >> > Perhaps you are yet to realise this is perhaps not 'simple' ? :) >> Nope. No more 'yet'. Got it. Not necessarily simple. People getting angry. >> Loud-n-clear. In over my head. Stateful? ... no flippin idea! ;-) >> Still, it *should* be ... > > Well, I will agree that you are making things overly complex. :) > >> great. i'll regurgitate/postulate in order ... >> first, the basics >> >> initialize the variables: >> >> fwcmd = "/sbin/ipfw" >> exipA = "A.A.A.1" >> exipB = "A.A.A.2" > > Assumptions: > 1. These addresses are static allocations to you from your ISP. > 2. A.A.A.1 is primary address on your interface, A.A.A.2 is an alias. > 3. ISP will route traffic for both A.A.A.1 and A.A.A.2 to you, and you > will receive the traffic for both IP on your external interface. > 4. You are using 4-STABLE or similar 4.x release (4.9 / 4.10) > The answers likely will work equally well on a 5.x release but I have > not tested/tried it. > 5. External interface is fxp0, internal interface is fxp1 > 6. Everything is ethernet based and no extra ppp/gif/whatever is in use. > > After configuring, your firewall interfaces will look something like this > in ifconfig(8) output: > > fxp0: flags=18843 mtu 1500 > inet A.A.A.1 netmask 0xffffff00 broadcast A.A.A.255 > inet A.A.A.2 netmask 0xffffffff broadcast A.A.A.2 > ether aa:bb:cc:dd:ee:ff > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=18843 mtu 1500 > inet 10.0.0.B netmask 0xffffff00 broadcast 10.0.0.255 > ether aa:bb:cc:dd:ee:ff > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > > >> inip = "10.0.0.B" >> gateway = "R.R.R.R" >> >> natd_portA_in= "8668" >> natd_portA_out= "8669" >> natd_portB_in= "8670" >> natd_portB_out= "8671" > > I believe you have three too many natd ports there. > > See below. > >> >> the 'usual' start & finish rules ... >> >> # allow localhost traffic >> ${fwcmd} add 100 allow all from 127.0.0.1 to 127.0.0.1 >> # deny everything else >> ${fwcmd} add 65000 pass deny from any to any > > I'm not sure where you get those as 'usual' ? > In my experience usual loopback rules (from /etc/rc.firewall) are: > > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > > Also your final rule will not work with both pass + deny, I assume > this is just a typo. > I will make another assumption here that you mean allow all default rule. > > 65000 allow ip from any to any > >> > 1. Get the workstation to anywhere case working using the aaa1 address. >> > Standard rc.firewall examples should get you going with regular natd. >> >> ok, but since my not-so-simple example has TWO external IPs (exipA=A.A.A.1 >> & exipB=A.A.A.2) that will BOTH be sending & receiving IP traffic, I'll set >> up TWO natd instances, one running on EACH external IP. > > I am sorry, but you are jumping ahead too far too quickly. > > I strongly recommend learning to crawl before trying to run. > > Step 1 is to get basic functionality working in a 'standard' setup with > just a single IP address in use. > Walk before running, crawl before walking... etc. > I will now proceed through each of the steps with a more detailed config > that should be sufficient to achieve each part. > If you cannot match my results for each step, fix the problem before > attempting to proceed. > > To achieve step 1 a very simple config should suffice. > > IPFW rules will be: > > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 01000 divert 8668 ip from any to any via fxp0 > 65000 allow ip from any to any > > natd can be started: > /sbin/natd -n fxp0 > > or the /etc/rc.conf lines on your 'firewall' would be: > ifconfig_fxp0="inet a.a.a.1 netmask 255.255.255.0" > ifconfig_fxp0_alias0="inet a.a.a.2 netmask 255.255.255.255" > ifconfig_fxp1="inet 10.0.0.B netmask 255.255.255.0" > defaultrouter="R.R.R.R" > gateway_enable="YES" > firewall_enable="YES" > firewall_type="OPEN" > natd_enable="YES" > natd_interface="fxp0" > etc > > /etc/rc.conf on 'workstation' would be: > ifconfig_fxp0="inet 10.0.0.C netmask 255.255.255.0" > defaultrouter="10.0.0.B" > gateway_enable="NO" > firewall_enable="YES" > firewall_type="CLIENT" > natd_enable="NO" > sshd_enable="YES" > etc > > Result should be that anything you route to the internet from internal > network will be modified by natd in transit to appear to originate from > A.A.A.1. > Return traffic that matches natd tables will have their destination updated > to match the original source. > > You can test this with a ping (or ssh) from workstation to c.c.c.1 etc. > > If you run natd with the verbose (-v) flag, you should get output to prove > this, like so: > > Out [ICMP] [ICMP] 10.0.0.C -> C.C.C.1 8(0) aliased to > [ICMP] a.a.a.1 -> C.C.C.1 8(0) > In [ICMP] [ICMP] C.C.C.1 -> a.a.a.1 0(0) aliased to > [ICMP] C.C.C.1 -> 10.0.0.C 0(0) > etc > >> > 2. Get the ccc1 to workstation working through aaa1. >> > 3. Get the ccc2 to workstation working through aaa2. >> >> > NATD port forward is obvious solution to me here. >> > To restrict this port-forward to the flow ccc1 to aaa1:22 use an ipfw rule >> > prior to the natd divert. >> > >> > Again, NATD port-forward should do the trick. >> > Another ipfw rule to only permit ccc2 to aaa2:22 before natd should do it. >> >> this has me confused ... should this not be done with the >> >> -redirect_port tcp ${WORKSTATION}:22 22 >> >> natd config option? my understanding of this is "any/all traffic to this >> NATd instance's alias_address, port 22 is forwarded to WORKSTATION:22". > > Yes, this is correct. > To move from step 1 to step 2 all that should be needed is an expansion of > the natd parameters, ie the -redirect_port parameter. > > /sbin/natd -n fxp0 -redirect_port tcp workstation:22 A.A.A.1:22 > > Now any tcp connection to port 22 on A.A.A.1 will be redirected by natd to > workstation. > This redirection will be done for any remote IP address at the moment. > Verify this by attempting to connect from c.c.c.1 to a.a.a.1:22. > It should work. > If you run natd with verbose flag (-v) you should see something like: > > In [TCP] [TCP] C.C.C.1:1234 -> a.a.a.1:22 aliased to > [TCP] C.C.C.1:1234 -> 10.0.0.C:22 > Out [TCP] [TCP] 10.0.0.C:22 -> C.C.C.1:1234 aliased to > [TCP] a.a.a.1:22 -> C.C.C.1:1234 > etc > > Moving from step 2 to step 3, we add another redirect_port parameter to > natd config. > ie: > > /sbin/natd -n fxp0 -redirect_port tcp workstation:22 A.A.A.1:22 -redirect_port tcp workstation:22 A.A.A.2:22 > > Now any tcp connection to port 22 on A.A.A.1 or A.A.A.2 will be redirected > by natd to workstation. > Return traffic will be modified as appropriate, ie either a.a.a.1 or a.a.a.2 > will be used depending on where the traffic was originally destined. > Outgoing connections initiated from workstation still all use a.a.a.1 as > the public address. > >> i.e., >> >> /usr/sbin/natd \ >> -alias_address ${exipA} \ >> -in_port ${natd_portA_in} \ >> -out_port ${natd_portA_out} \ >> -dynamic -use_sockets -same_ports -unregistered_only -log >> -log_denied \ >> -redirect_port tcp ${WORKSTATION}:22 22 >> >> /usr/sbin/natd \ >> -alias_address ${exipB} \ >> -in_port ${natd_portB_in} \ >> -out_port ${natd_portB_out} \ >> -dynamic -use_sockets -same_ports -unregistered_only -log >> -log_denied \ >> -redirect_port tcp ${WORKSTATION}:22 22 >> >> am i misusing this? specifically, i'm not sure what your reasoning/intent >> is with the "use an ipfw rule PRIOR to the natd divert" instruction. > > Misusing this - yes, I think so. You dont need two natd, and personally > I've never need to use the in_port / out_port options. > > [... snip ...] > >> where the intent of each is: >> >> (a) all OUTBOUND traffic via the firewall's internal-LAN-ip (inip) & >> the External NIC (exif) specifically to C.C.C.2:22 **MUST** travel >> OUT via exipB=A.A.A.2, i.e., the SECOND NATD instance, above >> (b) all **OTHER** OUTBOUND traffic via inip **MUST** travel OUT via >> exipA=A.A.A.1, i.e., the FIRST NATD instance >> (c) all INBOUND traffic coming into the (exif) & addressed to >> exipA=A.A.A.1 gets diverted to the 1st NATd instance >> (d) all INBOUND traffic coming into the (exif) & addressed to >> exipB=A.A.A.2 gets diverted to the 2st NATd instance > > Ok, with the setup I have described so far, step 1 achieves point b. > step 2 gets you item c, and step 3 gets you item d. > Obviously not exactly (ie my description does not use multiple natd etc) > but I think the final intent is acheived if I understand your goals > correctly. > > All that is left then is to ensure that any outgoing traffic initiated by > your internal network is translated to a.a.a.2 rather than a.a.a.1. > This is where things become a little more complex, hence my original question. > With the setup described above in step 3, any tcp connection originating from > c.c.c.2 destined to a.a.a.2:22 will be redirected to workstation:22. > Any return traffic as a result of this connection will automatically be > corrected in the outbound direction to use a.a.a.2 IP address. > > You can add security with extra ipfw rules to ensure only specific traffic > flows are permitted and the rest are denied, eg only allow ccc1 to aaa1 and > ccc2 to aaa2 etc. > > If I understand correctly, in addition to the above, you want to ensure that > any outgoing connection initiated from workstation to c.c.c.2:22 uses a.a.a.2. > > This is where things are tricky/complex and may well require multiple natd > instances. > > I would first question whether this cannot be achieved with a simpler approach? > Eg you could perhaps use the natd option redirect_address and define two > internal ip for workstation - one for use with ccc1 and the other for use with > ccc2. > A single natd process should then suffice and translate all traffic as needed. > > I started experimenting with a multiple natd setup and it quickly becomes very > complex. If you add ipfw state-checking on top you then have ipfw keeping state > plus natd keeping state. > I might keep going tomorrow on this one if I get bored; but if a working > configuration makes it out alive, it will not be pretty and I suspect it will > be a nightmare to maintain. > > Hope the above helps, > > Tony > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"