[isapros] Re: Exchange NSPI Proxy RPC Communications and ISA

  • From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
  • To: <isapros@xxxxxxxxxxxxx>
  • Date: Sat, 12 Aug 2006 17:42:35 -0700

Ah, yes.

While this is a desirable design, it's also a very difficult one.

What are the network relationships between the networks?

For instance:

ExchFE ßà Exch BE == Route

...?

Have you disabled Strict RPC on the relevant rules?

 

NAT ain't happenin' FWIW...

What's the "Internet FW"?

 

From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jason Jones
Sent: Saturday, August 12, 2006 3:18 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Exchange NSPI Proxy RPC Communications and ISA

 

 

 

________________________________

From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
Sent: 12 August 2006 22:41
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Exchange NSPI Proxy RPC Communications and ISA

Maybe a napkin drawing, then?

I don't understand how your BE needs specific rules unless its separated from 
the DC by ISA?

 

From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jason Jones
Sent: Saturday, August 12, 2006 2:19 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Exchange NSPI Proxy RPC Communications and ISA

 

No, not confused, and realise the difference between RPC/HTTP and MAPI. I guess 
I am obviously not explaining myself very well with a complex environment and 
the problem very specific.

 

>>AS such, any NSPI connections are strictly the problem of the BE server.

 

Not in this scenario, as the BE is in an ISA protected network seperated from 
the DCs and FEs. The rule that allows access from BE=>DCs is using RPC (All 
interfaces) and yet ISA is blocking traffic from the NSPI proxy when using 
RPC/HTTP. All other RPC traffic from BE=>DCs is working as expected and ISA is 
detecting the RPC dynamic ports correctly.

 

If I allow All outbound protocols from BE=>DCs the NSPI proxy works and I see 
ports 1025. 1026 etc being used. It seems as if ISA is missing the intitial RPC 
negations between the NSPI proxy and DCs and hence blocks all dynamic ports 
after 135 is contacted.

 

Maybe I need to provide some diagrams and/or better desacirptions...

 

JJ

 

________________________________

From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jim Harrison
Sent: 12 August 2006 16:55
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: Exchange NSPI Proxy RPC Communications and ISA

I think you're confused; RPC/HTTP doesn't use MAPI; it's "just" HTTP traffic.

AS such, any NSPI connections are strictly the problem of the BE server.

 

The only way ISA handles RPC traffic is via Exchange RPC or RPC (All 
interfaces) rules.

 

From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On 
Behalf Of Jason Jones
Sent: Friday, August 11, 2006 5: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 

All mail to and from this domain is GFI-scanned.

All mail to and from this domain is GFI-scanned.


All mail to and from this domain is GFI-scanned.

JPEG image

Other related posts: