On Monday 29 December 2003 04:43 am, Antony Gelberg wrote: > But if they wanted to run a public email server as well, clearly that > needs a public IP address. Fine, but how does the routing aspect > work? Do I need to ditch the bridging configuration on the firewall > and reconfigure it as a router with 3 NICs? One connected to the > WAN, one to the private LAN switch, and one to the public server(s) > switch?
There are a number of ways to accomplish what you're looking to do. Agreed, for your current setup your bridged firewall is probably a nice way to do things. The three port bridged environment looks tricky to implement correctly, and while it could be done, it'll probably long-term be more trouble than it's worth. Some folks gave you some other options, which were definitely "workable" but mix your public and private traffic. If you trust your switches to keep that traffic separate even under the load of a DoS attack, that might be a reasonable way to go. I like to think in terms of "what MUST be up and running for this to work" and engineer the network accordingly. For example, if you were to move the mail server completely OUTSIDE the firewall (put a switch between the DSL router and the firewall and hang the mail server off of that) and then if you're careful and harden the box, you can just place it directly on a public IP and run a host-based iptables firewall and say maybe snort to keep an eye on suspicious traffic to it. Why do this? Well, perhaps one reason is that if the firewall is down, the mail is still up and getting deliveries. The DSL router and a switch are an order of magnitude more "robust" than the firewall which could be down for upgrades, etc. Think "maintenance". The "just put a public address inside the firewall" works fine too but could create havok if the mail server is attacked or heavily loaded... affecting overall network performance for the clients already on the private-side network. Port-forwarding would be my least likely pick because it puts public traffic directly on the internal IP range. I don't like that idea at all if it can be avoided. I have used it in the past for a quick-and-dirty solution to get something working that was originally an "internal only" application that suddenly needs to have a worldwide presence, but that's definitely not my proudest "security decision" I've ever had to make. It's all about risk-management and load-management and documenting the possible solutions and then picking one for a reason... going through that process will also point out the negatives of any particular setup and will allow you to know more fully where your system has weaknesses. Have fun, -- Nate Duehr, [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
