Help! - Non RPC Auth - Port 135 Blocked

I'm going insane! I really hope someone can help me out. I have a wide area network spread across two service providers. I know I should have a domain controller on both sides of the network, but currently I only have one DC. Because of the blaster virus my upstream provider that the domain controller is on has blocked port 135. Now none of my servers outside of their ip range can logon to the domain. I get the RPC Server not available error. My upstream will not open port 135 for me, which I guess is understandable. But now I need to figure an alternative way to get my servers that are on a different ip range to be authorized by that domain controller. All options that go through port 135 I can't use. I am not very familiar with any other authentication options. Could anyone point me in the right direction? This is causing major problems. Thanks for any help!

More info. I have been researching this all day trying to figure a way to make this work. VPN is not an option because I have no IP addresses I could assign client computers that would connect. This has become a real mess. I have found that I can specify a specific port for RPC to use everytime on the domain controller so that port 135 doesn't have to be available to tell clients what port RPC is using. However I don't think there is a way to specify that port on the client side. Seems that clients HAVE to connect to port 135 to find out what port RPC is using. I'm going nuts over here. There has to be some kind of other way to simply verify the login information through active directory and allow computers to join the domain while avoiding port 135. Help me please!

I agree that there has to be a way to verify the login information through active directory, but I do not know what that is. But then I am no expert.

I have been thinking about your problem though, perhaps others have been as well.
I have a couple ideas... does the server have a modem? Could the clients call it directly and bypass the ISP alltogether?

My other idea would involve port forwarding. You said you can instruct the server to listen on an alternate port, but are unaware of how to change the port to which the clients call. Can you intercept the clients' calls to 135 and redirect them to the alternate port on the server? This could most easily be accomplished if most clients were behind the same firewall.

I've had major problems with ISPs blocking these ports as well. One of my clients has 20 locations. They connect back to an exchange server in the corporate office. When the client connects, it connect through port 135, then finds out what ports to use for connecting to the IS and DS. The main ISP we use (services all locations but 1), was an easy fix. I called them up, gave them a list of IPs, and modified their ACLs to permit that traffic through. The other ISP is PacBell. They just told me to bad, sucks to be you. I came up with a few ways to get around it. One was to try and modify the use of port 135. If you've found something different, please post it, because everything I cam across pointed to the fact that you cannot change this port successfully. The other option I had was to publish outlook to the sight via citrix, which would of been spendy as far as additional licenses. The third option, which I implemented successfully on Friday, was to setup a VPN connection. This might be your best solution. I setup pptp on each workstation, then I modified each users logon script to make the vpn connection at logon. It does create additional traffic, but pacbell did indicate that they won't keep those filters on indefinately. Anyway, now that traffic to port 135 is directed through the vpn tunnel, bypassing the filters.

If I were you, I would implement a vpn connection between those servers using Routing and Remote Access. It's fairly simple to setup (only takes a few minutes once you figure out how), and will get this fixed for you.

Anyway, hope this helps. Let me know what you did to fix it!

Thanks...

Cool. A VPN seems the obvious solution now. Got me thinking of other ways. Found a link that discusses ways to get AD through firewalls. They compare using a VPN and using IPSec to encapsulate the data. Either way seems ideal for your situation. And you get added security.

They also mention controlling RPC ports through the registry. You can't change the use of 135, however, you can only lock down to a single static port the dynamic ports allocated after the initial connection.

The link... http://www.microsoft.com/servicepro...psec_p63623.asp

They also list the ports you will need to open on your firewall for either a VPN or IPSec.

There may be other solutions that follow this logic.

And depending on your particular network, capturing port 135 traffic and forwarding it to port x, then capturing it again on the server side of the ISP and forwarding it back to 135 would still work I believe. It would require at minimum, one router on each side of the ISP.

I like your idea. The equipment on the small sites won't support it for me, but the cisco router at the corporate office would. If you have cisco equipment on both ends, it would be a great solution for you. Setup static Port Address Translation at both ends. Outbound from one site to translate port 135 traffic to 25000 or somethings, and on the other side, translate it back to 135. It should be a fairly easy translation to make...something similar to:

ip nat outside source static <outside ip> <new port> <inside ip> 135

and then reverse it on the other side using ip nat inside.

Anyway, I think it would work well. Wish I could implement it. None of the cheap routing equipment my customer uses has the ability to perform this.

Good luck.. Let me know how it turns out for you.