e2e: Simplified Direct Access in an IPv4-only Environment

• One computer named DC1 that is running Windows Server 2012. The computer is configured as an intranet domain controller, a Domain Name System (DNS) server, and a Dynamic Host Configuration Protocol (DHCP) server.
• One intranet member server named EDGE1 that is running Windows Server 2012. The computer is configured as a DirectAccess server.
• One intranet member server named APP1 that is running Windows Server 2012. The computer is configured as a general application server and a web server.
• One stand-alone server named INET1 that is running Windows Server 2012. The computer is configured as an Internet DHCP server, a DNS server, and a web server.
• One roaming member client computer named CLIENT1 that is running Windows 8. The computer is configured as a DirectAccess client.
• One stand-alone client computer named NAT1 that is running Windows 8. The computer is configured as a network address translation (NAT) device that uses Internet Connection Sharing.

• The Internet (131.107.0.0/24).
• An intranet named Corpnet (10.0.0.0/24) separated from the Internet by EDGE1.
• A home network named Homenet (192.168.137.0/24) connected to the Internet subnet by using a NAT device.

Hardware and software requirements

1. Set up the Base Configuration test lab:
   
   The Remote Access simplified setup test lab requires the Test Lab Guide: Windows Server 2012 Base Configuration with Optional mini-module: Homenet subnet as its starting point.
2. Configure DC1:
   
   DC1 is already configured as a domain controller with Active Directory, and as the DNS and DHCP server for the intranet subnet. For the DirectAccess simplified setup test lab, a security group will be added to Active Directory for DirectAccess client computers.
3. Configure EDGE1:
   
   EDGE1 is already a member server. For the Remote Access express setup test lab, EDGE1 must be configured as a Remote Access server that has simplified DirectAccess deployed.
4. Configure CLIENT1:
   
   CLIENT1 is already a domain member client computer that is running Windows 8. For the Remote Access express setup test lab, CLIENT1 will be used to test and demonstrate remote access operation.

Create a security group for DirectAccess client computers

To create a DirectAccess client security group

1. On DC1, from the Start screen, click Active Directory Administrative Center.
2. In the console tree, click the arrow to expand corp (local), and then click Users.
3. In the Tasks pane, click New, and then click Group.
4. In the Create Group dialog box, type DirectAccessClients for Group name.
5. Scroll down to access the Members section of the Create Group dialog box, and then click Add.
6. Click Object Types, select Computers, and then click OK.
7. Type CLIENT1, and then click OK.
8. Click OK to close the Create Group dialog box.
9. Exit the Active Directory Administrative Center.

1. In the Dashboard console of Server Manager, under Configure this local server, click Add roles and features.
2. Click Next three times to reach the server role selection screen.
3. In the Select Server Roles dialog box, select Remote Access, click Add Features when you are prompted, and then click Next.
4. Click Next five times to accept the default settings for features, remote access role services, and web server role services.
5. On the Confirmation screen, click Install. Wait for the feature installations to complete, and then click Close.

To configure DirectAccess by using the Getting Started Wizard on EDGE1

1. From the Start screen, click Remote Access Management.
2. In the Remote Access Management console, click Run the Getting Started Wizard.
3. Click Deploy DirectAccess only.
4. Verify that Edge is selected as the network topology. Type edge1.contoso.com as the public name to which remote access clients will connect. Click Next.
   
   Note By default, the Getting Started Wizard deploys DirectAccess to all laptops and notebook computers in the domain by applying a WMI filter to the client settings GPO. This default is unsuitable for the lab environment. Because the CLIENT1 computer is a member of the DirectAccessClients security group in Active Directory, take the following steps to change the client security group setting for DirectAccess.
5. On the final wizard page, click the link supplied to edit the wizard settings.
6. In the Remote Access Review dialog box, next to Remote Clients, click Change.
7. On the Select Groups screen, clear the Enable DirectAccess for mobile computers only check box.
8. Click Domain Computers (CORP\Domain Computers), and then click Remove.
9. Click Add, type DirectAccessClients, and then click OK.
10. Click Next, and then click Finish.
11. Click OK in the Remote Access Review screen, and then click Finish.
12. Because there is no PKI deployment in this test lab, the wizard will automatically provision self-signed certificates for IP-HTTPS and the Network Location Server, and will automatically enable Kerberos proxy. The wizard will also enable NAT64 and DNS64 for protocol translation in the IPv4-only environment. After the wizard successfully finishes applying the configuration, click Close.
13. In the console tree of the Remote Access Management console, select Operations Status. Wait until the status of all monitors are displayed as "Working." From the Tasks pane under Monitoring, click Refresh periodically to update the display.

1. Connect CLIENT1 to the Corpnet subnet. Restart CLIENT1 when it is connected to the Corpnet subnet to update its security group membership and to apply the DirectAccess client Group Policy settings.
2. From the Start screen, type PowerShell, then right-click Windows PowerShell, and then click Run as administrator.
3. Type Get-DnsClientNrptPolicy and press Enter. The Name Resolution Policy Table (NRPT) entries for DirectAccess are displayed. The NLS server exemption is displayed as DirectAccess-NLS.corp.contoso.com. The Getting Started WizardWizard automatically created this DNS entry for the DirectAccess server and provisions an associated self-signed certificate so that the DirectAccess server can function as the Network Location Server.
4. Type Get-NCSIPolicyConfiguration and press Enter. The network connectivity status indicator settings deployed by the wizard are displayed. The value of DomainLocationDeterminationURL is https://DirectAccess-NLS.corp.contoso.com:443/insideoutside. When this network location server URL can be accessed, the client will determine whether it is inside the corporate network, and NRPT settings will not be applied.
5. Type Get-DAConnectionStatus and press Enter. Because the client can reach the network location server URL, the status is displayed as "ConnectedLocally."
6. In a simplified DirectAccess deployment, client computers are not configured to use a 6to4 relay, and there is no routing for 6to4 on the Test Lab Guide simulated Internet subnet. To disable 6to4 on CLIENT1, type netsh interface 6to4 set state state=disabled and press Enter.

To test remote access from the Internet

1. Connect CLIENT1 to the Internet subnet. As soon as the network determination process is complete, the network icon should indicate Internet access.
2. In the PowerShell window, type Get-DAConnectionStatus and press Enter. The status should be displayed as "ConnectedRemotely."
3. Click the network icon in the System Notification Area. Workplace Connection is listed as Connected. This is the default connection name that was provided by the DirectAccess wizard.
4. Right-click Workplace Connection and then click Properties. The Status is displayed as "Connected."
5. From the PowerShell prompt, type ping inet1.isp.example.com and press Enter to verify Internet name resolution and connectivity. You should receive four replies from 131.107.0.1.
6. Type ping app1.corp.contoso.com and press Enter to verify corporate intranet name resolution and connectivity. Note the format of the IPv6 address returned. Because there is no IPv6 deployed in the test lab, the dynamically created NAT64 address of APP1 is returned. The dynamically created prefix assigned by DirectAccess for NAT64 will be in the form fdxx:xxxx:xxxx:7777::/96.
7. Start Internet Explorer, and verify that you can access the websites on http://inet1.isp.example.com and http://app1.corp.contoso.com.
8. From the desktop taskbar, click the Windows Explorer icon.
9. In the address bar, type \\app1\Files, and then press Enter.
10. You should see a folder window with the contents of the Files shared folder.
11. In the Files shared folder window, double-click the Example.txt file. You should see the contents of the Example.txt file.
12. Close the example.txt - Notepad and the Files shared folder windows.
13. From the PowerShell window, type Get-NetIPAddress and then press Enter to examine the client's IPv6 configuration. The results show the tunnel adapter IPHTTPSInterface is active with a valid IP-HTTPS address. CLIENT1 is using IP-HTTPS to tunnel IPv6 traffic to the EDGE1 server.
14. Type Get-NetIPHTTPSConfiguration and press Enter. Examine the settings applied by Group Policy to direct the client to https://edge1.contoso.com:443/IPHTTPS.
15. Type wf.msc and then press Enter to start the Windows Firewall with Advanced Security console. Expand Monitoring and then Security Associations to examine the IPsec SAs established. The authentication methods that are being used are Computer Kerberos and User Kerberos. No certificate-based authentication was needed to establish the single tunnel simplified connection security rule. The client uses the Kerberos proxy automatically deployed by the DirectAccess wizard. Select Connection Security Rules in the console tree to examine the associated policies applied.
16. Close the Windows Firewall with Advanced Security console.

netsh int httpstunnel show int 

netsh int 6to4 show int 

Netsh interface 6to4 set state disabled 

To test remote access from the home network

1. Connect CLIENT1 to the Homenet subnet. As soon as the network determination process is complete, the network icon should indicate Internet access.
2. In the PowerShell window, type Get-DAConnectionStatus and press Enter. The status is displayed as ConnectedRemotely.
3. Click the network icon in the System Notification Area. Workplace Connection is listed as Connected. Right-click Workplace Connection and then click Properties. The Status is displayed as Connected.
4. Type ping app1.corp.contoso.com and press Enter to verify corporate intranet name resolution and connectivity. Again, because there is no IPv6 deployed in the test lab, the dynamically created NAT64 address of APP1 is returned.
5. Start Internet Explorer, and verify that you can access the websites on http://inet1.isp.example.com and http://app1.corp.contoso.com.
6. Click Start, and then click the Windows Explorer icon.
7. In the address bar, type \\app1\Files, and then press Enter.
8. You should see a folder window with the contents of the Files shared folder.
9. In the Files shared folder window, double-click the Example.txt file. You should see the contents of the Example.txt file.
10. Close the example.txt - Notepad and Files shared folder windows.
11. From the PowerShell window, type Get-NetIPAddress and then press Enter to examine the client's IPv6 configuration. You will find the tunnel adapter IPHTTPSInterface is active with a valid IP-HTTPS address. CLIENT1 is using IP-HTTPS to tunnel IPv6 traffic to the EDGE1 server. In earlier versions of DirectAccess, a client that uses a private IPv4 address behind a NAT would connect by using a Teredo IPv6 transition address. The simplified DirectAccess deployment wizard configures IP-HTTPS only.

To monitor the client connection on EGDE1

1. From the Start screen, click Remote Access Management.
2. In the Remote Access Management console, select Dashboard.
3. Examine the data that is collected under Remote Client Status.
4. In the Remote Access Management console, select Remote Client Status.
5. Double-click the CLIENT1 connection to display the detailed remote client statistics dialog box.

1. Inspect the network adapter configuration. First, examine the configuration for the external interface directly connected to the Internet. If you want to enable clients to connect by using Teredo, the DirectAccess server must have two consecutive public IPv4 addresses configured on this external physical interface, and they cannot be behind a NAT device. This is a Teredo client requirement for NAT detection. There should be an external default gateway assigned to this interface, and nothing specified in the DNS connection-specific suffix. If the DirectAccess server is behind a NAT device or has only a single network interface, only IP-HTTPS will be deployed for client connectivity.
2. Next, verify the configuration for the internal interface. This adapter should have a static IPv4 address for the internal IPv4 subnet, and cannot have a default gateway configured. If there are additional internal IPv4 subnets to which the external clients will connect, add static routes for each of them on the server by using either the netsh int ipv4 context or the route add command. You can also use the New-NetRoute Windows PowerShell cmdlet. The internal adapter must have a connection-specific DNS suffix set to match the internal domain name.
3. Check the status of the Windows Firewall. The Windows Firewall must be enabled for all profiles with the default settings of Block Inbound and Allow Outbound. Disabling the Windows Firewall service is never a valid troubleshooting step for DirectAccess and will guarantee that connections fail, because disabling Windows Firewall also disables IPsec. An ICMPv6 Inbound Allow firewall rule must be enabled on the DirectAccess server for Teredo to function.
4. Verify PKI infrastructure and server certificates. For IPsec negotiation, the server must have a valid certificate with Server Authentication purpose installed that is issued by a CA that chains to the root CA to which the client computer certificates also chain. This is the root CA that will be specified in the connection security rules deployed by using GPO. The certificate that is used for IP-HTTPS must also specify a CRL distribution point that is published externally and is reachable by external Windows 7 clients. For simplified DirectAccess deployed with the Getting Started Wizard, the server will have a self-signed certificate created by the wizard.
5. Check membership of the DirectAccess client security group in step 1 of the Remote Access Setup wizard. Use Active Directory Administrative Center to verify that the security group specified in step 1 contains only the computer accounts of Windows 7 (Ultimate or Enterprise) or Windows 8 Enterprise clients. If there are any users, internal servers, or groups that are listed, remove them to prevent the client-specific settings from being applied to them by using GPOs.

1. In the Remote Access Management console, select Operations Status. Note the status indicators for DirectAccess Server components. Investigate any components not displaying a green check and status as "Working."
2. On the DirectAccess server, use the Windows Firewall with Advanced Security snap-in (wf.msc) to verify that DirectAccess connection security rules are applied and active. If the DirectAccess Policy-DaServerToCorp and DirectAccess Policy-DaServerToInfra rules are not present, update Group Policy with the command gpupdate /target:computer /force.
3. Open Monitoring\Security Associations. Examine the Main Mode and Quick Mode nodes for security associations established by test clients.

1. Verify that the client computer account is a member of the Active Directory security groupspecified in the Remote Access Setup Wizard step 1. A common customer scenario is to test with a remotely connected client over a VPN connection. This will update the GPO settings, but will not update computer account group membership.
   
   DirectAccess client policies are applied by using GPO to the root of the domain and then security filtering is used to limit applying the GPO to only members of a security group that is defined in AD for the client computers. If the client computers are not already members of this group, they must be connected to the internal network and restarted to update their computer group membership.
   
   Another workaround to use (if it is not practical to connect directly to the LAN) is to instead kill all the Kerberos tickets on the client and then do a gpupdate /force. This will force the computer to reauthenticate, obtain its new group membership, and obtain the previously-filtered GPO.
   
   The command to flush a computer account’s Kerberos tickets is Klist –li 0x3e7 purge.
2. Check the status of the Windows Firewall. The Windows Firewall must be enabled for all profiles with the default settings of Block Inbound and Allow Outbound. Disabling the Windows Firewall service is never a valid troubleshooting step for DirectAccess and will guarantee that connections fail, because disabling the Windows Firewall service also disables IPsec.
3. Unless simplified DirectAccess is deployed and Kerberos proxy is used, verify that the computer has a valid computer certificate issued by a CA that chains to the root CA specified in the DirectAccess connection security rules. The Certificate must contain the Client Authentication EKU and must have the computer account DNS name in the Subject Alternative Name field.
4. Verify that the NRPT is appliedby using GPOs. Use the command netsh name show pol or the Windows PowerShell cmdlet Get-DnsClientNrptPolicy to display the Name Resolution Policy Table.
5. Use the following Windows PowerShell cmdlets to verify DirectAccess configuration settings:
   Get-DnsClientNrptPolicy
   Get-NCSIPolicyConfiguration
   Get-DAConnectionStatus
   Get-DAClientExperienceConfiguration

Client Troubleshooting

1. Run tthe Ipconfig /all command or the Get-NetIPAddressWindows PowerShell cmdlet to verify that the client has a valid, globally routable IPv6 address. The address may be native, 6to4, Teredo, or IP-HTTPS. Use the following commands to see the status of each:
   Netsh int 6to4 show state
   Netsh int teredo show state
   Netsh int httpstunnel show int
   Get-Net6to4Configuration
   Get-NetTeredoState
   Get-NetIPHTTPSConfiguration
2. Run the command Netsh dnsclient show state to determine the results of network location detection (the Machine Location field). Examine Network Connectivity Status Indicator (NCSI) operational logs in Event Viewer.
3. From the output of netsh name show effectivepolicy or Get-DnsClientNrptPolicy, copy the IPv6 address of the internal DNS server specified. Ping this internal DNS address to verify IPv6 connectivity. If no connectivity exists, this must be corrected before continuing. Investigate routing and firewall configurations, and reference the external and internal firewall settings required at the TechNet link for Firewall Exceptions for DirectAccess.
4. Ping an internal host name to verify name resolution. If the name resolves to an IPv6 address, this indicates that the first (Infrastructure) IPsec tunnel is up. Try to access an internal share on a server other than a DNS, DC or Management server. If this is successful, then the second (Intranet) IPsec tunnel is also up.
5. Examine the IPsec Main Mode security associationsby running the Netsh adv mon show mmsa command or the Get-NetIPsecMainModeSA Windows PowerShell cmdlet. You can also use the WFAS Monitoring\Security Associations\Main Mode node on both the client and DirectAccess server.
6. If you have a valid IPv6 address and can ping internal IPv6 addresses, but one or both IPsec tunnels are not established successfully, you can collect DirectAccess scenario and WFP tracing information to investigate further.
   
   Use the following process from an elevated command prompt to capture the tracing files:
   Netsh trace start scenario=directaccess capture=yes report=yes tracefile=C:\datrace.etl
   Netsh wfp capture start file=C:\wfpdiag.cab
   
   Note To enable a tracing session that will survive a restart of the client, use the command Netsh trace start scenario=directaccess capture=yes report=yes persistent=yes tracefile=C:\datrace.etl.
   
   Reset the network adapter, and then try to connect to an internal share to reproduce the failure. Turn tracing off with the following commands:
   Netsh wfp capture stop
   Netsh trace stop