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