Insights Firewall Exceptions to allow SCCM Remote Control for DirectAccess clients

Firewall Exceptions to allow SCCM Remote Control for DirectAccess clients

Managing DirectAccess computers with SCCM is a great way to keep your mobile workforce up to date and in compliance with the corporation. Because everything is done on a “pull” basis, meaning the client computer pulls updates from the corpnet, things “just work” as normal. However, many people find that they are unable to use the SCCM Remote Control (or “Remote Tools” or “Remote Assistance”) to connect to DirectAccess computers. Why is that? First, remember that the DirectAccess clients are connecting to the Corpnet using IPv6 addresses. In most cases the Remote Access / DirectAccess server is then using NAT64 to translate that IPv6 traffic so it can talk to an IPv4 Corpnet, but it does not work the other way; IPv4 traffic from the Corpnet cannot be translated into IPv6 to reach the DirectAccess client. This means if you want to be the first one to start communications with a DA client, then you too must be able to talk IPv6. This can be a challenge if you are not already using Native IPv6 on the Corpnet, but you can pretty easily accomplish this by using the Remote Access server as an ISATAP router which will establish a sort of link-local IPv6 network on top of your existing IPv4 network. ISATAP enabled clients will then be able to talk IPv6 through the ISATAP router on Remote Access server and reach the DirectAccess clients. But that’s outside the scope of this article. The second reason is because the DirectAccess clients have their Windows Firewall enabled and will block unsolicited traffic. If you want to send traffic to the DA client, then you need to create a firewall exception to allow it in. You cannot (and should not) simply disable the firewall profile on the DA client, not only because it’s unsecure, but because the firewall service is used to establish the IPsec tunnels that DirectAccess uses to talk to the Corpnet. So how do you create a firewall exception for DirectAccess client without just opening up service to the entire world? First, we need to determine the scope of the IPv6 / ISATAP network that will be sending traffic to your DirectAccess clients, and then we can create the exceptions and limit the source to that scope. On the Remote Access server or any ISATAP enabled computer, run “ipconfig“.You want to know the prefix of the IPv6 address on the “Tunnel adapter isatap” adapter, up to and including the “:5efe:“. We will use this to define the a /96 network that represents your entire ISATAP network from which to allow incoming connections.

This is unique to your corpnet, so only computers from within your Corpnet, traversing the IPsec tunnels will match this scope!Create your firewall rule and when you specify the scope, set the Remote IP to the IPv6 subnet using :5efe:0.0.0.0/96. So using fd94:1:1:1:5:5efe:0.0.0.0/96 might be an example.

Also, to support Teredo connections, you must make sure that you Allow edge traversal on the rule. You cannot specify this in the creation wizard so once your made the rule you need to edit the Properties to select this from the Advanced tab. There is a list on TechNet that shows the ports used by the Configuration Manager Console to reach out to the Client. 

DescriptionUDPTCP
Remote Control (control)27012701
Remote Control (data)27022702
Remote Control (RPC)135
Remote Assistance (RDP and RTC)3389

This means there are 5 rules to make to allow SCCM Remote Tools to connect to your DirectAccess clients. Make a Group Policy to allow these exceptions for your ISATAP subnet and you’re golden. Note: If you want to allow other kinds of communications TO the DirectAccess client, for example accessing administrative file shares or pinging it, you can make those exceptions too. All you need to know is what Protocol and Port to allow, then assign the scope and allow edge traversal.