[isapros] Re: Exchange NSPI Proxy RPC Communications and ISA
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Sat, 12 Aug 2006 10:17:56 -0500
Hi Jason,
It's not clear here what's going on. Are you using RPC/HTTP?
Where is the RPC/HTTP proxy?
Where is the BE Exchange Server?
Are they each on the same ISA firewall Network?
Thanks!
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7>
MVP -- ISA Firewalls
________________________________
From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
Sent: Friday, August 11, 2006 7:13 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Exchange NSPI Proxy RPC Communications and
ISA
Hi,
Bit of a shot in the dark, as this is a strange issue, but
hoping someone can confirm what I am seeing.
Basically, I have a pretty secure Exchange environment whereby
both Exchange FE's and BE's are on ISA protected perimeter networks with
the external network connected to the 'traditional LAN' e.g., ISA is
acting as a multinetwork internal firewall to specifically protect
Exchange from the internal network (all routed relationships). In this
scenario, ISA is controlling all communications to and from Exchange and
all email client access is published using web publishing or secure RPC
publishing.
Up until now everything has been working pretty well (apart from
the other RPC filter issues in my other posts!) but we have come across
a specific issue when using RPC/HTTP as follows:
The problem seems to lie with the fact that the back-end
Exchange server is talking to the GCs and ISA is seeing these
connections as newly initiated connections (e.g. non RPC) as opposed to
detecting them as dynamic ports which have been defined as part of the
RPC handshake process. Therefore, ISA is dropping these connections and
prevents the back-end server from communicating with the GCs,
specifically for RPC/HTTP (e.g. when using the NSPI proxy). All other
communications which relate to RPC and ISA's ability to detect dynamic
RPC ports is being done successfully (e.g. MAPI communications from
Outlook to Exchange). It looks to me as if the back-end Exchange server
is initiating it own connections which ISA sees as communications
independent of RPC. The issue only appears to arise when the back-end
servers proxy the client AD communication (e.g. when using the NSPI
proxy), as is the case with RPC/HTTP, because Outlook clients have no
access to the GCs from the Internet. For standard MAPI clients, they are
simply given a referral to the actual GCs which they communicate with
directly, independent of Exchange (e.g. not using NSPI proxy).
Does this sounds familiar? Is Exchange doing something weird
here or is ISA missing the RPC dynamic port negotiations?
Looking at the ISA logs, I see ports 1025, 1027, 1030 etc. being
used by the NSPI proxy which I am pretty sure are going to be the kind
of ports dynamic RPC would use. If I add the ephemeral ports
(1024-65535) to the existing BE=>GC rule everything work just fine. If I
limit ports to standard intradomain protocols including RPC then
everything works apart from RPC/HTTP and I start seeing ports 1025, 1027
etc. being denied by ISA as unidentified traffic.
Answers on a postcard! ;-)
Cheers
JJ
Other related posts:
