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.