This topic describes how to protect traffic between DirectAccess clients.

DirectAccess clients on the Internet can communicate with each other directly without their traffic going through the Forefront UAG 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, and DACL1 then uses 6to4 tunneling to communicate directly with DACL2.

Without data confidentiality, the traffic between DACL1 and DACL2 is clear text. Some applications provide their own data confidentiality and some, such as Remote Assistance, Remote Desktop, and File and Printer Sharing, do not.

The following lists the connection rules you can configure to protect traffic between DirectAccess clients for all applications.

Note:
  • To create the connection rules below using the Netsh command-line tool, but in a GPO context, see Use Netsh to Configure GPOs (http://go.microsoft.com/fwlink/?LinkId=169485).

  • It is recommended that you create a separate DirectAccess client GPO for the rules below. This is because when the Forefront UAG DirectAccess configuration script is applied, the Windows Firewall and Advanced Security section of the DirectAccess client GPO is cleared.

To protect the traffic between DirectAccess clients for all applications

  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

    Note:
    To configure this connection security rule using the Network Shell (Netsh) command-line tool, use the following command: netsh advfirewall consec add rule endpoint1=any endpoint2=any action=requestinrequestout profile=public,private auth1=computercert auth1ca=CA_Name
  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.

    1. 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, use the following command:

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

  4. 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 will be encrypted regardless of the application. Outbound connections to Internet destinations and non-DirectAccess clients will be sent as clear text.