0

Summary: how do I create an RDC connection from a Windows 2008 server to another server?

Our client will only allow us to connect to their server via a static IP address (which is fair enough), but unfortunately as we're a very small company we don't have one in the office.

As a work around, we had the connection working through our old Windows 2003 server (dynamic-cloud from 1and1). .. however we have just rebuilt the server to run under Windows 2008 R2 (don't ask, but it was necessary), and now I simply cannot get the connection working.

  • I have added an "Outbound Rule" to Windows Firewall with Advanced Security (TCP, All local ports, 3389 remote port - I have also tried the other way around).

  • I have added a packet filter IP security rule with the same details.

  • The 1and1 firewall rules (through their online control panel) allows for 3389 TCP and UDP.

But it is simply not connecting (yes, the server is definitely on and able to accept connections) with the general error of...

Remote Desktop can’t connect to the remote computer for one of these reasons:
1) Remote access to the server is not enabled
2) The remote computer is turned off
3) The remote computer is not available on the network

Is there anything obvious I've missed - or something I can use to find out where the request is being blocked? The new server is using the exact same IP address as before, so I don't believe that would be an issue. Unless it's trying to use an IPv6 address rather than the old IPv4 address that it was before?

I apologise that I am not a network person by trade, but I know more than anybody else in my office!!


Edit

I have temporarily stopped the windows firewall (via netsh firewall set opmode disable) and IPSec (via net stop "ipsec policy agent"), but it still doesn't connect.

I'm running out of ideas


Edit 2

It would appear that I didn't disable the ipsec properly (or if I did, something must have automatically turned it back on).

If I disable (untick) the Block All option in IPSec, then the connection starts working. I've tried to find any documentation that states the order of precedence, but as I can see no way of reordering the security rules within the dialog, I have to presume that Permit overrides Block.

However, that still makes no sense to me, as I have specifically added a Permit for TCP 3389 which is not working. Argh, I hate computers!!


Edit 3

A friend of mine (who is a network administrator for a medium size company) has had a look at the configuration and is also at a loss to explain what is going on... I'm glad it's not just me!

His only thoughts on the matter are to do with the Kerberos authentication method, and whether that might be having an effect. Unfortunately he was unable to work out exactly how you would get around it without starting to use SSL certificates.

For the moment I am left in the situation where I have to temporarily disable the Block All rule in the list of IP Security rules - connect up to the client in question - and once finished, re-enable the block all. Not ideal in the slightest, but unless anybody else can come up with an answer, it's the only thing I've got.

(Another suggestion he came up with was completely removing the IPSec security, and instead just using the Windows Firewall. Is this a good idea?)

5
  • Can you ping the other server you are trying to reach? We do this on a Server 2008 R2 box, and it works ok - so it's def possible.
    – pierre
    Sep 17, 2012 at 9:23
  • @pierre, ping response is disabled on the client server (or more likely their network), so it's not possible even from my development machine, let alone the hosted server... but nice thought
    – freefaller
    Sep 17, 2012 at 9:27
  • I suppose that remote desktop is enabled on the remote server?
    – tombull89
    Sep 17, 2012 at 9:32
  • @tombull89, yes, this was all working correctly on the Windows 2003 server before the update, and I have also attempted to connect to a different server that doesn't have any IP restrictions without success. The new 2008 R2 installation is running under the exact same IPv4 address as before.
    – freefaller
    Sep 17, 2012 at 9:35
  • @Pierre, you say you have this working on one of your 2008 R2 boxes... would it be possible for you to see what IPSec rules are there for port 3389, and in particular what authentication those rules are running under? (This is in light of my "Edit 3" in the original question) Many thanks
    – freefaller
    Sep 17, 2012 at 15:43

2 Answers 2

1

To answer my own question... I have simply not found out the reason why the IPSec is blocking the RDC (and I later found also the FTP). I have gone through every setting I have think of so many times I have lost count - but they all look fine.

I have now disabled (unticked) the Block All item in the IPSec, and things are now working as expected.

Whether this is a security hole I have just opened up, I'm really not sure. Or whether there is any point having IPSec enabled at all if the Block All is disabled.

But as Windows Firewall with Advanced Security is setup and running, and the firewall setup on the 1and1 control panel is also there, I'm hoping there is enough there to provide a good level of protection.

2
  • 1
    Why did you have IPSec running in the first place?
    – Chris S
    Sep 21, 2012 at 14:10
  • It's a good question @Chris, and it's simply because it comes already configured on the instance provided by 1and1 when you "reimage" the server. As I said in my question, I am not a network guru (I'm a programmer in a very very small company, and know more about networks that anybody else), and therefore assumed as it was already on the box it needed to be left on the box. Would you consider it "safe" to disable IPSec completely?
    – freefaller
    Sep 21, 2012 at 14:15
0

The first thing you should do is perform a traceroute your client's server, to determine that packets are indeed getting out of the network owned by the company hosting your cloud server you are trying to connect from.

Unfortunately, because your client has decided to block ICMP Echo, it's going to be difficult to diagnose where the problem lies.

Does your client have their own admins? If so, once you've established packets are getting to (or close to) their network, you should speak with them.

3
  • Can you give more information about traceroute? It doesn't appear to be a recognised utility through the start menu search or command line
    – freefaller
    Sep 17, 2012 at 11:24
  • From windows server command prompt, tracert 1.2.3.4, obviously put the IP of your client's server in place of 1.2.3.4.
    – Bryan
    Sep 17, 2012 at 11:25
  • I think I've just had a bit of a break-through, and it looks like a problem with the IPSec configuration... thanks for your help though
    – freefaller
    Sep 17, 2012 at 11:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .