Re: Public / private IP addresses
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, nate@natetech.com
Reply to: