RDP access via TMG

Hi Guys,

I have RDP access into my TMG server from the internet using the remote desktop client on a custom port.

It works well accessing the TMG server, but I am trying to setup access to another internal Windows 2008 server on a different port.

I've setup a non-website publishing rule in TMG, with destination server IP, the custom port number, etc.

All seems to be 100% correct, but access to the secondary server (via TMG) does not seem to work.
Access briefly worked after configuration and then went off.  I am able to access the secondary server from the LAN, but not via TMG, tried almost all configurations, even with default 3389 port, but no joy!!

Any ideas?
Rupert EghardtProgrammerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Craig BeckCommented:
If you do some logging on the rule in TMG what does it say when you try to connect from outside?
Rupert EghardtProgrammerAuthor Commented:
Connection is very intermittent, works for a minute or two, then stops, then starts working again ...

The only error displayed in the log file:

Configuration changes made may result in loss of connectivity to the configuration storage server HE**.**.local and cannot be applied. This alert is caused by a failure to connect to the Domain Controller. The error description is: The specified domain either does not exist or could not be contacted.

The failure is due to error: The specified domain either does not exist or could not be contacted.

However, it seems to work for a minute or two, then stops working again.
Craig BeckCommented:
So are you allowing DNS from localhost to your DCs?
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Rupert EghardtProgrammerAuthor Commented:
TMG is on a seperate IP network, but it has a routing to the DC (network).
I am able to ping the target RDP server by name and IP address.
Craig BeckCommented:
The TMG needs rules to allow it to talk to DCs and vice-versa regardless of whether it's on the same IP network as the DCs or not.  Any traffic to or from the TMG itself is defined as Localhost so if you have no rule allowing access from the TMG to a DNS server it won't be able to locate a SRV record for a DC.
Rupert EghardtProgrammerAuthor Commented:
Do you suggest we add an Access Rule to enable the communication back to the DC?
What I dont understand, we have OWA, RPC and Active Sync as well as other domain applications running just fine from this TMG server.

It's not making any sense ...
Craig BeckCommented:
OWA, ActiveSync, etc don't come FROM TMG, they come THROUGH TMG (usually unless you're using Forms, etc).

Let's say you want to allow access to your internal Exchange via ActiveSync from an external network; you would have a rule that allows the publishing of your Exchange via ActiveSync from External to Internal.

When you want traffic to come from TMG itself, you need to source the traffic from Local Host, not from Internal or External networks.  The TMG itself is a network in its own right.

If you want to allow RDP from Internal to the TMG you need to create a rule to allow TCP/3389 from your Internal network object to Local Host.  The only difference you'll notice is that you don't actually create that rule, you just enable the Remote Admin option in the TMG's system admin settings.

The TMG needs to be able to see a DC to resolve DNS queries (as per the error you saw) so it sounds like either:

1] there is no rule allowing comms between the TMG and DC.  I'd create a rule allowing everything between the TMG (Local Host) and your DCs in both directions to test, or

2] the DNS servers you configured on the TMG are not correct.  On the internal NIC you need to configure the DNS server address of your DCs which do DNS.  Quite often people just use an external DNS for this - that's not a correct configuration.

When the TMG wants to enumerate its configuration it needs permission (as per security ACL, etc) to do so.  If the TMG can't authenticate against the domain it can't read security permissions.  If, on the other hand however, the failure is intermittent that may sway me to believe that one DNS server may be incorrect, or the TMG is trying to use round-robin between all configured (external and internal NIC DNS addresses) but timing out.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Rupert EghardtProgrammerAuthor Commented:
Hi Craigbeck,

Following your message above, I don't understand ... as the problem I'm having is also with traffic PASSING through TMG, not originating from the TMG server.

Nevertheless, we have two TMG servers onsite and I've setup a rule on a second TMG server for testing the RDP problem.

Thus, traffic coming from external, via TMG, passing to the destination server on port 30405.

This time I am getting the following error in the logs (LIVE):

Destination IP = TMG wan IP
Destination Port = 30405 (which is the port I've setup for the destination server)
Port = 30405 outgoing  (I've also setup incoming traffic on port 30405 in the same rule)
Action = denied connection
Rule = default rule
Code = 0xc004000d FWX_E_Policy_Rules_Denied
Source network = External
Destination network = Local host
Server = TMG server

I am able to successfully access the destination server from the TMG server via RDP on port 30405.

I am also able to access the TMG server directly from externally via a different port.
Craig BeckCommented:
The log tells you which rule blocked the traffic.  We can see that the default rule blocked the traffic so the rule you configured is incorrect.  That's the problem.
Rupert EghardtProgrammerAuthor Commented:
Would you mind having a looking at the attached screenshots and pointing out any mistakes you may see?
Rupert EghardtProgrammerAuthor Commented:
Problem not yet solved.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.