This topic provides information about planning Internet access for DirectAccess clients in your Forefront Unified Access Gateway (UAG) DirectAccess deployment.

Overview

DirectAccess clients can access the Internet in one of two ways:

  • Split tunneling—DirectAccess client traffic to the intranet is sent over the IPsec intranet tunnel to the Forefront UAG DirectAccess server. Traffic to the Internet is sent directly to the Internet using IP address settings configured on the network adapter of the DirectAccess client computer. The advantage of split tunneling is better performance for both DirectAccess client computers that are not required to route Internet requests via the DirectAccess server, and for corporate users, because Internet traffic from DirectAccess client computers is not consuming Internet bandwidth.

  • Force tunneling—All DirectAccess client traffic that is not destined for the local subnet is sent via the Forefront UAG DirectAccess server over the intranet tunnel, including Internet traffic. When force tunneling is enabled, the following occurs:

    1. Force Tunneling-enabled clients will still be able to access any resources on their local subnet, such as network printers, but any network traffic beyond the local subnet must be IPv6 traffic.

    2. Teredo and 6to4 traffic is blocked by Forefront TMG running on the Forefront UAG server.

    3. The IP-HTTPS interface status is changed from automatic to enabled.

    4. DirectAccess clients use IP-HTTPS to obtain IPv6 connectivity to the Forefront UAG DirectAccess server over the IPv4 Internet. IP-HTTPS connections have lower performance and higher overhead than 6to4 and Teredo-based connections. The DirectAccess clients and server must negotiate and use both IPsec encryption, and the SSL session. In addition, IP-HTTPS has a much higher protocol overhead, meaning that the space available for the payload for each packet is smaller, and more packets are required to send the same amount of data.

      Note:
      As all traffic is passed through the Forefront UAG DirectAccess server, this also increases the load on you wide area network infrastructure.
    5. The only locations that a DirectAccess client can reach by default with IPv4 traffic are those on its local subnet. All other traffic sent by the applications and services running on the DirectAccess client is IPv6 traffic sent over the DirectAccess connection. Thus, IPv4-only applications on the DirectAccess client cannot be used to reach Internet resources.

When deploying DirectAccess split tunneling is the default setting, and does not require explicit configuration. Force tunneling is an optional setting that can be configured during DirectAccess deployment.We recommend that you only use force tunneling if required by your corporate policy. For example, if your network security policy requires all client traffic to go through a corporate Web proxy.

Requirements

When using split tunneling the only requirement is that the client computer must have network settings to allow Internet access and DNS name resolution.

Requirements for force tunneling include the following:

  1. With force tunneling enabled, connectivity to the IPv4 Internet must be done through intranet devices that translate the IPv6 traffic from DirectAccess clients to IPv4 for the Internet. Otherwise, DirectAccess clients will not have access to IPv4 Internet resources. One of the following solutions should be used:



    1. Deploy a dual protocol (IPv4and IPv6) corporate Web proxy server, which can receive IPv6 requests for Internet resources, and translate them into requests for the IPv4 Internet. Alternately, use a corporate Web Proxy server that can receive IPv4 requests for Internet resources, and use the Forefront UAG DirectAccess NAT64 that receives the IPv6-based requests for Internet resources and translates them to IPv4-based requests for Internet resources.

    2. Alternatively, you can use Forefront UAG DirectAccess integrated NAT64 and DNS64 that translates IPv6 traffic from DirectAccess clients to IPv4 traffic for the Internet.

Limitations

  1. Forced tunneling is not relevant when DirectAccess is deployed for remote client management only.

  2. With force tunneling enabled, you cannot allow DirectAccess clients with the DirectAccess Connectivity Assistant (DCA) 1.5 installed to select to use local DNS name resolution.

  3. If you deploy two-factor authentication (smart card or OTP) and enable force tunneling, users will be required to enter their two-factor authentication credentials even if only accessing the Internet. If you are deploying a Web proxy server to handle the Internet requests, add it to the list of management servers when you configure DirectAccess. This ensure that users will not need intranet access to reach the proxy server. This option is not available if you are using NAT64 and DNS64 to handle Internet requests.

Planning steps

  1. If you want to use split tunneling no prior planning is required.

  2. If you want to use force tunneling plan the following:

    1. If you want to handle Internet requests using a proxy server and not integrated NAT64 and DNS64, deploy a Web proxy server that is both IPv4 and IPv6 capable.

    2. When force tunneling is enabled, settings might be applied to DirectAccess client computers located in the corporate network. To avoid this, do the following:

      1. Ensure that the FQDN of the Forefront UAG DirectAccess server cannot be resolved by internal DNS servers.

      2. If client computer configured with DirectAccess access the internet via a proxy server, configure the proxy not to allow connections to the FQDN of the Forefront UAG DirectAccess server. 

      3. Ensure that the URL of the IP-HTTPS server cannot be resolved inside the corporate network, to ensure that force tunneling is not enabled for DirectAccess clients on the internal network.

      4. When implementing force tunneling with Forefront UAG DirectAccess DNS64, we recommend that you do not configure an external DNS server on the external interface of the Forefront UAG DirectAccess, to ensure that DNS queries for intranet servers are not sent to public DNS servers. As an alternative, intranet DNS servers should also be configured to resolve addresses for Internet resources.