[isapros] Re: ISA 2006 Design Questions
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 16 Mar 2007 09:08:47 -0700
I'm just surprised you're the only one to react...
:-p
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Thor (Hammer of God)
Sent: Friday, March 16, 2007 8:58 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA 2006 Design Questions
OMG. You said "kick the perms." Why'd you have to start our day like
that??
t
----- Original Message -----
From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
To: <isapros@xxxxxxxxxxxxx>
Sent: Wednesday, March 14, 2007 6:21 AM
Subject: [isapros] Re: ISA 2006 Design Questions
> We need to clear up a misconception:
> - CSS doesn't "push"; ISA "pulls". It's possible to "kick the perms"
by
> forcing a policy refresh at each ISA from the CSS, but the policy
> changes happen at each ISA because that server pulls the changes from
> CSS.
> - you haven't stated your expected traffic profile. Without that, any
> design considerations are woefully incomplete. If you respond with
> anything like "Internet access" or "normal stuff", we'll kick you off
> the list <g>.
> - what's the point of the dual-homed OWA / SMTP servers? This seems
> like complexity for its own sake.
> - what's the "CSS / NLB" point you didn't finish?
>
> To the questions:
> 1. Yes, but you *must* use a routed relationship between networks (2),
> (3) and (4). Too many domain-related protocols don't tolerate NAT.
> 2. *Do Not Use Firewall Chaining* - just don't. ISA 3/4 can be web
> proxy & SecureNET clients to ISA 1/2 and this should work fine in most
> cases.
> 3. Of course there are routing table considerations. How is ISA 1/2
> supposed to pass traffic to network 4 without a routing table entry
> telling TCP/IP how to direct the traffic? You'll want to read the
> "network behind a network" articles on ISAServer.org.
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx]
> On Behalf Of Gerald G. Young
> Sent: Tuesday, March 13, 2007 3:14 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] ISA 2006 Design Questions
>
> All,
>
> I wanted to bounce this design concept off of the list to see if
anyone
> might be able to help me avoid any pitfalls this particular design
might
> present. While I've played with ISA 2004 Enterprise Edition in a
> limited sense, I have not yet implemented anything that incorporates
> everything I'm looking to incorporate here. Below is a network
diagram
> of the design concept. The questions I have follow.
>
> ----------------------------------------
> o-----------o *1
> | Internet | *1
> o-----------o *1
> | *1
> | *1
> | *1
> | *1 MS NLB VIPs *1
> o-------o *1
> | | *1
> | | *1
> 0-----0 0-----0 *1
> -----------| ISA |-| ISA |--------------
> 0-----0 0-----0 *2
> | | *2
> | | *2
> o-------o *2
> | *2 MS NLB VIP *2
> | *2
> o----------------------o *2
> | | *2
> 0-----0 0------0 *2
> | OWA |___ | SMTP |___ *2
> ---| RPC | |-----------| GW | |---
> 0-----0 | 0------0 | *3
> |______| |______| *3
> | | *3
> o----------------------o *3
> | *3
> | *3 MS NLB VIP *3
> o-------o *3
> | | *3
> | | *3
> 0-----0 0-----0 *3
> -----------| ISA |-| ISA |--------------
> 0-----0 0-----0 *4
> | | *4
> | | *4
> o-------o *4
> | *4 MS NLB VIP *4
> | *4
> o-------------------o *4
> | | *4
> 0---------0 0---------0 *4
> | ISA CFG | | Infra | *4
> 0---------0 0---------0 *4
> ----------------------------------------
>
> Legend
> ------
> *1 - Internet VLAN
> *2 - DMZ External VLAN
> *3 - DMZ Internal VLAN
> *4 - Trusted VLAN
>
> The things that I am unsure about are as follows:
>
> 1. Can all ISA servers be part of the forest located in *4?
>
> I'm assuming yes they can but I'm a bit unclear on what I would need
to
> do with the system policy on the ISA servers to make that work.
>
> 2. What kind of clients will I need to configure each protected server
> as?
>
> There was a lot of talk about SecureNAT, NAT, etc., kind of clients.
> Since some boxes will need to traverse both the front-end and back-end
> ISA servers for Internet access (BES, WSUS, etc.) what do I need to be
> aware of to get them to play nicely across the ISA servers when using
> them for that access? Or, can I get away with simply creating access
> rules for Internet access and not worry about configuring the ISA
> servers as proxies (no corporate users to worry about - just a
messaging
> and collaboration solution accessed externally)?
>
> 3. Is there any special consideration for configuring the routing
tables
> on the servers?
>
> This may be as simple as doing the following but I wanted to confirm.
>
> DMZ Devices' Network Configuration
> *2 VLAN NICs set with default gateway pointing to *2 MS NLB VIP.
> Static route set for *3 VLAN NICs which points *4 VLAN-destined
traffic
> to *3 MS NLB VIP.
>
> Trusted Devices' Network Configuration
> *4 VLAN NICs set with default gateway pointing to *4 MS NLB VIP.
>
> 4. Is it a good idea to use a Configuration Server in the Trusted VLAN
> to hold policies for all ISA Servers?
>
> I like the idea of a central Configuration Server from which to push
> policies to ISA Array members. I also seem to recall this is
preferable
> when using NLB (although I know a work around). What I'm not sure
about
> is whether or not the ISA Array members talk to each other directly or
> via the Configuration Server, and if via the Configuration Server
> whether that chatter is significant enough to justify keeping it on a
> local segment.
>
> If a remote Configuration Server is the way to go, are they any
pitfalls
> to be aware of when setting it up to manage both front-end and
back-end
> ISA Servers?
>
> The tip of the iceberg, I'm sure, but I thought this might be enough
to
> get me out of the gates.
>
> Thank you in advance.
>
> Cordially yours,
> Jerry G. Young II
> Application Engineer, Platform Engineering and Architecture
> NTT America, an NTT Communications Company
>
> 22451 Shaw Rd.
> Sterling, VA 20166
>
> Office: 571-434-1319
> Fax: 703-333-6749
> Email: g.young@xxxxxxxx
>
>
>
>
> All mail to and from this domain is GFI-scanned.
>
>
>
>
All mail to and from this domain is GFI-scanned.
Other related posts:
