In typical enterprise networking, the recommended way to build in Internet
connectivity is with the classic DMZ: there are two firewalls, one facing
the Internet and the other facing the corporate network; all DMZ resources
can make connections out the Internet as well as receive inbound
connections; the internal firewall allows only outbound connections from the
internal network, thus preventing the internal network from being attacked
by the DMZ. OK, so far so good -- there's never really any reason for DMZ
hosts to make connections into the internal network.
But what about for service providers? Your typical hosted Exchange
environment will have protocol servers in a front-end network and an
Exchange store in a back-end network. Obviously, now, there will need to be
some traffic originating from the front net (DMZ) and heading into the back
(internal network). Since this traffic might be carried over RPC, does it
really even make sense to put a firewall between the front and the back
networks? My gut tells me it's still the best thing to do, even if you have
to open up the firewall to handle RPC (and we can limit port use by making
some registry modifications on the servers). You could use IPSec to carry
all that traffic and therefore lock down the firewall, but most
implementations use clusters in the back network, and IPSec doesn't like
clusters very much.
I'm asking this question because a number of network designers have simply
dual-homed their front-end servers, with one NIC pointing to the Internet
and the other NIC pointing to the back. I'm just not comfortable with this,
but honestly I can't really think of concrete reasons why! Maybe my brain
won't engage today. Anyway, what are your thoughts on this? Thanks!
___________________________________________________________
Steve Riley
Microsoft Telecommunications Consulting in Denver, Colorado
[EMAIL PROTECTED]
+1 303 521-4129 or [EMAIL PROTECTED]
www.microsoft.com/isn/
Applying computer technology is simply finding the right wrench to pound in
the correct screw.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
