[isapros] Re: ISA 2006 Design Questions
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 16 Mar 2007 13:57:40 -0700
Ktp's represents the magical view of our world of computering
-----Original Message-----
From: "Thor (Hammer of God)"<thor@xxxxxxxxxxxxxxx>
Sent: 3/16/07 9:28:56 AM
To: "isapros@xxxxxxxxxxxxx"<isapros@xxxxxxxxxxxxx>
Subject: [isapros] Re: ISA 2006 Design Questions
Tom's probably still waiting for his eyesight to return.
t
----- Original Message -----
From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
To: <isapros@xxxxxxxxxxxxx>
Sent: Friday, March 16, 2007 9:08 AM
Subject: [isapros] Re: ISA 2006 Design Questions
> 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:
