Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Sep 2011 12:20:20 -0700
From:      Freddie Cash <fjwcash@gmail.com>
To:        Marek Salwerowicz <marek_sal@wp.pl>
Cc:        freebsd-net@freebsd.org
Subject:   Re: ipfw - accessing DMZ from LAN
Message-ID:  <CAOjFWZ6wf9NnVeffUV4uA6h1t-1T8juxXycZbM7%2BGgpFC-HkUg@mail.gmail.com>
In-Reply-To: <4E7B450F.5050802@wp.pl>
References:  <4E412116.1070305@wp.pl> <CAOjFWZ4B3uUfOLAzL=B1WY98rqi6X32j7FM61VjJ3td76NkADg@mail.gmail.com> <4E422A74.3090601@wp.pl> <CAOjFWZ5CK62nQMA8JsfW1b4BQh3hAJbAAynortzaUBqSWBwdSQ@mail.gmail.com> <4E7B450F.5050802@wp.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 22, 2011 at 7:24 AM, Marek Salwerowicz <marek_sal@wp.pl> wrote:

> W dniu 2011-08-10 16:22, Freddie Cash pisze:
>
>
>>        The more correct method is to double-NAT the traffic, such
>>        that the LAN
>>        clients connect to public IPs, and the DMZ servers see
>>        connections from
>>        public IPs.  It's more complicated to wrap your head around
>>        the first time,
>>        but it prevents private IPs from "leaking" between the LAN,
>>        the Internet,
>>        and the DMZ.  (It took me 10 years of using IPFW to figure
>>        this one out.)
>>
>>        # Configure the general natd process for the LAN
>>        natd -port $port2 -same_ports -use_sockets -alias_address
>>        x.x.x.171
>>
>>        # Configure the natd process to NAT from x.x.x.170 to
>>        192.168.0.10 using
>>        some port
>>        natd -port $port1 -same_ports -use_sockets -alias_address
>>        x.x.x.170
>>        -redirect_address x.x.x.170 192.168.0.10
>>
>>        # NAT the traffic coming from the LAN to x.x.x.170
>>        ipfw add divert $port1 ip from $LAN to x.x.x.170 in recv vr0
>>        ipfw add allow ip from $LAN to 192.168.0.10 in recv vr0
>>
>>        # NAT the traffic going to x.x.x.170 from the LAN
>>        ipfw add divert $port2 ip from $LAN to 192.168.0.10 out xmit vr2
>>        ipfw add allow ip from x.x.x.171 to 192.168.0.10 out xmit vr2
>>
>>        # NAT the traffic coming from x.x.x.170 to the LAN
>>        ipfw add divert $port1 ip from 192.168.0.10 to x.x.x.171 in
>>        recv vr2
>>        ipfw add allow ip from 192.168.0.10 to $LAN in recv vr2
>>
>>        # NAT the traffic going to the LAN from x.x.x.170
>>        ipfw add divert ip from 192.168.0.10 to $LAN out xmit vr0
>>        ipfw add allow ip from x.x.x.170 t0 $LAN out xmit vr0
>>
>>        The general flow of the rules above is (src -->  dest)
>>        10.0.0.x -->  x.x.x.170
>>        10.0.0.x -->  192.168.0.10  (after first NAT)
>>        x.x.x.171 -->  192.168.0.10 (after second NAT)
>>
>>        192.168.0.10 -->  x.x.x.171
>>        192.168.0.10 -->  10.0.0.x (after first NAT)
>>        x.x.x.170 -->  10.0.0.x  (after second NAT)
>>
>>        Notice how vr3 is never used in any of the rules above, as the
>>        packets never
>>        touch the public interface of the router.
>>
>>
>>
> Hi,
>
> I set up firewall like this:
>
> Your rules are too generic, they will not work for a double-NAT setup.

Each and every single rule must specify the network interface.  And it must
specify whether it's incoming (in recv) or outgoing (out xmit) traffic.
 Don't use "via" anywhere.

While it's easier to use generic rules to start with, you really need to get
very specific, at least for the double-NAT setup.

See my example above.

-- 
Freddie Cash
fjwcash@gmail.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOjFWZ6wf9NnVeffUV4uA6h1t-1T8juxXycZbM7%2BGgpFC-HkUg>