Designing protection for traffic between DirectAccess clients
Updated: February 1, 2010
Applies To: Unified Access Gateway
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 (https://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
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_NameCreate 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
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, 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 will be encrypted regardless of the application. Outbound connections to Internet destinations and non-DirectAccess clients will be sent as clear text.