Date: Sat, 05 Jun 2004 11:10:23 -0700 From: OpenMacNews <freebsd-ipfw.20.openmacews@spamgourmet.com> To: freebsd-ipfw <freebsd-ipfw@freebsd.org> Cc: Tony Frank <tfrank@optushome.com.au> Subject: Re: any ipfw + nat gurus out there? 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
<http://lists.netfilter.org/pipermail/netfilter/1999-October/002630.html>;
and,
<http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=Pine.BSF.4.10.9909131744020.88005-100000_resnet.uoregon.edu%40ns.sol.net&rnum=1&prev=/groups%3Fq%3D%2522Multiple%2520NAT%2520alias%2520addresses%2522%26hl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26sa%3DN%26tab%3Dwg>;
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 <tfrank@optushome.com.au> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex>)
> status: active
> fxp1: flags=18843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex>)
> status: active
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6D9F09210EC5D7E9112EF5DD>