RDS and Gateway issues: Cannot get remoteapps to run without opening port 3389 on firewall

Question

I am testing the setup of a small RDweb server to host QuickBooks for some remote sales users (4 users). For the most part, I have everything installed on one virtual server (using 2012r2 "Quick Start" session host deployment with the additional
Licensing and Gateway server roles added to the same server).
Everything works excellent with one exception. External clients cannot launch published apps without having port 3389 open on the firewall, even with the gateway role installed and the 'Deployment Properties' set to use the gateway. They can properly connect
to the RDweb site and view the published apps. The only way it works is open the firewall port (at which time I can disable the gateway or leave it configured and it works either way). Internally, everything works accordingly. I have followed the steps outlined
on many sites and have combed though the forum here to no avail.
Error received (summarized but is a well documented error):
remote desktop can't connect to the remote computer: 1- Your user account is not listed (it actually is) or 2- You might have specified the remote computer in NetBios format . . etc.
This is an existing SBS 2011 environment with additional virtual servers setup to host QuickBooks as outlined below:
Current setup:
Used Quick Start to install Remote Desktop Services in hosted sessions mode
Installed the additional roles for Licensing and Gateway server on same server
Configured wild card public certificates on all four services (Connection Broker(2), Web Access and Gateway)
Configured internal DNS to properly lookup our external FQDN of this server (ex. quickbooks.contoso.com points to quickbooks.contoso.local
One thing I noticed (just now) when I launch a published app and the firewall has port 3389 closed, a dialog box pops up directly after launching the app that warns about running a RemoteApp program and mentions the Remote Computer and the Gateway Server
as both the same (which it is); however, I would have assumed one would have listed the internal server's name while, instead, both are listed as the external FQDN. Either way, internal DNS should still allow it to properly route . . no? I don't know . . I'm
sure I am just missing something in a routing configurations somewhere. The gateway service is not properly looking up the RDweb service and then seeming not routing the encapsulated RDP session through HTTPS. . .. is my guess . .
I was reading about the "set published name" commandlet; however, I am not experiencing a certificate name mismatch; however, the certificate name does show up as *.contoso.com versus the actual name. I may just be grasping as straws now . . :)

Answer 1

Ok, while I was in the server and looking over the BPA scans: "The Remote Desktop Gateway (RD Gateway) server Secure Sockets Layer (SSL) certificate may not have a valid certificate subject name." This may be due to it showing up as *.companyname.com
versus quickbooks.companyname.com. Anyhow. .. on to the list of actions above:
Changed RD RAP from "Select Active Directory" group to "Allow any network resource" and tested with port 3389 closed on firewall:
Worked. Initially it did not as I had used a custom shortcut created from earlier; however, after logging into the RDweb site again, the application loaded fine now (after the RD RAP change)
No error message appeared; however, I did notice that for a split second, the word Error did appear in the browser's tab title, but only very shortly. The app launch does take a bit longer too now (about 10-15 seconds, up from about 4 seconds with the port
open). This, I could care less about so long as we are properly forwarding the traffic through the gateway.
As for log entries, I had spend quite a bit of time in there and only had minor issues with loading user profile setting taking too long and policy settings preventing the redirection of USB devices. Looking again, no issues still. Just a bunch of informational
entries where I would connect before (and disconnect) but only with the port on the firewall open; otherwise, there was not an entry corrolating to when I would receive an error before. Now though, I am connecting after the RD RAP change and logs are showing
connections even with the port closed. These are in "operational", the "admin" log only shows the update to the RD RAP configuration.
Yes, the LAN's DNS server does relay the lookup information for my public FQDN as the local LAN address. No need for a local host record.
I have now added a new rule in our firewall to allow and forward UDP port 3391 traffic to the internal server hosting remote services
Thank you very much for your assistance on this matter. The RD RAP rule was default built during the creation of this services. Why is the resource not cross-referencing AD security groups? I could have sworn I created a group for that . . .