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"