[Shorewall-users] Network Redesign
Thu, 31 Jan 2002 10:31:57 -0800
First off, let me say thanks to Mr. Eastep for such a solid and easy to
use package. Seawall was the only ipchains 'package' firewall I ever
considered using, and Shorewall has been my first venture into the world
of iptables. The deployment I have just completed (and now need to redo
due to client requirement changes) was 100% straightforward and has been
working flawlessly for over a week.
Now, on to the question. The client now has a requirement that one of
the machines previously only accessible via the 'loc' zone should now be
partially accessible to the outside world. I've managed to convince them
that NAT is not the right way to do this. We're pretty much decided that
the host in question will now be multihomed, and (of course) not routing
between interfaces, and I've been kicking around two different options
as to how to wire this up, and I'd love some suggestions from anyone on
the list as to what might be considered 'best practices'. If you feel
that this is OT, feel free to reply off-list, ignore this, or flame, or
The location in question is blessed with two independent connections to
the internet. For the purposes of my hypothetical questions here, the
'primary' connection, which clients use to NAT out to the internet, has
addresses 172.16.0.0/24 available to it. The second internet connection,
which I had in mind for the DMZ, has addresses 10.0.0.0/24 available to
it, and the LAN, 192.168.1.0/24. (Yes, I know the addresses are bogus,
and that you know too. The question is purely a matter of theory.. )
Now that I think I've given enough info to draw the cheezy ASCII maps,
I'll get right down to it.
Logical Description: DMZ host physically 'outside' the firewall.
FW-ETH1 / \
172.16.0.1 / \
\ / \
FW-ETH0 FW-ETH2 DMZHOST
192.168.0.1 10.0.0.1 10.0.0.2
Advantages, as I see it:
1. Very few, if any, changes necessary to the configuration of the
2. True and traditional DMZ host. The only packet filtering is the stuff
on the host itself.
1. Single-point-of-failure packet filtering for DMZHOST.
2. Wiring a little more complex.*
*Due to physical considerations. The hookups for the other network are
across the room, and there are no cable channels anywhere, and it's a
Now, the other configuration. We resubnet 10.0.0.0/24, and eth0 gets an
alias on, e.g. 10.0.0.0/25.
1. Another layer of packet filtering for DMZHOST.
2. Physically, this makes the network simpler in a few ways.
1. Firewall config becomes more complex.
2. Different logical networks sharing physical layer.