[isapros] Re: RPC filter and ISA port stealing - limitation???
- From: "Jason Jones" <Jason.Jones@xxxxxxxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Mon, 26 Jun 2006 13:05:36 +0100
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. "
Other related posts:
