RDP Port Access via Internet - [WP]

[WildPacket]

Windows 2008 TSweb,TSG, TS all running on the same server..

I have opened RDP and HTTPS port on the firewall to access my apps via
TSWebAccess from Internet. Works fien no issues so far ....

Using the WAN side IP if I RDP into my server across the internet it hits
straight to my Win2008 Server where TSWeb and TSGateway is running.

Just want to confirm that I need to open RDP port in my firwall - correct???

I know we can use a different port number in the firewall, TServer Gateway
etc.

Is there some other way ..so nobody can use RDP and hit my server if they
grab my wan IP?

Advise Please.

Thanks

 

[Rob Leitman [MSFT]]

"WildPacket" wrote in message
news:338B8CE0-D183-46AF-81DE-D81B3F9FC583@microsoft.com...
> Windows 2008 TSweb,TSG, TS all running on the same server..
>
> I have opened RDP and HTTPS port on the firewall to access my apps via
> TSWebAccess from Internet. Works fien no issues so far ....
>
> Using the WAN side IP if I RDP into my server across the internet it hits
> straight to my Win2008 Server where TSWeb and TSGateway is running.
>
> Just want to confirm that I need to open RDP port in my firwall -
> correct???
>
> I know we can use a different port number in the firewall, TServer Gateway
> etc.
>
> Is there some other way ..so nobody can use RDP and hit my server if they
> grab my wan IP?

If you're using TS Gateway, there's no need to open the RDP port in the
firewall. All traffic goes over HTTPS.

Rob

 

[WildPacket]

Rob .. thanks.

we are testing an app via
https://terminalserver.ourdomain.com/ts
and it works fine ...

If I turn rdp port off in the firewall ... the users dont connect?????

Why is that then ... or something is misconfigured..?

ts, tsweb, tsgateway, application and tslicense all on this one server.








"Rob Leitman [MSFT]" wrote:

>
> "WildPacket" wrote in message
> news:338B8CE0-D183-46AF-81DE-D81B3F9FC583@microsoft.com...
> > Windows 2008 TSweb,TSG, TS all running on the same server..
> >
> > I have opened RDP and HTTPS port on the firewall to access my apps via
> > TSWebAccess from Internet. Works fien no issues so far ....
> >
> > Using the WAN side IP if I RDP into my server across the internet it hits
> > straight to my Win2008 Server where TSWeb and TSGateway is running.
> >
> > Just want to confirm that I need to open RDP port in my firwall -
> > correct???
> >
> > I know we can use a different port number in the firewall, TServer Gateway
> > etc.
> >
> > Is there some other way ..so nobody can use RDP and hit my server if they
> > grab my wan IP?
>
> If you're using TS Gateway, there's no need to open the RDP port in the
> firewall. All traffic goes over HTTPS.
>
> Rob
>
>
>

 

[Rob Leitman [MSFT]]

"WildPacket" wrote in message
news:9C937305-38C3-4A88-A6E3-BAB9CAA86A39@microsoft.com...
> Rob .. thanks.
>
> we are testing an app via
> https://terminalserver.ourdomain.com/ts
> and it works fine ...
>
> If I turn rdp port off in the firewall ... the users dont connect?????
>
> Why is that then ... or something is misconfigured..?
>
> ts, tsweb, tsgateway, application and tslicense all on this one server.

Did you set the Deployment Settings in RemoteApp Manager to have the
RemoteApps use TS Gateway? If not, they won't use it, and will try to
connect via RDP (3389).

Rob

 

[WildPacket]

Rob Thanks.

"I THINK" I did. Let me run it by you .....

On the TS Remoteapp Manger Properties -> Under TSGateway tab in the server
name field I have the same name as the CN on the certificate ...???

And on the Terminal Server tab in the server name field I have the same name
as the CN on the certificate

Is that right????

Thanks,







"Rob Leitman [MSFT]" wrote:

>
> "WildPacket" wrote in message
> news:9C937305-38C3-4A88-A6E3-BAB9CAA86A39@microsoft.com...
> > Rob .. thanks.
> >
> > we are testing an app via
> > https://terminalserver.ourdomain.com/ts
> > and it works fine ...
> >
> > If I turn rdp port off in the firewall ... the users dont connect?????
> >
> > Why is that then ... or something is misconfigured..?
> >
> > ts, tsweb, tsgateway, application and tslicense all on this one server.
>
> Did you set the Deployment Settings in RemoteApp Manager to have the
> RemoteApps use TS Gateway? If not, they won't use it, and will try to
> connect via RDP (3389).
>
> Rob
>
>
>

 

[Rob Leitman [MSFT]]

"WildPacket" wrote in message
news:AC250A34-B5BC-4F8D-B02D-DBE04C82A34A@microsoft.com...
> Rob Thanks.
>
> "I THINK" I did. Let me run it by you .....
>
> On the TS Remoteapp Manger Properties -> Under TSGateway tab in the server
> name field I have the same name as the CN on the certificate ...???
>
> And on the Terminal Server tab in the server name field I have the same
> name
> as the CN on the certificate
>
> Is that right????

Is the radio button on "Use these TS Gateway server settings"? Did you try
unchecking "Bypass TS Gateway server for local addresses"?

Rob

 

[WildPacket]

Yes ...tried that.

There are 2 NICs in the server ...
one on wan side and one on lan side ...could this be causing issue???





"Rob Leitman [MSFT]" wrote:

>
> "WildPacket" wrote in message
> news:AC250A34-B5BC-4F8D-B02D-DBE04C82A34A@microsoft.com...
> > Rob Thanks.
> >
> > "I THINK" I did. Let me run it by you .....
> >
> > On the TS Remoteapp Manger Properties -> Under TSGateway tab in the server
> > name field I have the same name as the CN on the certificate ...???
> >
> > And on the Terminal Server tab in the server name field I have the same
> > name
> > as the CN on the certificate
> >
> > Is that right????
>
> Is the radio button on "Use these TS Gateway server settings"? Did you try
> unchecking "Bypass TS Gateway server for local addresses"?
>
> Rob
>
>
>

 

[Rob Leitman [MSFT]]

"WildPacket" wrote in message
news:6DB445B8-9280-468A-B5E4-F422E42A7215@microsoft.com...
> Yes ...tried that.
>
> There are 2 NICs in the server ...
> one on wan side and one on lan side ...could this be causing issue???

There's no reason for the client to use RDP. Can you View Source in the
browser and tell me what the RDP file in there looks like? It will be
encoded, but still readable.

Rob

 

[WildPacket]

Rob: Thanks I will look at the code and let you know.

Spent 5 hours with Microsoft tech support and they are still not able to fix
this ... will continue working again with them today ...

They seem to be concerned about the machine name not matching the CN name on
the certificate .... but they are were not 100%.

My internal machine name is:
TERMINAL001.domain.local

And CN on the cert:
Terminal.domain.com

but it works fine ....as long as the RDP is opened... so I think its nothing
to do with the names here in my situation ....








"Rob Leitman [MSFT]" wrote:

>
> "WildPacket" wrote in message
> news:6DB445B8-9280-468A-B5E4-F422E42A7215@microsoft.com...
> > Yes ...tried that.
> >
> > There are 2 NICs in the server ...
> > one on wan side and one on lan side ...could this be causing issue???
>
> There's no reason for the client to use RDP. Can you View Source in the
> browser and tell me what the RDP file in there looks like? It will be
> encoded, but still readable.
>
> Rob
>
>
>

 

[WildPacket]

What should be I looking for in the source code???






"Rob Leitman [MSFT]" wrote:

>
> "WildPacket" wrote in message
> news:6DB445B8-9280-468A-B5E4-F422E42A7215@microsoft.com...
> > Yes ...tried that.
> >
> > There are 2 NICs in the server ...
> > one on wan side and one on lan side ...could this be causing issue???
>
> There's no reason for the client to use RDP. Can you View Source in the
> browser and tell me what the RDP file in there looks like? It will be
> encoded, but still readable.
>
> Rob
>
>
>

 

[TP]

WP,

The TSGateway server name needs to be resolvable from the
*client* machine, whereas the Terminal Server name must
be resolvable from the *TSGateway* machine. If the TS
is on the same local LAN as your TSG, then the TS name
should resolve to a *local* ip address (eg 192.168.1.x) from
the perspective of the TSG.

Example connection:

1. First the client attempts to connect to the TS Gateway using
the TS Gateway name you provided--it finds the name and
connects via port 443

2. Second the TS Gateway attempts to connect to your TS
Server using the TS Server name provided via port 3389

I think it is the second step which is failing (if 3389 is blocked),
because the CN may not be resolvable to the correct *internal*
ip address.

The short answer is you should either change your internal
DNS so that the CN will resolve to the internal ip address of
your TS when on the LAN, -or- change the TS server name
to the internal server name.

Thanks.

-TP

WildPacket wrote:
> Rob Thanks.
>
> "I THINK" I did. Let me run it by you .....
>
> On the TS Remoteapp Manger Properties -> Under TSGateway tab in the
> server name field I have the same name as the CN on the certificate
> ...???
>
> And on the Terminal Server tab in the server name field I have the
> same name as the CN on the certificate
>
> Is that right????
>
> Thanks,

 

[WildPacket]

TP thanks for your input ....

Changing the internal DNS name to resolve the CN is a big job?

I ahve tried to change the TS Server name to internal name it still no
workie ......

Waht about UCC Certificates ... I heard we can mentioned both the CN name
and the internal Server name in that cert and that will work?????

Thanks adivse Please.









"TP" wrote:

> WP,
>
> The TSGateway server name needs to be resolvable from the
> *client* machine, whereas the Terminal Server name must
> be resolvable from the *TSGateway* machine. If the TS
> is on the same local LAN as your TSG, then the TS name
> should resolve to a *local* ip address (eg 192.168.1.x) from
> the perspective of the TSG.
>
> Example connection:
>
> 1. First the client attempts to connect to the TS Gateway using
> the TS Gateway name you provided--it finds the name and
> connects via port 443
>
> 2. Second the TS Gateway attempts to connect to your TS
> Server using the TS Server name provided via port 3389
>
> I think it is the second step which is failing (if 3389 is blocked),
> because the CN may not be resolvable to the correct *internal*
> ip address.
>
> The short answer is you should either change your internal
> DNS so that the CN will resolve to the internal ip address of
> your TS when on the LAN, -or- change the TS server name
> to the internal server name.
>
> Thanks.
>
> -TP
>
> WildPacket wrote:
> > Rob Thanks.
> >
> > "I THINK" I did. Let me run it by you .....
> >
> > On the TS Remoteapp Manger Properties -> Under TSGateway tab in the
> > server name field I have the same name as the CN on the certificate
> > ...???
> >
> > And on the Terminal Server tab in the server name field I have the
> > same name as the CN on the certificate
> >
> > Is that right????
> >
> > Thanks,
>

 

[WildPacket]

TP:

The TSG, TServer, RemoteApp all on this one server in the same LAN ....and
TS License server also on this server




"TP" wrote:

> WP,
>
> The TSGateway server name needs to be resolvable from the
> *client* machine, whereas the Terminal Server name must
> be resolvable from the *TSGateway* machine. If the TS
> is on the same local LAN as your TSG, then the TS name
> should resolve to a *local* ip address (eg 192.168.1.x) from
> the perspective of the TSG.
>
> Example connection:
>
> 1. First the client attempts to connect to the TS Gateway using
> the TS Gateway name you provided--it finds the name and
> connects via port 443
>
> 2. Second the TS Gateway attempts to connect to your TS
> Server using the TS Server name provided via port 3389
>
> I think it is the second step which is failing (if 3389 is blocked),
> because the CN may not be resolvable to the correct *internal*
> ip address.
>
> The short answer is you should either change your internal
> DNS so that the CN will resolve to the internal ip address of
> your TS when on the LAN, -or- change the TS server name
> to the internal server name.
>
> Thanks.
>
> -TP
>
> WildPacket wrote:
> > Rob Thanks.
> >
> > "I THINK" I did. Let me run it by you .....
> >
> > On the TS Remoteapp Manger Properties -> Under TSGateway tab in the
> > server name field I have the same name as the CN on the certificate
> > ...???
> >
> > And on the Terminal Server tab in the server name field I have the
> > same name as the CN on the certificate
> >
> > Is that right????
> >
> > Thanks,
>

 

[Wayne Tilton]

"TP" wrote in news:u4Be#Q3QKHA.4028
@TK2MSFTNGP05.phx.gbl:

> WP,
>
> The TSGateway server name needs to be resolvable from the
> *client* machine, whereas the Terminal Server name must
> be resolvable from the *TSGateway* machine. If the TS
> is on the same local LAN as your TSG, then the TS name
> should resolve to a *local* ip address (eg 192.168.1.x) from
> the perspective of the TSG.
>
> Example connection:
>
> 1. First the client attempts to connect to the TS Gateway using
> the TS Gateway name you provided--it finds the name and
> connects via port 443
>
> 2. Second the TS Gateway attempts to connect to your TS
> Server using the TS Server name provided via port 3389
>
> I think it is the second step which is failing (if 3389 is blocked),
> because the CN may not be resolvable to the correct *internal*
> ip address.
>
> The short answer is you should either change your internal
> DNS so that the CN will resolve to the internal ip address of
> your TS when on the LAN, -or- change the TS server name
> to the internal server name.
>
> Thanks.
>
> -TP
>
> WildPacket wrote:
>> Rob Thanks.
>>
>> "I THINK" I did. Let me run it by you .....
>>
>> On the TS Remoteapp Manger Properties -> Under TSGateway tab in the
>> server name field I have the same name as the CN on the certificate
>> ...???
>>
>> And on the Terminal Server tab in the server name field I have the
>> same name as the CN on the certificate
>>
>> Is that right????
>>
>> Thanks,

I set this up in a lab recently and the way I got it to work was to use
the FQDN of the TS Gateway (e.g. tsgateway.mydomain.com) on the "Connect
from anywhere" tab under Advance and the NetBIOS name of the target
system in the 'Computer' field of the General tab.

This causes the initial connect to the TS Gateway to work by resolving
the external over the internet using DNS and the connection to the actual
target server resolves by NetBIOS on the internal network.

HTH,

Wayne Tilton

 

[WildPacket]

Thanks all for your participation ....

Got it going... had to use a UCC Certificate.





"Wayne Tilton" wrote:

> "TP" wrote in news:u4Be#Q3QKHA.4028
> @TK2MSFTNGP05.phx.gbl:
>
> > WP,
> >
> > The TSGateway server name needs to be resolvable from the
> > *client* machine, whereas the Terminal Server name must
> > be resolvable from the *TSGateway* machine. If the TS
> > is on the same local LAN as your TSG, then the TS name
> > should resolve to a *local* ip address (eg 192.168.1.x) from
> > the perspective of the TSG.
> >
> > Example connection:
> >
> > 1. First the client attempts to connect to the TS Gateway using
> > the TS Gateway name you provided--it finds the name and
> > connects via port 443
> >
> > 2. Second the TS Gateway attempts to connect to your TS
> > Server using the TS Server name provided via port 3389
> >
> > I think it is the second step which is failing (if 3389 is blocked),
> > because the CN may not be resolvable to the correct *internal*
> > ip address.
> >
> > The short answer is you should either change your internal
> > DNS so that the CN will resolve to the internal ip address of
> > your TS when on the LAN, -or- change the TS server name
> > to the internal server name.
> >
> > Thanks.
> >
> > -TP
> >
> > WildPacket wrote:
> >> Rob Thanks.
> >>
> >> "I THINK" I did. Let me run it by you .....
> >>
> >> On the TS Remoteapp Manger Properties -> Under TSGateway tab in the
> >> server name field I have the same name as the CN on the certificate
> >> ...???
> >>
> >> And on the Terminal Server tab in the server name field I have the
> >> same name as the CN on the certificate
> >>
> >> Is that right????
> >>
> >> Thanks,
>
> I set this up in a lab recently and the way I got it to work was to use
> the FQDN of the TS Gateway (e.g. tsgateway.mydomain.com) on the "Connect
> from anywhere" tab under Advance and the NetBIOS name of the target
> system in the 'Computer' field of the General tab.
>
> This causes the initial connect to the TS Gateway to work by resolving
> the external over the internet using DNS and the connection to the actual
> target server resolves by NetBIOS on the internal network.
>
> HTH,
>
> Wayne Tilton
>