Udostępnij za pośrednictwem


Unable to access shares or SCCM Remote Control from internal network to the Direct Access(DA) clients

DESCRIPTION:

From SCCM machine we were unable to use Remote control against the DA clients that connect via UAG.

SCENARIO:

 

 Lab done based on this.

TROUBLESHOOTING DONE:

Doing a network trace on the SCCM we were able to see that SCCM tries to connect to FIRST to port 135 and I also saw connection to port 445 when issuing the Remote Control command. However documentation states:

 https://technet.microsoft.com/en-us/library/bb694088.aspx

 Remote Control

In order to use the remote tools features of Configuration Manager 2007, you need to allow the following ports:

  • TCP port 2701
  • TCP port 2702
  • TCP port 135

My tests shown TCP/135 and TCP/445 and only after those connections work we see: TCP2701/TCP2702

I believe that this documentation should also have 445 here, actually documentation refers to File and Print sharing....

"Windows Event Viewer, Windows Performance Monitor and Windows Diagnostics

To enable Windows event viewer, Windows performance monitor and Windows diagnostics to be accessed from the Configuration Manager console, you must enable File and Printer Sharing as an exception on the Windows Firewall."

Network traces shows that TCP 445 connections are tried from SCCM to remote DA client.

On the DA Client, there’s no point in doing any network trace because all the traffic goes via IPSec Tunnel established between DA Client and UAG.

There’s specific ways to get this data using netsh but I didn’t follow that.

My goal now was to have port TCP 445 / 135 from internal network to DA clients working. Fact was that:

- DC is able to connect to DAClient:

- (ICMP) Ping -> work.  

- (TCP 3389) mstsc -> works

- (TCP 445) Access to Share -> Fails from DC or SCCM or any other machine in internal network.

 

Lot's of configuration tried in the Windows Firewall of the machine without success.

Until something was found:

...by default the Remote IP Scope when you enable (SMB in) in your firewall we got:

 

It was very tricky to find that this was the cause for the problem.

Of course this is wrong - “Local Subnet” for DA Client cannot be our internal network.

Changing this to “Any IP Address” started to work in my lab.

On the Windows Firewall of the DA client. I’ve configured a Local GPO to allow File and Print Sharing: (You can also set this by a Domain Policy or in GPO UAG Client Access policy.)

 

 

We wanted to make sure that we could focus in a specific range. Security is important.

How do we know what range to use?

From a DA Client do a ping to an internal machine and check the reply.

  1. 2002:WWXX:YYZZ:8000::/49 as the organizational prefix
  2.  2002:WWXX:YYZZ:8000::/64 as the ISATAP prefix
  3.  2002:WWXX:YYZZ:8001::/96 as the NAT64/DNS64 prefix
  4.  2002:WWXX:YYZZ:8100::/56 as the IP-HTTPS prefix

Ping reply was: 

2002:2700:e9:8000… etc… this means ISATAP

So added this range on my DA Client firewall.

 

With customer environment the firewall was 3rd party but the logic was the same.

From Da client we did a ping to internal network, we saw reply being ISATAP and we added the entry.

 

 Shares working

Remote control started to work in production environment

Hope this helps...