ipfw - accessing DMZ from LAN

Freddie Cash fjwcash at gmail.com
Tue Aug 9 16:29:18 UTC 2011


On Tue, Aug 9, 2011 at 4:59 AM, Marek Salwerowicz <marek_sal at wp.pl> wrote:

> I have set up a new router for my network, with separated DMZ zone for my
> internet servers. I'd like computers from my LAN to be able to connect to
> DMZ zone.
>
> My ISP provided me some public IP's, so right now configuration looks like
> this:
>
> Router with 4 NICs:
> #public ISP
> ifconfig_vr3="inet xx.yy.zz.171 netmask 255.255.255.248"
> ifconfig_vr3_alias0="inet xx.yy.zz.170 netmask 255.255.255.255"
> ifconfig_vr3_alias1="inet xx.yy.zz.172 netmask 255.255.255.255"
> ifconfig_vr3_alias2="inet xx.yy.zz.173 netmask 255.255.255.255"
>
> The first IP, with suffix .171 I want to be used as real router's IP, and
> public IP for computers in my LAN.
> All 3 aliases I want to be redirected to DMZ (one public IP for each server
> in DMZ)
>
> #DMZ
> ifconfig_vr2="inet 192.168.0.1 netmask 255.255.255.0"
>
> #LAN
> ifconfig_vr0="inet 10.0.0.1 netmask 255.255.255.0"
>
> I've set up in natd.conf:
>
> use_sockets yes
> same_ports yes
> interface vr3
> dynamic yes
> unregistered_only yes
> redirect_address 192.168.0.10 xx.yy.zz.170 #DMZ host 1
> redirect_address 192.168.0.20 xx.yy.zz.172 #DMZ host 2
> redirect_address 192.168.0.30 xx.yy.zz.173 #DMZ host 3
>
> Right now everything works from the Internet - if I do ssh to xx.yy.zz.170,
> I really can connect to host 192.168.0.10 etc.
>
> The problem is that when I want to connect from my 10.0.0.0/24 network
> (and even from router) to any DMZ host, using it's public address (any of
> xx.yy.zz.{170,172,173} ), I can't connect and in fact I am connecting to the
> router..
> So I am unable to access my web, mta, ftp servers that are located in DMZ
>
> My ipfw firewall script looks as follows:
>
> #!/bin/sh
>
> cmd="ipfw -q"
>
> DMZ="192.168.0.0/24"
> LAN="10.0.0.0/24"
>
> kldstat -q -m dummynet || kldload dummynet
> $cmd flush
>
> $cmd add 80 divert natd ip from any to any via vr3
> $cmd add 90 allow ip from any to any via lo0
>
> $cmd add 100 allow ip from any to me
> $cmd add 101 allow ip from me to any
>
> $cmd add 500 deny ip from $DMZ to $LAN
> $cmd add 510 deny ip from $LAN to $DMZ
>
>
> $cmd add 10000 allow ip from any to any
>
> I know I've blcoked traffic between DMZ and LAN, but I wanted them to
> contact via public IPs.. but now I'm not sure if it's possible...
>
> Can you give me some hints on how to properly configure my router?
>

There are two ways to do this, depending on whether or not you want to
"leak" you private LAN IPs into the DMz.

The simplest method, where LAN clients connect to the public IP of the DMZ
servers, and where the DMZ servers see the private IPs of the clients, is
like so:

# Configure the natd process to NAT from x.x.x.170 to 192.168.0.10 using
some port
natd -port $port -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 $port 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

ipfw add allow ip from $LAN to 192.168.0.10 out xmit vr2
ipfw add allow ip from 192.168.0.10 to $LAN in recv vr2

ipfw add divert ip from 192.168.0.10 to $LAN out xmit vr0
ipfw add allow ip from x.x.x.170 to $LAN out xmit vr0

Repeat the above for each of the servers in the DMZ, using separate natd
processes for each, with separate divert port numbers.

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

192.168.0.10 --> 10.0.0.x
x.x.x.170 --> 10.0.0.x


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.

-- 
Freddie Cash
fjwcash at gmail.com


More information about the freebsd-net mailing list