Re: kern/159353: [netinet] [patch] conditional call of ifa_del_loopback_route()
The following reply was made to PR kern/159353; it has been noted by GNATS. From: Svatopluk Kraus To: bug-follo...@freebsd.org Cc: Subject: Re: kern/159353: [netinet] [patch] conditional call of ifa_del_loopback_route() Date: Tue, 9 Aug 2011 12:55:42 +0200 This PR can be closed because (IMHO) more complex patch (I'm just trying to work on) is needed. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ipfw - accessing DMZ from LAN
Hi all,
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 1 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?
Regards,
--
Marek Salwerowicz
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ipfw - accessing DMZ from LAN
Hi all,
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 1 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?
Regards,
--
Marek Salwerowicz
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfw - accessing DMZ from LAN
On Aug 9, 2011, at 4:57 AM, Marek Salwerowicz wrote:
> 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
It's not working because you configured natd to work against traffic flowing
via vr3, but traffic from your LAN is coming via vr0. While you can change
natd to run against all traffic, it's much better to avoid re-writing purely
internal traffic by setting up a DNS view for your machines in the DMZ which
uses internal IPs rather than the public IPs.
Or, if you insist upon your DMZ hosts being on externally routable IPs, then go
ahead and configure them with externally routable IPs rather than using natd's
redirect_address, and only do NAT for internal traffic via vr0 instead.
Regards,
--
-Chuck
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfw - accessing DMZ from LAN
W dniu 2011-08-09 15:09, Chuck Swiger pisze:
On Aug 9, 2011, at 4:57 AM, Marek Salwerowicz wrote:
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
It's not working because you configured natd to work against traffic flowing
via vr3, but traffic from your LAN is coming via vr0. While you can change
natd to run against all traffic, it's much better to avoid re-writing purely
internal traffic by setting up a DNS view for your machines in the DMZ which
uses internal IPs rather than the public IPs.
So should I allow trafic from LAN to DMZ and setup my local DNS to
connect to hosts in DMZ using private IPs ?
Or, if you insist upon your DMZ hosts being on externally routable IPs, then go
ahead and configure them with externally routable IPs rather than using natd's
redirect_address, and only do NAT for internal traffic via vr0 instead.
Am I able to configure them with externally IPs only and having eg.
bandwidth control using only one router?
My current setup is that I have separately router, web server and mail
server but If I want to limit bandwidth, I have to do it on proper
machine instead of configuring only one device.
Regards,
--
Marek Salwerowicz
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfw - accessing DMZ from LAN
On Aug 9, 2011, at 6:15 AM, Marek Salwerowicz wrote: >> It's not working because you configured natd to work against traffic flowing >> via vr3, but traffic from your LAN is coming via vr0. While you can change >> natd to run against all traffic, it's much better to avoid re-writing purely >> internal traffic by setting up a DNS view for your machines in the DMZ which >> uses internal IPs rather than the public IPs. > > So should I allow trafic from LAN to DMZ and setup my local DNS to connect to > hosts in DMZ using private IPs ? Yes, that ought to work fine. In fact, in the classic screened-subnet design from which the notion of DMZ hosts originated, you only permitted traffic from LAN to DMZ, and blocked all traffic from outside to LAN. This meant that all LAN hosts needed to go through proxies or other services living in the DMZ-- internal hosts never talk to strangers, so to speak. :) >> Or, if you insist upon your DMZ hosts being on externally routable IPs, then >> go ahead and configure them with externally routable IPs rather than using >> natd's redirect_address, and only do NAT for internal traffic via vr0 >> instead. > > Am I able to configure them with externally IPs only and having eg. bandwidth > control using only one router? > > My current setup is that I have separately router, web server and mail server > but If I want to limit bandwidth, I have to do it on proper machine instead > of configuring only one device. dummynet (or Altq, or whatever else you might be using) works fine with pure routing config, yes-- you don't have to NAT traffic to do bandwidth control on the router. Regards, -- -Chuck ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfw - accessing DMZ from LAN
W dniu 2011-08-09 15:26, Chuck Swiger pisze: dummynet (or Altq, or whatever else you might be using) works fine with pure routing config, yes-- you don't have to NAT traffic to do bandwidth control on the router. How it should be done? Leave the aliases at my external interface, and then 'bridge' DMZ interface with external and set up public IPs on my DMZ hosts? Regards, -- Marek Salwerowicz ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfw - accessing DMZ from LAN
On Aug 9, 2011, at 6:45 AM, Marek Salwerowicz wrote: > W dniu 2011-08-09 15:26, Chuck Swiger pisze: >> dummynet (or Altq, or whatever else you might be using) works fine with pure >> routing config, yes-- you don't have to NAT traffic to do bandwidth control >> on the router. > > How it should be done? > Leave the aliases at my external interface, and then 'bridge' DMZ interface > with external and set up public IPs on my DMZ hosts? You don't need to do NAT aliasing if you make your DMZ hosts directly routable-- you just need to do firewall and bandwidth shaping. If your provider is cooperative, then their end and your external NIC (vr3?) can switch to communicate over an unroutable /30 subnet, and your FreeBSD box's DMZ NIC (vr2) is reconfigured with the public router IP they are now vending. If they aren't willing to make such changes, then yes, you could bridge between vr3 and vr2 instead; you need to set the net.link.ether.bridge_ipfw=1 sysctl for IPFW to act on bridged traffic. There are more complicated solutions which could also work, but there doesn't seem to be a need for them. IMO, it's cleaner and more efficient to explicitly route between networks off of a firewall than it is to permit subnet-local broadcast traffic to pass thru the firewall. Regards, -- -Chuck ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfw - accessing DMZ from LAN
On Tue, Aug 9, 2011 at 4:59 AM, Marek Salwerowicz 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 1 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 (
Re: kern/159601: [netinet] [patch] in_scrubprefix() - loopback route refcount malfunction
Old Synopsis: [patch] in_scrubprefix() - loopback route refcount malfunction New Synopsis: [netinet] [patch] in_scrubprefix() - loopback route refcount malfunction Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 10 00:27:54 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=159601 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problem using CARP + HAST ...
On Mon, 8 Aug 2011 16:54:10 +0200 Ferdinand Goldmann wrote:
FG> Hi!
FG> I am trying to create a common resource pool for a certain application
using
FG> CARP/HAST as described in [1]. However while testing my setup I ran into a
FG> problem which I don't know how to fix or work around:
FG> If I shut down only the carp interface on the master (ifconfig carp0 down),
FG> the slave will take note of this, make his carp interface the master and
FG> mount the HAST storage using a script called by devd. Everything fine so
far. BUT:
FG> If, however, I completely shut down the masters network connection (using
"shut" on
FG> the switchport), the carp interface on the slave will still switch to
master.
FG> But the script for making the HAST storage primary will just hang forever:
FG> root 46841 0.0 0.6 3628 1524 ?? S 4:21PM 0:00.08 /bin/sh
/opt/bin/carp-hast-switch master
FG> root 47043 0.0 2.6 42228 6580 ?? S 4:22PM 0:00.03 hastd: hast0
(secondary) (hastd)
FG> Seemingly, this is because the hastd daemons on master and slave are
unable to
FG> communicate. So the script waits forever for the secondary device to go
away... :
FG># Wait for any "hastd secondary" processes to stop
FG>for disk in ${resources}; do
FG>while $( pgrep -lf "hastd: ${disk} \(secondary\)" > /dev/null
2>&1 ); do
FG> sleep 1
FG> done
What freebsd are you running on? I suppose it is release, because on STABLE
this issue should be fixed -- the secondary terminates after timeout.
FG> Im a bit puzzled. Is there a way for hastd to make himself the master in
case of a timeout
FG> or such? Because in normal operation, whenever the carp interface fails,
the underlying
FG> infrastructure will most likely be down as well.
On release you can just modify the script not to wait forever for hastd
secondary to stop -- it will be terminated when the role is switched to
primary.
But anyway my advise is to use STABLE :-).
--
Mikolaj Golub
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfw - accessing DMZ from LAN
W dniu 2011-08-09 18:04, Freddie Cash pisze:
On Tue, Aug 9, 2011 at 4:59 AM, Marek Salwerowicz 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 1 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.1
