[isapros] Re: RPC filter and ISA port stealing - limitation???
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>,<isapros@xxxxxxxxxxxxx>
- Date: Mon, 26 Jun 2006 06:22:41 -0700
If you use ISA to separate AD members, you *must* have a routed relationship
between them.
If you use NAT, you break ~half of the protocols used.
"Port stealing" isn't the issue.
________________________________
From: isapros-bounce@xxxxxxxxxxxxx on behalf of Jason Jones
Sent: Mon 6/26/2006 5:05 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: RPC filter and ISA port stealing - limitation???
No takers?
Jason Jones | Silversands Limited | T: 01202 360489 | M: 07971 500312 | F:
01202 360900 | E: jason.jones@xxxxxxxxxxxxxxxxx
<mailto:jason.jones@xxxxxxxxxxxxxxxxx>
________________________________
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Jason Jones
Sent: 22 June 2006 15:17
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] RPC filter and ISA port stealing - limitation???
Hi,
In some of Tom's older articles, he has talked about problems that can occur
when you are using the RPC filter to protect *both* domain controllers and
Exchange servers behind the same ISA array. This problem seem to occur due to
the nature of ISA performing "port stealing" in order to listen for incoming
RPC connections and map port accordingly. An example quote from Tom's article
may explain this a little better (see below).
A lot of our solution designs are starting to place all Microsoft services
behind ISA in untrusted environments (e.g. universities) and hence the need for
the RPC filter to provides limited UUIDs for Exchange and also to allow all or
limited UUIDs for AD is starting to become more and more apparent. Up until now
it hasn't been much of an issue as people have been reluctant to place AD
servers behind ISA (mainly due to complexity and ISA dependency) or Exchange
has been able to use the DSproxy process to allow Exchange clients with proxied
indirect directory access.
Is this still a known problem with 2k4 SP2 code or has it been fixed? Does
ISA2k6 have anything to combat this problem?
Cheers
JJ
"Because we are using a Route relationship instead of a NAT relationship
between the source and destination Network, we can't bind a specific IP address
to the listener used in the Server Publishing Rule. When you use a Route
relationship, the Server Publishing Rule listens on all addresses bound to the
external interface using a feature known internally as port stealing. Because
both the Secure Exchange RPC server Server Publishing Rule and the RPC (all
interfaces) component of the intradomain communications Access Rule are
listening for similar communications, we end up with a conflict that prevents
Outlook MAPI clients from connecting to Directory services.
If there were a NAT relationship between the Corpnet and the network services
segment, we could bind multiple IP addresses to the external interface of the
network services perimeter ISA firewall. Then we could create two rules: one
for Secure Exchange RPC publishing and the other for RPC (all interfaces) and
use a different listening address for each of the rules. Machines on the
Corpnet ISA firewall Network then connect to Secure Exchange RPC services or
RPC (all interfaces) services using the IP address used for their respective
rule's listener. This works because connections are made to the IP addresses on
the ISA firewall's external interface when you have a NAT relationship between
the network services segment and the Corpnet ISA firewall Network.
It doesn't work when there is a Route relationship between the network services
segment and the Corpnet ISA firewall Network because hosts on the Corpnet ISA
firewall Network connect to the Exchange server using the actual IP address of
the Exchange Server. Since the hosts are connecting to the IP address of the
Exchange Server itself and not an IP address on the external interface of the
ISA firewall, the ISA firewall's port stealing mechanism must listen and
intercept RPC communications on all IP address of the external interface. This
breaks the granularity required to allow both a Secure Exchange RPC Server
Publishing Rule and a RPC (all interfaces) Access Rule on the same ISA firewall
when there is a Route relationship between the source and destination ISA
firewall Networks.
You can confirm this by creating both a secure Exchange RPC Server Publishing
Rule in the scenario used in this article series. Then attempt to make a
connection to the Exchange Server from the full Outlook MAPI client using RPC
(don't use RPC/HTTP, since the inbound connection is HTTP, so the ISA firewall
doesn't see the RPC communications tunneled in the HTTP header). You'll that
the connection seems to establish successfully, but if you open the Connection
Status window in Outlook 2003, you'll find that the RPC connections are
successful only to the Exchange Server's Mail Services. No connection is
established to Directory Services. "
All mail to and from this domain is GFI-scanned.
Other related posts:
