Client ORPC bind request on TCP port 135 is reset by server

[jiffle]

I've got a client trying to use a remote DCOM object. The client is configured with the object's location via dcomcnfg. When I initiate the request I can see the client connect to TCP/135 on the server, and both complete a TCP/IP handshake. When the client then sends its Bind request to the server it gets a TCP/IP reset sent back to it. I've checked the eventvwr logs (this is NT4 SP6 by the way) and can see nothing on the server. The client reports DCOM 10009 in the event logs, and returns error 462 to the caller, which both basically say it can't contact the remote server. What's really strange is that the TCP/IP session which was established on the server still shows as ESTABLISHED (via a netstat command) even though the server sent a reset back to the client. It looks like it could be a problem with endpoints but I think my configuration is okay (all using ncacn_ip_tcp with a defined range of ports). Also note that we're barely getting into DCOM here, ie we're just doing the ORPC stuff. Any ideas please? Anybody else seen anything like this?

 

[chiph]

Is there a firewall inbetween the client and the server?
Does the server have it's port control (in TCP/IP advanced settings) set to allow port 135?

Is there a chance that the DCOM Server is on the server twice, isn't registered correctly, or is missing a required component?

Chip H.

 

[jiffle]

Hi Chip. No there's no firewall between the client and server in this particular case, they're both on the same switch and subnet. Yes the advanced TCP/IP settings allow port 135 (in fact we removed all port controls as part of our testing, as well as unrestricting DCOM access and launch permissions). I'm not sure how to answer "Is there a chance that the DCOM Server is on the server twice, isn't registered correctly, or is missing a required component?" because I don't know how to tell! As far as we know it's okay, the only strange thing is that 'netstat -na' shows TCP port 135 listening twice, but then I've since found that's the case on other servers so perhaps it is normal? Not normal for TCP/IP, but normal for Microsoft . In any event we've been doing some more work and discovered this problem happens when a particular Microsoft patch is applied so we've got a call open with them at the moment...

 

[swgray1]

Hi Jiffle

Which patch was causing the problems - I am having the same issue...

 

[jiffle]

Hello SWGRAY1, I don't remember the details now (I was pulled off this particular problem to go and fix something else) but somebody identified one of Microsoft's major SRPs (security roll-up patches) which conflicted with SNA. The SRP patched lots of things, including I believe some RPC vulnerabilities, and also played around with syn flood protection. If you don't have SNA then your root cause may be different (well, could be different anyway I suppose).