Re: ISA 2004 Enterprise in Checkpoint DMZs
- From: siewjb <siewjb@xxxxxxxxxxxxxx>
- Date: Tue, 1 Aug 2006 08:50:02 -0700
Thanks for the advice, and I agree with both of you, that would be my
preferred method of implimentation. It would be far easier to setup since I
could just join our AD Domain via the internal network, and configure ISA
with the appropriate rules. I also wouldn't be struggling to find out what
ports, etc. need to be opened through the firewall. I also wouldn't be
fighting to figure out how to configure RPC on all our servers to allow this
sort of setup.
The problem is that our Firewall/Network admin is a UNIX guy who does not
trust anything that has the name "Microsoft" stamped on it. He also does not
want a machine in the DMZ with a direct network connection back to the
internal LAN. All traffic coming to the inside must go through the firewall
(twice in this case). Let's face it, the job of the security guy is to be
extremely paranoid, so I can't fault him for it.
On a side note, we are not planning on using caching, or having our users
authenticate to use the internet.
So, is there little to no chance of the proposed setup working? Any other
comments, suggestion, or just plain help?
Thanks again.
"Ray" wrote:
I agree with Virgil. I did the design for our 2,500 employee company to put.
ISA's external interface off a Check Point DMZ interface while putting ISA's
internal interface on the same stub network as the FW-1 internal interface.
We started with ISA 2000 and are now on ISA 2004. We've run this way for
four years.
We use ISA in this configuration to publish Outlook Web Access and also as a
proxy server for all internal computers. ISA has GFI's WebMonitor HTTP virus
scanner running on it. All users are required to authenticate to ISA with
their domain credentials before they can get to the Internet. FW-1 has a
rule that drops all outbound HTTP & HTTPS traffic unless it comes from the
external interface of the ISA server.
I am both the FW-1 admin and the ISA admin plus I hold a CCSE certification
from Check Point. Using ISA for this purpose is one of the few times I think
it provides better protection than FW-1 alone does. Not only does Microsoft
understand the requirements of OWA and Exchange the best, ISA can perform
SSL termination.
If you're using SSL for OWA, you need to forward TCP 443 straight through
FW-1, so no inspection is possible. On ISA, however, you can bind the SSL
certificate to its external interface. The Internet client blows through
FW-1 and has their SSL session terminated on the ISA external interface, the
decrypted traffic is inspected and handled by ISA, and then ISA
re-establishes an SSL connection between its internal interface and the
Exchange server. The only time the traffic is decrypted before it gets to
Exchange is internal to ISA.
The combination of FW-1 and ISA is really optimum in my opinion. All of the
HTTP virus scanning is off-loaded from FW-1 and the caching abilities of ISA
dramatically reduces the size of the connection table on FW-1 (since all
HTTP/HTTPS connections originate from only one computer, the ISA server). It
also significantly reduces the usage of the Internet connection. We saw a
full 35% drop in peak and average utilization ourselves due to ISA's web
proxy caching ability. We've never had a complaint about "stale" content
being served up by ISA.
HTH,
Ray
"ZVR" <no_spam_ever@xxxxxx> wrote in message
news:44cedbba$0$2699$9a6e19ea@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi there,
Your proposed configuration with ISA having two interfaces in two separate
DMZ's is an overly complicated contraption that will not work, and even if
it _could_ be made to work it would be a nightmare to administer.
The key concept here is that ISA really shines in configurations where its
internal interface is connected to the LAN. That is the perfect textbook
example for Exchange publishing. Of course you can place another firewall
in front of ISA in this scenario, for an even more secure (read paranoid)
deployment. That is called a back-to-back firewall topology and it is what
you would do - seeing as the Checkpoint needs to stay in place.
So basically what you do, is alter your suggested diagram a little, so
that the 2nd ISA interface connects to the Internal network, instead of
connecting to that "DMZ2" contraption. Obviously in this topology you
don't need routes or to open "blanket" ports through DMZ2 - you only need
to open ports in Checkpoint for the published services.
Having said that, here's an article that deals with this exact kind of
setup - except the front firewall is another ISA not a Checkpoint;
concepts apply word for word though.
Publishing an OWA Site in a Back to Back ISA Firewall Configuration
http://www.isaserver.org/tutorials/Publishing-OWA-Site-Back-to-Back-ISA-Firewall-Part1.html
Virgil
- References:
- Re: ISA 2004 Enterprise in Checkpoint DMZs
- From: ZVR
- Re: ISA 2004 Enterprise in Checkpoint DMZs
- From: Ray
- Re: ISA 2004 Enterprise in Checkpoint DMZs
- Prev by Date: Re: Incoming SMTP problem
- Next by Date: Re: Publishing a rule to connect to printer
- Previous by thread: Re: ISA 2004 Enterprise in Checkpoint DMZs
- Next by thread: Re: ISA 2004 Enterprise in Checkpoint DMZs
- Index(es):
Relevant Pages
|
