none
Connecting to RD Web Access from a network that blocks outbound access to port 3389

    Question

  • I have a server farm setup and when i connect from an external location the traffic is handed off to the client over port 3389, how do i fix this?

    Information on Setup:

    Server1: Network Policy and Access Services, Remote Desktop services, IIS Web Services (Gateway Server)

    Remote Desktop Connection = Digital cert from verisign installed

    Remote app sources = Server Farm name that points to the 2 session hosts in DNS (something.domainname=server1 IP,server2 IP)

    Under session host server it says it is configured for remote desktop for administration

    In IIS the server certificate installed is the same Digital cert from verisign.

     

    Servers 2,3: Remote Desktop Services, IIS Web Services (Session hosts, which are part of a server farm)

    Remote app manager = session host server settigns point to farm name, gateway settings point to gateway(use same creds on gateway and sh is checked,bypass gateway for local add is checked), digital signiature settings will not allow me to specify the same cert that is installed on the gateway server = says it is invalid for rdp signing. 

    Current issues:

    1. traffic does not appear to pass over port 443 when connecting externally from client, appears to hand off to port 3389

    2. Cannot utilize the same verisign cert on gatewaybox and session hosts

    3. Single sign on does not work.  have to login to webaccess then prompted for creds after clicking on pub app, receive cert prompt = request remote computer lists farm name/name on computer states it is the server cert for this session host. i clidk ok and then provide password for my destination host.

    I think that is it hope i provided enough info to help you figure out my problem.  I am guessing i have something misconfigured but not sure where.  Also, everywhere i read it says that i can utilize the same cert but not sure what the os thinks the problem is.  your assistance is appreciated.

    thank you,

    if i uncheck bypass gateway i cannot connect to pub rdp app via web access.

     

    Friday, October 15, 2010 4:56 PM

Answers

  • Hi,

     

    Sorry for the late reply.

     

    Here is the similar issue when triggering the RempteApp programs on the Remote Web Access page.

     

    Hope the following link hopes.

    http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/e956eb02-630d-481b-8726-148a4597d4e3

     

     

    Meanwhile, please try to enter the domain name/user name & password when you provide credentials for the published app. What’s the result?

     

    Can you ping the RemoteApp server from TS Gateway server after change the farm name back to the original name which matched the common name on the certificate?

    Tuesday, October 26, 2010 2:03 AM
  • The problem lies in having the Common Name on the certificate, and the farm name respond to the same name.

    When setting up a RD Web Server Farm and utilizing a Certificate that utilizes multiple SAN's and you wish to use that same certificate to sign published Apps.  The following requirements need to be met.

    1. The common name in the certificate needs to be unique from the Farm Name.

    2. The certificate needs to include the external name, the Farm Name, and each of the fqdn's for each host involved in the architecture.  In addition to that the Common Name needs to be the external name utilized to access the farm externally. 

    3. If the gateway is setup on a perimeter network the hosts involved in the setup should be configured to utilize ports 135 and 24158 for wmi traffic.  This simplifies firewall setup. 

    These are some of the sticking points i ran into and did not find documentation on, with the exception of (3.), that may help others deploying this type of setup. 

    I did NOT include the specifics.  if you reached this point you most likely will figure it out.  Although i could not get the answers i was looking for, i had an idea of what was wrong so save yourself some headache and make then test changes. 

    Accessing this environment from an XP client requires some mod's so review the kb's.  vista is fine with sp2 applied and is the only one that works for sso.  win 7 is also fine as well as 2k8 however i would not expect many clients to utilize 2k8 to connect.

    Good luck, and hopefully this information will assist someone in the future!

    Valentini,

    • Marked as answer by valentini69 Friday, October 29, 2010 4:50 PM
    Friday, October 29, 2010 4:50 PM

All replies

  • Hi,

     

    Thank you for posting.

     

    Question #1

     

    If you enable the RD Gateway, the external users can RD Gateway transmits RDP traffic to port 443 instead of 3389. In this case, I think there is something wrong with your configuration of RD Gateway.

     

    Please review the configuration of RD Gateway through the following article.

     

    Windows Server 2008 RD Gateway Troubleshooting

    http://blogs.technet.com/b/tonyso/archive/2008/02/22/windows-server-2008-ts-gateway-troublshooting.aspx

     

     

    Meanwhile, I suggest that you specific the RD Gateway on RDC by the following steps:

    To specify an RD Gateway server

     

    1. Open Remote Desktop Connection by clicking the Start button . In the search box, type Remote Desktop Connection, and then, in the list of results, click Remote Desktop Connection.

    2. Click Options, click the Advanced tab, and then, under Connect from anywhere, click Settings.

    3. Select Use these RD Gateway server settings, and then type the server name (ask your network administrator for this information).

    4. S elect one of the three available logon methods:

    Allow me to select later. This option lets you select a logon method when you connect.

    Ask for password (NTLM). This option prompts you for a password when you connect.

    Smart card. This option prompts you to insert a smart card when you connect.

    5. Select or clear the Bypass RD Gateway server for local addresses check box.

     

    Selecting this check box prevents traffic to and from local network addresses from being routed through the RD Gateway server. This can make your connection faster.

     

    What’s the result?

     

     

     

    Question #2

     

    In order to use the certificate on the RD server, the certificate should meet some requirements when installing on the RD server.

     

    The following article describes TS Gateway Certificates

    http://blogs.msdn.com/b/rds/archive/2008/12/04/introduction-to-ts-gateway-certificates.aspx

     

     

    Question #3

     

    The single sign on feature will not work for some reasons.

     

    1.       Single sign-on requires that your RDP files are digitally signed by a trusted publisher. The certificate used to sign the RemoteApp programs must be present in the Trusted Root Certification Authorities store on the client computer.

     

    2.       The new single sign-on features, the client must be running Remote Desktop Connection (RDC) 7.0.

     

    Single Sign-On for Terminal Services

    http://technet.microsoft.com/en-us/library/cc772108(WS.10).aspx

     

    Tuesday, October 19, 2010 8:09 AM
  • So let me tell you what i have changed since my first post, before i respond to the questions:

    I went ahead and grabbed a new cert that utilized the "Farm Name" as the "common name" in the cert and specifiec multiple SAN's for each of the serve involved in the farm.  I was then able to expor the cert from the Gateway server and install it on each session server. This automatically cleared up the cert warnings.

    1. i will review the document and see if i have missed something

    1a. tested successfully, able to rdp to gateway.  lock is visible in the rdp window

    2. i will review this doc and see if i notice anything.  other docs were not specific enough.  i had an idea of how to resolve, but it was not in any document i found.

    3a. need to test again after changes.

    3b. did read this however, i have not found a client that reads as 7.0 all i have seen is 6.1.7600 and supports protocol 7.0.  i do recall downloading a client that ran as an ie window in the past but don't recall what that was.  i will re-test again now that the cert appears to be working properly.  i will also review the link provide here as well. 

    Performed a quick test via rd web:

    i can login to the rd web but when selecting an rdp file i am prompted for login which specifies the gateway server name instead of the farm.  (config setting?)

    Here is what it says:

    windows cannot start the remote app program.  the following remote app program is not in the list of remote app programs. "remote desktop connection" for assistance contact bla,bla. 

    i will review the links provided and see if i come up with any config issues and if so resolve them.  figured i would send a reply in case you know what the issue is now that you have more information. 

    Thank you for your assistance, chat with you soon.

    Tuesday, October 19, 2010 3:07 PM
  • Hi,

     

    Additionally, I found a similar issue of RDS Gateway on the Forum. It’s quite clear to help troubleshooting the RDS Gateway issue.

     

    Please kindly refer to the follow link,

     

    http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/f658ae07-4936-4cc2-8c38-12cab619e190

     

    Wednesday, October 20, 2010 3:27 AM
  • Great, i will review this in the a.m.

    One other thing i failed to mention is that we have split dns setup so if i connect via fqdn that resides on the cert it points to the gateway server externally, however after login to rdweb and selecting a published app it tries to connect to the farm name which is the same name listed in the cert(common name) so it again hits the gateway server instead of the sh server.

    i attempted to change the dns record and connect to a different url for the gateway server and to ensure i get to the sh server after selecting the published app and recieve an error stating: Remote desktop cannot connect to the following computer for one of the following reasons

    1.your account is not listed in the gateways permissions list.

    2. you might have specified the remote computer in NETBIOS format but the gateway is expecting fqdn....

    rule previously stated that i can connect to any source...after this i tried adding the gateway and session host servers via fqdn and hostname.  NO LUCK!

    Maybe the article will shed some light here.  i figured i better send additional info since we appear to be on diff work schedules.

    thanks again.  hopefully tomorrow brings better luck.

     

    Wednesday, October 20, 2010 3:50 AM
  • so i was able to do some more testing with no luck, this is what i did:

    Testing:

    Set gateway settings on sh to not bypass gateway for local addresses

    on sh tab specifiec port 443

    on cb specified in RAP can connect to any resource and via 443

     

    1.rdp to gateway server externally via fqdn:

                            client set to auto detect

                                                    successfully rdp and receive lock – not using gateway

                            specified gateway

    1 .your account is not listed in the gateways permissions list.

    2. you might have specified the remote computer in NETBIOS format but the gateway is expecting fqdn....

    rule previously stated that i can connect to any source...after this i tried adding the gateway and session host servers via fqdn and hostname.  NO LUCK!

     

     

    2. rdp to sh server externally via fqdn:

                            client set to auto detect

                                                    successfully rdp and receive lock– not using gateway

                            specified gateway

    1 .your account is not listed in the gateways permissions list.

    2. you might have specified the remote computer in NETBIOS format but the gateway is expecting fqdn....

    rule previously stated that i can connect to any source...after this i tried adding the gateway and session host servers via fqdn and hostname.  NO LUCK!

     

     

    3. rdp to sh server externally via IP:

                            client set to auto detect

                                                    successfully rdp and DO NOT receive lock

                            specified gateway

    1 .your account is not listed in the gateways permissions list.

    2. you might have specified the remote computer in NETBIOS format but the gateway is expecting fqdn....

    rule previously stated that i can connect to any source...after this i tried adding the gateway and session host servers via fqdn and hostname.  NO LUCK!

     

    4. rdp to common name in cert externally via fqdn

                            client set to auto detect

                                                    cannot find fqdn - there is not a record on ext server for this fqdn

                            Specified gateway

    1 .your account is not listed in the gateways permissions list.

    2. you might have specified the remote computer in NETBIOS format but the gateway is expecting fqdn....

    rule previously stated that i can connect to any source...after this i tried adding the gateway and session host servers via fqdn and hostname.  NO LUCK!

     

     

     

    Set gateway settings on sh to not bypass gateway for local addresses

    on sh tab specifiec port 3389

    on cb specified in RAP can connect to any resource and via 3389

     

    1.rdp to gateway server externally via fqdn:

                            client set to auto detect

                                                    successfully rdp and receive lock and wrench–  authenticated and using gateway

                            specified gateway

                                                    successfully rdp and receive lock and wrench–  authenticated and using gateway

     

    2. rdp to sh server externally via fqdn:

                            client set to auto detect

                                                    successfully rdp and receive lock only– not using gateway

                            specified gateway

                                                    successfully rdp and receive lock and wrench–  authenticated and using gateway

     

    3. rdp to sh server externally via IP:

                            client set to auto detect

                                                    *

                            specified gateway

                                                    *

    4. rdp to common name in cert externally via fqdn =there is no dns record for fqdn

                            client set to auto detect

                                                    *

                            Specified gateway

     

    RD Web published app (calculator) does not work in any of these scenarios:

    Receive Error Stating if via 443 on cb and sh

     

                           

     

    Receive Error Stating if 3389 is set cb and sh

     

                           

     

    When I setup the Common name for the cert in external dns the published app again tries to go back to the connection broker for the app because the fqdn is pointing to the connection broker.  (Loop: common name, conn broker, and farm name are the same)

                           

     

                                   

     

    Wednesday, October 20, 2010 7:44 PM
  • sorry, cannot paste images:

    RD Web published app (calculator) does not work in any of these scenarios:

    Receive Error Stating if via 443 on cb and sh:

                            Remote desktop cant find the computer “fqdn of common name on cert” might mean that it does not belong to the same specified network. Verify computer and domain trying to connect to.

    Receive Error Stating if 3389 is set cb and sh:

                            Your computer cant connect to the remote computer because the gateday and remote computer are unable to exchange policies.  This could happen due to:

    1.not capable of exchanging policies with gateway

    2.remote computers config does not permit a new connection

    3.the connection between the gateway and remote computer ended.

    external dns entries:

     connection broker has forward and reverse lookups

     farm name points to the session host servers forward and reverse lookups

    internal dns entries:

     connection broker has forward and reverse lookups

     farm name points to the session host servers forward lookups

     host names of session host servers has forward lookups

     host names of session host servers has reverse lookups

     

    could this be where the problem lies?  wonder if these were dynamically setup.

     

     

    Wednesday, October 20, 2010 8:03 PM
  • OK THIS IS REALLY GETTING PATHETIC THAT I CANNOT GET THIS WORKING!  THINKING I SHOULD HAVE IMPLEMENTED CITRIX...

    so i am going to attempt to describe my setup once again and see if this helps because i may have changed things a bit.  i think i tried every possible setting change with various issues with each.

    Certificate:

    Common Name plus multiple SAN's one for each server.  (the connection broker and each session host)

    ive tried utilizing the common name and the fqdn of the gateway/conn broker for the gateway settings with no luck

    before I had the common name the same as the farm name. (had farm name first) thought this would work because the dns servers for the gateway and session host servers are the same and internal or on the same network as each server involved.

    DNS:

    I have External and Internal entries identical

    the gateway server has two entries common name on cert is a cname pointing to the hostname of the gateway server.

    The hostname also points to the same IP

    Entries: Training farm point to a.b.c..x, and a.b.c..y, common name points to a.b.c.z, hostname of gateway points to a.b.c.z

    Gateway/connection broker server:

    ·          Remote desktop connection has cert installed

    ·          Gateway manager points to hostname of gateway server

    ·          Policies are setup for group access to any resource via 3389, tried 443 also

    ·          Rdp-tcp properties has same cert installed and is setup for SSL(tls 1.0)

    ·          IIS websites rdweb, and rpc require SSL

    Session host server:

    Remote app deployment settings:

    ·          SHS tab points to farm name something.domain.com port 3389

    ·          Gateway tab points to gateway server by fqdn which is not common name in cert

    ·          Bypass rd gateway is not checked

    ·          The same cert is installed here

    Rd session host config:

    ·          Rdp-tcp settings are same as gateway

    ·          Rd connection broker settings indicate:

    o    This server is a member of a farm

    o    Farm name is specified

    o    Gateway server is specified by fqdn

    o    Set for ip address redirection

    I think that is it.  Can someone tell me if there are any glaring issues with this config?  Trust me your help is appreciated.  I can’t believe I cannot get this working. J

     

    Thursday, October 21, 2010 9:57 PM
  • Hi,

     

     

    As you posted some results above, I don’t think this is a good idea to change RD SH port to 443. As far as I know, the external client will pass the traffic via RDP over SSL to RD gateway server, and then the gateway server will pass your traffic to the target servers.

     

    Meanwhile, the testing result of part tow (on SH tab specific port 3389), that make more sense from my point of view.

     

    Now let’s move on the RemoteApp issue on the RD web access.

    Based on my knowledge, we have to methods to deploy this RD web access on internet.

     

    1.       Place both the TS Gateway server and the TS Web Access server in the perimeter network.

    2.       Publish the TS web access server.

     

    For more information:

     

    TS RemoteApp Step-by-Step Guide

    http://technet.microsoft.com/en-us/library/cc730673(WS.10).aspx

     

     

    For the further troubleshooting, please help to collect the following Information:

     

    1.       Does this issue of RemoteApp exist when you’re using it in the internal network? If does not, I suggest check your CAP and RAP polices.

     

    2.       Would you mind letting me know the detail errors of then event log when you use the RemoteApp programs?

     

    ===========================================================================================

    For your convenience, I have created a workspace for you.  You can upload the information files to the following link.  (Please choose "Send Files to Microsoft")

     

    Workspace URL:( https://sftasia.one.microsoft.com/choosetransfer.aspx?key=50cdf0eb-eca8-4ed4-a1e7-46288dcf067d )

    Password: BYN3pNP])D%^v

     

    Note: Due to differences in text formatting with various email clients, the workspace link above may appear to be broken.  Please be sure to include all text between '(' and ')' when typing or copying the workspace link into your browser. Meanwhile, please note that files uploaded for more than 72 hours will be deleted automatically. Please ensure to notify me timely after you have uploaded the files. Thank you for your understanding.

     

    Friday, October 22, 2010 2:40 AM
  • Thank you for the additional information:

    I wanted to pass the traffic over 443 because all servers are currently accessible vi the perimiter network.  In the article i think i have what i need to relocate them back into the private network. 

    I will be utilizing option 1 the guide you reference also identifies the additional ports i need to open up. 

    Issues i had with testing from a Win7 client seem to have led me astray.  i ended up testing from a 2k8r2 client and did not have any issues so i restarted the win7 client and then it becan to work as the 2k8r2 did. 

    so i am at the point where i am utilizing port 3389 and have validated tha i can connect with a win7 client and 2k8r2 client. 

    Current issues:

    i am now getting a cert error for the new farm name. 

         I should be able to change things back to resolve this.

    via the win xp client i keep getting prompted for credentials over and over.

         I will test this after i revert changes so to speak and validate functionality once again.

    The final step assuming things go well is to relocate the sh servers back inside and validate proper communication.

     

    Internal access functions the same as external access with the exception of the xp client, haven't tested.  i will get back to you.

    Thank you,

     

    Friday, October 22, 2010 4:23 PM
  • I HAVE UPLOADED THE FILES YOU REQUESTED.  HOPE THIS HELPS.  I WILL CHECK THIS POST THROUGHOUT THE DAY.

    THANK YOU,

    Friday, October 22, 2010 7:14 PM
  • I found this post essentially he had the same issue except i am using the same name all the way through.

    http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/ba0dbe94-4209-475f-b026-93189a83744f

    something.domain.com is used as the:

    1. Common name in a verisign cert with multiple SANS(each host involved,gateway/rdweb and each session host)

    2. I also am using this name as the farm name = something.domain.com

    3. tried both url's to hit the web access page.  something.domain.com, and hostname.domain.com

    Currently the gateway/rdweb box is avaiable externally as well as the sh servers.

    my thought is the client will use something.domain.com/rdweb to hit the page.  Once logged in the host will utilize it's primary or secondary dns servers to reach the Farm name "something.domain.com" and all is well. :) lol 

    maybe not, this is where i run into issues...

    hope this clears up what i am trying to do.

    thank you,

     

     

    Friday, October 22, 2010 7:53 PM
  • hi valentini, since you are using app publishing, can you check the rdsh server to see that the remoteapp connection setting is set to use gateway?  Also i'd recommend disabling by-pass for local address; it seems to cause more issues for me than it solves.
    Friday, October 22, 2010 9:14 PM
  • i think you are referring to the "RD Gateway" tab of the remote app deployment settings.  if so the gateway fqdn is set here and i do not have "bypass the gateway for local addresses" checked.

    let me know if i misunderstood your reply.

    thank you

    Friday, October 22, 2010 9:58 PM
  • Any updates here?
    Monday, October 25, 2010 3:11 PM
  • Hi,

     

    Sorry for the late reply.

     

    Here is the similar issue when triggering the RempteApp programs on the Remote Web Access page.

     

    Hope the following link hopes.

    http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/e956eb02-630d-481b-8726-148a4597d4e3

     

     

    Meanwhile, please try to enter the domain name/user name & password when you provide credentials for the published app. What’s the result?

     

    Can you ping the RemoteApp server from TS Gateway server after change the farm name back to the original name which matched the common name on the certificate?

    Tuesday, October 26, 2010 2:03 AM
  • The problem lies in having the Common Name on the certificate, and the farm name respond to the same name.

    When setting up a RD Web Server Farm and utilizing a Certificate that utilizes multiple SAN's and you wish to use that same certificate to sign published Apps.  The following requirements need to be met.

    1. The common name in the certificate needs to be unique from the Farm Name.

    2. The certificate needs to include the external name, the Farm Name, and each of the fqdn's for each host involved in the architecture.  In addition to that the Common Name needs to be the external name utilized to access the farm externally. 

    3. If the gateway is setup on a perimeter network the hosts involved in the setup should be configured to utilize ports 135 and 24158 for wmi traffic.  This simplifies firewall setup. 

    These are some of the sticking points i ran into and did not find documentation on, with the exception of (3.), that may help others deploying this type of setup. 

    I did NOT include the specifics.  if you reached this point you most likely will figure it out.  Although i could not get the answers i was looking for, i had an idea of what was wrong so save yourself some headache and make then test changes. 

    Accessing this environment from an XP client requires some mod's so review the kb's.  vista is fine with sp2 applied and is the only one that works for sso.  win 7 is also fine as well as 2k8 however i would not expect many clients to utilize 2k8 to connect.

    Good luck, and hopefully this information will assist someone in the future!

    Valentini,

    • Marked as answer by valentini69 Friday, October 29, 2010 4:50 PM
    Friday, October 29, 2010 4:50 PM