From: Greg W. <gre...@gr...> - 2002-01-31 18:31:40
|
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 whatever. ;) 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. Proposition #1: Logical Description: DMZ host physically 'outside' the firewall. ISPRTR1 ISPRTR2 172.16.0.254 10.0.0.254 \ / FW-ETH1 / \ 172.16.0.1 / \ \ / \ FW-ETH0 FW-ETH2 DMZHOST 192.168.0.1 10.0.0.1 10.0.0.2 \ \ CLIENTS Advantages, as I see it: 1. Very few, if any, changes necessary to the configuration of the firewall. 2. True and traditional DMZ host. The only packet filtering is the stuff on the host itself. Disadvantages: 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 heritage building.... Now, the other configuration. We resubnet 10.0.0.0/24, and eth0 gets an alias on, e.g. 10.0.0.0/25. ISPRTR1 ISPRTR2 172.16.0.254 10.0.0.254 \ / FW-ETH1 / 172.16.0.1 / \ / FW-ETH0 FW-ETH2 192.168.1.1 10.0.0.129/25 \ / CLIENTS FW-ETH0:0 10.0.0.1/25 / DMZHOST 10.0.0.2/25 Advantages: 1. Another layer of packet filtering for DMZHOST. 2. Physically, this makes the network simpler in a few ways. Disadvantages: 1. Firewall config becomes more complex. 2. Different logical networks sharing physical layer. (yuck). Thoughts welcomed.... -- Greg White |