Microsoft RPC issue

[sasa.rasovic]

Hello,

Has anyone ever managed to make it work?

We have a problem with our Exchange server and allowing MAPI clients to connect if only RPC is allowed. This problem arises not only with Exchange RPC, but with MS's RPC in general.

Access lists permit all the ports that are necessary for the sessions, and 'established' command is used accordingly.

However, when sniffing on the session, there is always a very short and insufficient exchange of TCP/EPM/DCERPC packets- to be precise: only 5 to 50 packets are exchanged (while a regular MS RPC session takes more than 800)... It seems that PIX is cutting off the packets.

Ethereal shows that :"DCERPC Fault: call_id: 1 ctx_id: 0 status: Unknown (0x00000005)"...and just before that EPM Map request for certain UUIDs is made!

Note that we tried to make it work even without NAT!

Anyone had a similar problem, or at least has an idea of what seams to be the issue with this?

Thanks

Sasa

[paddyxdoyle · Accepted solution]

Hi,

I have looked into this before, our scenario was home office workers accessing our Exchange server through the PIX, so they were coming in from the outside interface and the exchange server was on the inside.

After lots of searching around, i discovered that using the established command on the PIX only works going from a high security interface to a lower one, or perhaps it could have been specifically from the inside interface to the outside, i can't quite remember.

I checked this with our Cisco representative at the time and he confirmed that this was true.

Thanks

Paddy

[sasa.rasovic]

Thanks Paddy,

Checked it out and it seems it works right when accessing RPC servers from a higher security interface.

Its quite amusing though, that the aforementioned possibility to access rpc servers in the oposite direction does not work as well (though it works for SUN RPC servers thanks to its rpc fixup). Lets hope it will be addressed in 7.0.

Good Luck,

Sasa

[douglasrichmond]

When you connect to an Exchange server the client connects on tcp 135 to establish the session then the Exchange server assigns the client 2 random ports > 1023. You can lock these ports down by following this microsoft article. http://support.microsoft.com/?kbid=259240

Microsoft has something similar for generic RPC communication. This article talks about how to limit RPC communication to a range so it will work through a firewall or router ACLs. http://support.microsoft.com/kb/154596 Hope all this helps.

Doug

[sasa.rasovic]

Thanks Douglas,

Unfortunately, that is not only Exchange Server that I want to made accessible.

So, when connect to any of Microsoft's RPC-based COM and DCOM servers, those applications use RPC EPM (135) and make requests for certain UUID. Problem is that when connecting from the interface that has a lower security level to any MS's rpc-based server, PIX seem to truncate responses and clients never get those ports to connect to. So the session is actually never initiated beyond ACK to 135.

On the other side, there is a possibility you suggest- to fix ports for secondary connections and open them statically, which could be very good if it was only one RPC server, but, I don't want to open that ammount of ports for my applications.

This is the same problem as is with non-statefull firewalls to accept ftp passive connections from outside to internal servers. As I recall, Washington University made some staff to make this work by limiting the surface of statically opened ports. Luckily for us, Cisco has a fixup for FTP, so do allmost all firewall vendors today.

However, when it comes to RPC, this doesn't even work with NAT!

Good Luck,

Sasa

[douglasrichmond]

Thats interesting I have never had to use the established command for RPC when going from a lower security interface to a higher one. Our OWA servers sit in a DMZ that has a lower security level than the inside interface. I did have very similar problems until I locked the ports down. I had to lock down both the Exchange ports and RPC ports for Windows. Here is another option but it only works with Exchange 2003. You can tunnel RPC over HTTP or HTTPS which would make it much easier connecting through your pix to multiple Exchange Servers. Here is the link. http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ex2k3rpc.mspx

Doug

[mostiguy]

You will never find happiness with MS RPC traversing nat.

other than that, there really shouldn't be any issues provided your access lists are not blocking anything necessary, which should be easily to detect.