[isapros] Re: ISA 2006 Design Questions
- From: "Gerald G. Young" <g.young@xxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 16 Mar 2007 09:45:24 -0400
Jim,
Thank you for the response. Further details are below.
>- 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.
Thank you for the clarification. So, if I understand it properly, the "push"
is really the CSS telling ISA that ISA needs to "pull" an updated policy. If
the CSS is on a different server, do the ISA Servers in an array still talk
with one another directly or is all communication proxied through the 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>.
The traffic profile from network (1) to network (2) will be 80, 443, and 25.
Traffic coming in on 80 will be redirected to 443.
The traffic profile from network (2) to network (1) will be 25 and 80/443 to
the WindowsUpdate site (contingency to WSUS not working).
The traffic profile from network (3) to network (4) will be all forest/domain
required traffic, backup traffic, and the required Exchange traffic for the
OWA/RPC and SMTP boxes.
The traffic profile from network (4) to network (3) will be the required
reversed communication for the traffic listed above with the addition of RDP
traffic (am likely to lock this down to one server on the Trusted VLAN).
It did become apparent as I was looking at this more closely thanks to the
question asked that I have no path between the front-end ISA servers and the
back-end ISA servers. To that end, imagine another network incorporated in the
diagram from before that connects the front-end ISA servers directly with the
back-end ISA servers. I'll call this network 2.5.
The traffic profile from network (2.5) to network (4) will be all forest/domain
required traffic, any inter-Array ISA required traffic (is there this?), and
backup traffic.
The traffic profile from network (4) to network (2.5) will be the required
reversed communication for the traffic listed above with the addition of RDP
traffic.
The traffic profile from network (4) to network (1) - via network 2.5 - will be
80/443 to the WindowsUpdate site, 3101 for BES to RIM traffic, and 53 (TCP/UDP).
>- what's the point of the dual-homed OWA / SMTP servers? This seems
>like complexity for its own sake.
The purpose is to separate service traffic from other traffic. External-facing
services are exposed through one interface without having to share bandwidth
with traffic above and beyond the minimum necessary for those external-facing
services. The other interface is used for servicing internal traffic only,
like forest/domain membership, backup, etc. Finally, I just personally find it
easier to logically troubleshoot network pathing problems when traffic "passes
through" the box.
- what's the "CSS / NLB" point you didn't finish?
NLB in Unicast mode (which will be used) usually means the hosts, where another
NIC isn't available for intra-cluster communication, can't speak with one
another, specifically ISA to the CSS. By moving the CSS off to another server,
this can be avoided. The work around (Registy key for W2K3 SP1) that I alluded
to, however, can be found at the following URL:
http://support.microsoft.com/kb/898867/
Thanks again, Jim, for the response. I do appreciate your time on this.
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
-----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.
Other related posts:
