Design Protection for Traffic between DirectAccess Clients

Applies To: Windows 7, Windows Server 2008 R2

Important

This topic describes design considerations for DirectAccess in Windows Server 2008 R2. For the design considerations of DirectAccess in Microsoft Forefront Unified Access Gateway (UAG), see the Forefront UAG DirectAccess Design Guide (https://go.microsoft.com/fwlink/?LinkId=179988).

DirectAccess clients on the Internet can communicate with each other directly without having to go through the DirectAccess server. For example, two DirectAccess clients on the Internet named DACL1 and DACL2 have public Internet Protocol version 4 (IPv4) addresses and configure themselves as 6to4 hosts with 6to4 addresses. DACL1 and DACL2 register their 6to4 addresses with intranet DNS servers. When DACL1 initiates communication with DACL2 by name, the intranet DNS server responds with the 6to4-based address of DACL2. DACL1 then uses 6to4 tunneling to communicate directly with DACL2.

Without data confidentiality, the traffic between DACL1 and DACL2 is sent as clear text. Some applications provide their own data confidentiality and some—such as Remote Assistance and File and Printer Sharing—do not. To protect the traffic between DirectAccess clients for all applications, do the following:

1. Create a connection security rule with the following properties:

   • Rule Type: Isolation

   • Requirements: Request authentication for inbound and outbound connections

   • Authentication Method: Computer Certificate for the first authentication

   • Profile: Private and Public

   To configure this connection security rule using the Network Shell (Netsh) command-line tool, you can use the following command:

   **netsh advfirewall consec add rule endpoint1=any endpoint2=any action=requestinrequestout profile=public,private auth1=computercert auth1ca=**CAName

2. Create a connection security rule with the following properties:

   • Rule Type: Custom

   • Endpoints: Endpoint 1 address for your intranet IPv6 prefix, Endpoint 2 address for your intranet IPv6 prefix

   • Requirements: No authentication

   • Protocols and Ports: Any

   • Profile: Domain, Private, and Public

3. Create an inbound rule for each application that needs to accept unsolicited inbound connection requests.

   • For example, for Remote Desktop, the inbound rule has the following properties:

     • Rule Type: Port

     • Protocols and Ports: Transmission Control Protocol (TCP) 3389

     • Action: Allow the connection if it is secure, Require the connections to be encrypted

     • Profile: Private and Public

   To configure this Windows Firewall rule for Remote Desktop using Netsh.exe, you can use the following command:

   netsh advfirewall firewall add rule name=RemoteDesktop profile=public,private program=system action=allow security=authenc protocol=tcp localport=3389

For additional protection, you can require protection for all inbound connections to the DirectAccess client. You can specify this when creating the rule in the following ways:

• From the Windows Firewall with Advanced Security snap-in, on the Requirements page, select Require authentication for inbound connections and request authentication for outbound connections instead of Request authentication for inbound and outbound connections.

• For the Network Shell (Netsh) command, specify the action=requireinrequestout parameter instead of action=requestinrequestout.

With this additional protection, outbound connections to other DirectAccess clients is encrypted regardless of the application. Outbound connections to Internet destinations and non-DirectAccess clients is sent as clear text.

For more information, see Configure Connection Security Rules for Traffic Between DirectAccess Clients in the DirectAccess Deployment Guide.