i want to RDP from the LAN to clients on the NC-Network. My accesslist looks like that:
1. Rule: ICMP any
2. Rule: Admin Rule
3. Rule: Remote Access
and so on...
This is not working - its not possible to make an RDP-Connect to any client that has a NetworkConnect IP. If I add an "any any allow to all roles"-rule to the top, it works. so its something at the ACL which is not correct but i dont know why. any help? dont want to have "any any"-rules there
Tried with windows-rdp @ tcp/3389.
From my experience Network Connect resource policies are not bidirectional so for example tcp://*:3389 allows the Network Connect user to connect to devices on the Internal network on port 3389 but does not allow internal devices to connect to the Network Connect user on portr 3389. If you could predict the source port the internal devices is using you may be able set up a policy to allow it but RDP usually uses random source ports,
Well - I will fire away with the "stupid" question of the day. Why use NC for RDP access? RDP is easily provided with very tight security through the standard "core" access. If you want security gaurentees it for you.
If I'm reading this correctly (orig. issue) then the problem could be obfuscated by the outside setup. If the end machine was behind a firewall or router that hid the machine from that type of connection you'd be out of luck trying to use that method.... unless I'm missing something.
I think Microsoft DirectAccess is addressing this issue in 2008 R2.
@dcvers: yes we're also using the supportmeeting feature but it isnt as fast and comfortable as just a simple RDP session though the vpn. it also has to be installed on the clientmachine and could cause additional problems, thats not the perfect solution.
@muttbarker: uhm, i dont know what you mean. we are not providing NC for rdp access! we just want to remote support users who are connected via NC and are experiencing any problems.
As mentioned by dcvers, the policies are outbound NC -> intranet, so the tcp://*:3389 policy will not work.
Depending on your network structure, there are a couple other options that might work (increased administrative pain, yes, but it does allow some more control than *:*):
1) If all support staff go through a NAT/proxy; this would allow you to set a tcp://<NATted_IP>:*
2) If your support staff is on a specific network, you could use tcp://subnet/mask:*
3) If your support staff all use a static list of IPs, and only your support staff would have these IPs, you could use tcp://staticIP:* for each PC
Unfortunately the port needs to be '*' (any) as the inbound port will vary from attempt to attempt, even though it leaves the client on 3389.