RDP from LAN but not from external addresses

  • Thread starter Thread starter Roger Vicker
  • Start date Start date
R

Roger Vicker

Guest
We had set up a W2K8 server (the only server in the organization) with User
CALs and everything was working fine inside and outside.

Just as we were rolling it out to the remote and roaming users it stopped
working.

Users on the local, to the server, network can still fully use RDP.

Outside users get to the server's full screen logon but no matter what
user/password they use they get a "The user name or password is invalid."
error. Same user/password works via the local network.

The event log was showing a 1004 id but a hot fix stopped that as MS
indicated it was a false event that led to useless investigation.

This started right in the middle of the day. A user was connected,
disconnected and rebooted to install a .NET update and from then on none of
the RDP users could get logged on unless they were on the local network.

The firewall isn't blocking the port as they are getting to the server's
logon screen.

What has changed?

How do we get the outside users to get fully logged in again?

Thanks.
 
Re: RDP from LAN but not from external addresses

An end user installed a .net update? That's not good.

Does the firewall show any traffic going to the server? Can you telnet,
ping, etc to the server (opening up proper communication of course). If
you remove the .net update, does it start to work?

Jeff Pitsch
Microsoft MVP - Terminal Services

Roger Vicker wrote:
> We had set up a W2K8 server (the only server in the organization) with User
> CALs and everything was working fine inside and outside.
>
> Just as we were rolling it out to the remote and roaming users it stopped
> working.
>
> Users on the local, to the server, network can still fully use RDP.
>
> Outside users get to the server's full screen logon but no matter what
> user/password they use they get a "The user name or password is invalid."
> error. Same user/password works via the local network.
>
> The event log was showing a 1004 id but a hot fix stopped that as MS
> indicated it was a false event that led to useless investigation.
>
> This started right in the middle of the day. A user was connected,
> disconnected and rebooted to install a .NET update and from then on none of
> the RDP users could get logged on unless they were on the local network.
>
> The firewall isn't blocking the port as they are getting to the server's
> logon screen.
>
> What has changed?
>
> How do we get the outside users to get fully logged in again?
>
> Thanks.
 
Re: RDP from LAN but not from external addresses



"Jeff Pitsch" wrote:

> An end user installed a .net update? That's not good.
>
> Does the firewall show any traffic going to the server? Can you telnet,
> ping, etc to the server (opening up proper communication of course). If
> you remove the .net update, does it start to work?
>
> Jeff Pitsch
> Microsoft MVP - Terminal Services
>


The .NET update is needed for the new printer driver support of Server 2008.
I actually included it on the CD for them to install in case MS Update hadn't
already.

Please re-read OP. Basic communications is working as they are getting to
the server to get its logon display. You know, the one with the blue
background, icons for last user, Other User, Smart Card and says Windows 2008
at the bottom, looks entirely different from Windows 2003... Also, it is
affecting all external users, not just the last one to try.
 
Re: RDP from LAN but not from external addresses

Woops, wrong part to the wrong post. Sorry about that.

The NAT is still valid? It didn't get changed? Are there any errors in
the event logs when they try to login? Have you at least tried to
remove the update to see if it fixes the situation? Are they coming in
through TSWeb/TSGateway (i would assume yes for securities sake because
no one likes to have their internal network exposed to everybody but you
know what they say about assuming)?

It is never, ever a good idea to have users install an update. If the
server is ever put into install mode, it can completely corrupt the
shadow key if not worse. The administrator should always make sure the
proper updates are in place before the system is available to the users.



Jeff Pitsch
Microsoft MVP - Terminal Services

Roger Vicker wrote:
>
> "Jeff Pitsch" wrote:
>
>> An end user installed a .net update? That's not good.
>>
>> Does the firewall show any traffic going to the server? Can you telnet,
>> ping, etc to the server (opening up proper communication of course). If
>> you remove the .net update, does it start to work?
>>
>> Jeff Pitsch
>> Microsoft MVP - Terminal Services
>>

>
> The .NET update is needed for the new printer driver support of Server 2008.
> I actually included it on the CD for them to install in case MS Update hadn't
> already.
>
> Please re-read OP. Basic communications is working as they are getting to
> the server to get its logon display. You know, the one with the blue
> background, icons for last user, Other User, Smart Card and says Windows 2008
> at the bottom, looks entirely different from Windows 2003... Also, it is
> affecting all external users, not just the last one to try.
 
Re: RDP from LAN but not from external addresses



"Jeff Pitsch" wrote:

> Woops, wrong part to the wrong post. Sorry about that.
>
> The NAT is still valid? It didn't get changed? Are there any errors in
> the event logs when they try to login? Have you at least tried to
> remove the update to see if it fixes the situation? Are they coming in
> through TSWeb/TSGateway (i would assume yes for securities sake because
> no one likes to have their internal network exposed to everybody but you
> know what they say about assuming)?
>
> It is never, ever a good idea to have users install an update. If the
> server is ever put into install mode, it can completely corrupt the
> shadow key if not worse. The administrator should always make sure the
> proper updates are in place before the system is available to the users.
>
>
>
> Jeff Pitsch
> Microsoft MVP - Terminal Services
>

1) NAT is working as THEY ARE GETTING THE LOGON SCREEN FROM THE SERVER.

2) There were ID 1004 errors in the logs but a MS Hotfix stopped them as it
stated they were coming from a false condition. Nothing about TS since then.

3) I haven't removed the update as the problem is affecting other machines
that were working and had the update long before things stopped working.

4) They are coming in via the RDP port being mapped in the firewall to the
server. Using the RDP client 6.1. This is not TSWeb at this stage and there
is no TSGateway. I said that there is ONLY ONE SERVER total.

5) The update was applied to the USER'S PC. Users have no special rights on
the server. The update was just why the user disconnected and then minutes
later tried to reconnect. I mentioned it to show that there wasn't an
overnight, reboot, server change between it working and not working.

The .NET Framework update did not cause the problem because:

1) It was applied to only one CLIENT PC. The others already had it applied
via MS Update some time ago.

2) The problem is blocking ALL CLIENTS OUTSIDE THE FIREWALL.

3) Clients inside the firewall can connect and work using the exact same
user/password as those trying from outside the firewall.

4) Probable indication that it is not the problem is that I can logon using
the same client PC to a server running 2003 SBS on an entirely different
network but not this server.

The firewall is not causing this unless TS suddenly requires something other
than the RDP port being open/mapped. REPEAT: The client is connecting to the
server, the server is just rejecting the user/password when the connection is
coming from outside the firewall but accepting it when coming from inside the
firewall. We are not talking about the user name/credentials that can be
stored with the .RDP file. The .RDP file has the user name left blank and
there is no check mark for "Allow me to save credentials"

Rebooting the server didn't clear the problem but 72+ hours seems to have.
However, the client disk drives don't show in Explorer despite the .RDP being
checked and the GPO doesn't say to disallow it. Also, printing to the client
printers never produces anything and there are no errors. They are via the
new TS Easy Print drivers.
 
Re: RDP from LAN but not from external addresses

=?Utf-8?B?Um9nZXIgVmlja2Vy?=
<RogerVicker@discussions.microsoft.com> wrote on 21 sep 2008 in
microsoft.public.windows.terminal_services:

> 1) NAT is working as THEY ARE GETTING THE LOGON SCREEN FROM THE
> SERVER.
>
> 2) There were ID 1004 errors in the logs but a MS Hotfix stopped
> them as it stated they were coming from a false condition.
> Nothing about TS since then.
>
> 3) I haven't removed the update as the problem is affecting
> other machines that were working and had the update long before
> things stopped working.
>
> 4) They are coming in via the RDP port being mapped in the
> firewall to the server. Using the RDP client 6.1. This is not
> TSWeb at this stage and there is no TSGateway. I said that there
> is ONLY ONE SERVER total.
>
> 5) The update was applied to the USER'S PC. Users have no
> special rights on the server. The update was just why the user
> disconnected and then minutes later tried to reconnect. I
> mentioned it to show that there wasn't an overnight, reboot,
> server change between it working and not working.
>
> The .NET Framework update did not cause the problem because:
>
> 1) It was applied to only one CLIENT PC. The others already had
> it applied via MS Update some time ago.
>
> 2) The problem is blocking ALL CLIENTS OUTSIDE THE FIREWALL.
>
> 3) Clients inside the firewall can connect and work using the
> exact same user/password as those trying from outside the
> firewall.
>
> 4) Probable indication that it is not the problem is that I can
> logon using the same client PC to a server running 2003 SBS on
> an entirely different network but not this server.
>
> The firewall is not causing this unless TS suddenly requires
> something other than the RDP port being open/mapped. REPEAT: The
> client is connecting to the server, the server is just rejecting
> the user/password when the connection is coming from outside the
> firewall but accepting it when coming from inside the firewall.
> We are not talking about the user name/credentials that can be
> stored with the .RDP file. The .RDP file has the user name left
> blank and there is no check mark for "Allow me to save
> credentials"
>
> Rebooting the server didn't clear the problem but 72+ hours
> seems to have. However, the client disk drives don't show in
> Explorer despite the .RDP being checked and the GPO doesn't say
> to disallow it. Also, printing to the client printers never
> produces anything and there are no errors. They are via the new
> TS Easy Print drivers.


Roger, when you say that there is only a single server, do you mean
that the TS is a standalone server in a workgroup, and the users
have local user accounts on the TS, or is there a DC and the TS is
a member of AD?
Is Single Sign-On enabled on the server?

_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___
 
Re: RDP from LAN but not from external addresses

My point on the NAT was that it could have been changed and it was
pointed at a different server. Also, you can run all 3 roles on the
same server so yes, TSWeb/TSGateway could be installed and you still
only have one server.

And this information you provided in this post is much more detailed
than previously and explains the situation much better. Thank you.

Jeff Pitsch
Microsoft MVP - Terminal Services

Roger Vicker wrote:
>
> "Jeff Pitsch" wrote:
>
>> Woops, wrong part to the wrong post. Sorry about that.
>>
>> The NAT is still valid? It didn't get changed? Are there any errors in
>> the event logs when they try to login? Have you at least tried to
>> remove the update to see if it fixes the situation? Are they coming in
>> through TSWeb/TSGateway (i would assume yes for securities sake because
>> no one likes to have their internal network exposed to everybody but you
>> know what they say about assuming)?
>>
>> It is never, ever a good idea to have users install an update. If the
>> server is ever put into install mode, it can completely corrupt the
>> shadow key if not worse. The administrator should always make sure the
>> proper updates are in place before the system is available to the users.
>>
>>
>>
>> Jeff Pitsch
>> Microsoft MVP - Terminal Services
>>

> 1) NAT is working as THEY ARE GETTING THE LOGON SCREEN FROM THE SERVER.
>
> 2) There were ID 1004 errors in the logs but a MS Hotfix stopped them as it
> stated they were coming from a false condition. Nothing about TS since then.
>
> 3) I haven't removed the update as the problem is affecting other machines
> that were working and had the update long before things stopped working.
>
> 4) They are coming in via the RDP port being mapped in the firewall to the
> server. Using the RDP client 6.1. This is not TSWeb at this stage and there
> is no TSGateway. I said that there is ONLY ONE SERVER total.
>
> 5) The update was applied to the USER'S PC. Users have no special rights on
> the server. The update was just why the user disconnected and then minutes
> later tried to reconnect. I mentioned it to show that there wasn't an
> overnight, reboot, server change between it working and not working.
>
> The .NET Framework update did not cause the problem because:
>
> 1) It was applied to only one CLIENT PC. The others already had it applied
> via MS Update some time ago.
>
> 2) The problem is blocking ALL CLIENTS OUTSIDE THE FIREWALL.
>
> 3) Clients inside the firewall can connect and work using the exact same
> user/password as those trying from outside the firewall.
>
> 4) Probable indication that it is not the problem is that I can logon using
> the same client PC to a server running 2003 SBS on an entirely different
> network but not this server.
>
> The firewall is not causing this unless TS suddenly requires something other
> than the RDP port being open/mapped. REPEAT: The client is connecting to the
> server, the server is just rejecting the user/password when the connection is
> coming from outside the firewall but accepting it when coming from inside the
> firewall. We are not talking about the user name/credentials that can be
> stored with the .RDP file. The .RDP file has the user name left blank and
> there is no check mark for "Allow me to save credentials"
>
> Rebooting the server didn't clear the problem but 72+ hours seems to have.
> However, the client disk drives don't show in Explorer despite the .RDP being
> checked and the GPO doesn't say to disallow it. Also, printing to the client
> printers never produces anything and there are no errors. They are via the
> new TS Easy Print drivers.
>
 
Re: RDP from LAN but not from external addresses



"Vera Noest [MVP]" wrote:


>
> Roger, when you say that there is only a single server, do you mean
> that the TS is a standalone server in a workgroup, and the users
> have local user accounts on the TS, or is there a DC and the TS is
> a member of AD?
> Is Single Sign-On enabled on the server?
>
> _________________________________________________________
> Vera Noest
> MCSE, CCEA, Microsoft MVP - Terminal Server
> TS troubleshooting: http://ts.veranoest.net
> ___ please respond in newsgroup, NOT by private email ___
>


Single server as it it is the only system running server OS and is
everything, DC, TS, App server, file server...

Single Sign On is not in use.
 
Re: RDP from LAN but not from external addresses

=?Utf-8?B?Um9nZXIgVmlja2Vy?=
<RogerVicker@discussions.microsoft.com> wrote on 21 sep 2008 in
microsoft.public.windows.terminal_services:

> "Vera Noest [MVP]" wrote:
>>
>> Roger, when you say that there is only a single server, do you
>> mean that the TS is a standalone server in a workgroup, and the
>> users have local user accounts on the TS, or is there a DC and
>> the TS is a member of AD?
>> Is Single Sign-On enabled on the server?

>
> Single server as it it is the only system running server OS and
> is everything, DC, TS, App server, file server...
>
> Single Sign On is not in use.


OK, running TS on a DC is *not* recommended, for obvious security
reasons, but it shouldn't cause the problems you mention.
However, you should keep in mind that users could have modified all
kinds of things, and double-check all settings which you believe to
be in effect to see if they are still as you configured them.

You wrote in an earlier post:

>> Rebooting the server didn't clear the problem but 72+ hours
>> seems to have.


OK, so outside users *can* logon now?
Sounds really weird. I would investigate these areas:
* check the logs on the firewall to see if some traffic was
rejected
* maybe there was a problem with Kerberos authentication?

>> However, the client disk drives don't show in
>> Explorer despite the .RDP being checked and the GPO doesn't say
>> to disallow it. Also, printing to the client printers never
>> produces anything and there are no errors.


These problems could indicate that GPOs are not applied as they
should. I'd enable verbose logging of the user environment, and
compare remote and local user logon processes.

221833 - How to enable user environment debug logging in retail
builds of Windows
http://support.microsoft.com/?kbid=221833

_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___
 
Back
Top