• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1007
  • Last Modified:

Cannot Remote Desktop Server after move to DMZ

Hello Experts,

I have just rebuilt a server giving it a new name and moved it into our DMZ.  I have added it's address to our DMZ in our PIX.

Now when I try to ping it or connect with Remote Desktop Connection I can't get through to it from our internal network.  However I can get to it from our ISA server.  I have run a log in ISA for all traffic to the servers IP address and it shows excatly the same allowed rule for a sucessful attempt to another server in the DMZ as an unsuccessful one to the new server in the DMZ.

When I run a tracert from inside the internal network it shows the ping reaching the ISA Server then nothing but if I tracert from the ISA Server then it finds the new server.

Does anyone know why I can't get to the new server from inside our network?

Thank you
Tom
0
TomMonkey
Asked:
TomMonkey
1 Solution
 
KCTSCommented:
Make sure that your firewall allows TCP port 3389.
0
 
TomMonkeyAuthor Commented:
As far as I know as all the other Servers in the DNZ are contactable on 3389.  The new server was added to the DMZ in the hosts/networks and has all the same properties as the other.

Sorry I'm a little new to our PIX.
0
 
SagiEDocCommented:
Add a rule on the ISA server to allow TCP on port 3389. Obviously you do have a rule like this already for the other servers to work, but the new servers ip address is falling out of the scope of this rule, you could just change the scope so that the new servers ip is included.
0
Get quick recovery of individual SharePoint items

Free tool – Veeam Explorer for Microsoft SharePoint, enables fast, easy restores of SharePoint sites, documents, libraries and lists — all with no agents to manage and no additional licenses to buy.

 
TomMonkeyAuthor Commented:
But the new server's IP is in the range allowed through on the ISA.  Also when I run monitoring on ISA to check it it shows the connection to port 3389 from my computer as allowed.

I'm not sure at what stage the connection is getting blocked.  I thought ISA at first because the ISA server it's self could get through. But the monitoring shows the same allowed connection to the new server as an existing one.

Very confusing.
0
 
Keith AlabasterCommented:
Tom,

What version of ISA server are you running? I'll assume its 2004 or 2006 as ISA2000 is out of mainstream support now.

what do you mean by 'DMZ'? Have you added a 3rd nic to ISA server to create a perimeter network or is this the 'space' between the ISA external nic and the PIX internal nic?

Assuming it is in a 3rd nic, what ip addresses have you placed on that nic (in the isa gui - configuration - networks - perimeter (properties) - addresses? Does this include the new servers ip?

Are you natting between the perimeter network and the external network or routing between them?
Have you published the rdp service on the perimeter network to the external interface?

0
 
lrmooreCommented:
Can you post PIX config?
0
 
TomMonkeyAuthor Commented:
Keith,

Sorry for not responding earlier, I was away this weekend.

It is ISA 2004.  Our DMZ is the area outside of ISA but inside our PIX.

We have an extrnal connection coming into our PIX.  Several servers connect directly into the PIX.  One of them has ISA running.  A switch connects to a second nic on this server.  Our internal network connects to this switch.

The new servers IP address is in the range of IP's in the Perimeter/DMZ list in the ISA configuration/networks.

The RDP service is allowed between Internal network and Perimeter/DNZ.

Irmoore,

Not sure I'm allowed to put the setting to our firewall on here. Sorry.
0
 
TomMonkeyAuthor Commented:
Sorry, didn't answer one question:

We route to the DMZ/Permeter from internal, not NAT.

Cheers
0
 
TomMonkeyAuthor Commented:
Problem solved.  My fault.  The new server rebuild did not have a persistant route.  This was found by using route print.  Added one using route add -p ...

Cheers guys.
0
 
Vee_ModCommented:
Closed, 500 points refunded.
Vee_Mod
Community Support Moderator
0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now