Its seems like we’ve run into a little confusion recently regarding how to deploy the UAG DA server in a firewalled environment.

If you look at our documentation for Packet Filtering for the Internet Firewall (http://technet.microsoft.com/en-us/library/ee809062.aspx) you’ll see that we fully support putting a firewall in front of the UAG DA server.

-----------------------------------------------------------------------------------------
Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag
-----------------------------------------------------------------------------------------

To quote Packet Filtering for the Internet Firewall:

“Most organizations use an Internet firewall between the Internet and the computers on their perimeter network. The firewall is typically configured with packet filters that allow specific types of traffic to and from the perimeter network computers. When you add a Forefront UAG DirectAccess server to your perimeter network, you must configure additional packet filters, to allow the traffic to and from the Forefront UAG DirectAccess server for all the traffic that a DirectAccess client uses to obtain IPv6 connectivity to the Forefront UAG DirectAccess server.

The following describes the type of traffic you can configure on your Internet firewall depending on whether the Forefront UAG DirectAccess server is on an IPv4 or IPv6 Internet.

When the Forefront UAG DirectAccess server is on the IPv4 Internet

Configure packet filters on your Internet firewall to allow the following types of IPv4 traffic for the Forefront UAG DirectAccess server:

• Protocol 41 inbound and outbound—For DirectAccess clients that use the 6to4 IPv6 transition technology to encapsulate IPv6 packets with an IPv4 header. In the IPv4 header, the Protocol field is set to 41 to indicate an IPv6 packet payload.
• UDP destination port 3544 inbound and UDP source port 3544 outbound—For DirectAccess clients that use the Teredo IPv6 transition technology to encapsulate IPv6 packets with an IPv4 and UDP header. The Forefront UAG DirectAccess server is listening on UDP port 3544 for traffic from Teredo-based DirectAccess clients.
• TCP destination port 443 inbound and TCP source port 443 outbound—For DirectAccess clients that use IP-HTTPS to encapsulate IPv6 packets within an IPv4-based HTTPS session. The Forefront UAG DirectAccess server is listening on TCP port 443 for traffic from IP-HTTPS-based DirectAccess clients.

When the Forefront UAG DirectAccess server is on the IPv6 Internet

Configure packet filters on your Internet firewall to allow the following types of IPv6 traffic for the Forefront UAG DirectAccess server:

• Protocol 50—Forefront UAG DirectAccess on the IPv6 Internet uses IPsec Encapsulating Security Payload (ESP) to protect the packets to and from the Forefront UAG DirectAccess server without the encapsulation headers required for IPv6 transition technologies. In the IPv6 header, the Protocol field is set to 50 to indicate an ESP-protected payload.
• UDP destination port 500 inbound and UDP source port 500 outbound—Forefront UAG DirectAccess on the IPv6 Internet uses the Internet Key Exchange (IKE) and Authenticated Internet Protocol (AuthIP) protocols to negotiate IPsec security settings. The Forefront UAG DirectAccess server is listening on UDP port 500 for incoming IKE and AuthIP traffic.
• All ICMPv6 traffic inbound and outbound.”

=====================================

However, there has been a cause for confusion in this documentation because some admins confuse firewalling with NAT. While it is true that most firewalls are deployed with NAT enabled, that doesn’t mean you must NAT connections coming through the firewall. In fact, the UAG Infrastructure and Planning Guide (http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=110b4c77-b411-4845-9b82-40a733b17003) states:

“Are you deploying Forefront UAG as a DirectAccess server?─A Forefront UAG DirectAccess server can be located behind a firewall or between a frontend and backend firewall, but note that a public IPv4 address is required, and therefore the server should not be located behind a NAT (Network Address Translation) device” [italics mine]

So to answer the question - “can you put the UAG DA server” behind a front-end firewall, the answer is yes. However, that firewall cannot NAT connections between the DirectAccess clients and the UAG DirectAccess Server.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISDiX/SCDiX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)

When you configure a Windows DA server or UAG DA server-based DirectAccess (DA) solution, the default setting is to enable split tunneling. What split tunneling refers to is the fact that only connections to the corpnet are sent over the DA IPsec tunnels. If the user wants to connect to resources on the Internet, the connection is made over the local link (that is to say, the connection is sent directly to the Internet based on the IP addressing configuration on the DA client computer’s NIC).

The advantage of split tunneling is that users have a much better computing experience, especially when accessing Internet based resources. In addition, users on the corpnet are likely to have a better computing experience when accessing resources on the Internet, since the DA client traffic isn’t consuming corporate Internet bandwidth to connect to Internet resources. The combined advantages of improved DA client and corpnet client Internet computing experience makes it worthwhile to make split tunneling the default configuration for DA client/server communications.

Disable Split Tunneling by using Force Tunneling

However, you might not want to enable split tunneling. If that is the case, then all traffic from the DA client to any resource must go over the DA IPsec tunnels. Traffic destined for the intranet goes over the DA IPsec tunnels, and traffic destined to the Internet also goes over the DA IPsec tunnels. Split tunneling is disabled when you enable Force Tunneling for the DA client connections. Force Tunneling is enabled via Group Policy:

Computer Configuration\Administrative Templates\Network\Network Connections\Route all traffic through the internal network

When Force Tunneling is enabled, all traffic is sent over the DA client tunnel using the IP-HTTPS protocol. IP-HTTPS is one of the three IPv6 transition protocols that the DA client can use to connect to the DA server. The other two protocols are 6to4 (used when the DA client is assigned a public IP address) and Teredo (used when the DA client is assigned a private IP address and has outbound access to UDP port 3544 to the DA server). IP-HTTPS is used when the DA client is assigned a private address and outbound access to UDP port 3544 to the DA server is not available.

The Problems with IP-HTTPS

The problem with IP-HTTPS is that it should be considered, and is instantiated as, a protocol of last resort. There are a number of reasons for this, with the primary reason being that it’s the lowest performing of the IPv6 transition technology protocols. Think about it – the client and server have to negotiate and use IPsec encryption and then also has to negotiate and encrypt the HTTPS (SSL) session. This “double encryption” takes a toll on the processor. In addition, IP-HTTPS has a much higher protocol overhead, so that the area available for the payload for each packet is smaller, requiring more packets to be sent to communicate the same amount of data, thus impairing performance even more.

In addition to the performance issues are the Internet access issues for the IP-HTTPS client. Remember that all communications from the DA client to the DA server are over IPv6. The DA client never uses IPv4 to connect to resources through the DA client/server channel. Because of this, you will need to deploy an IPv6 aware web and winsock proxy server on the network that the DA clients can use to connect to the Internet, or use the UAG DirectAccess solution, which includes an IPv6/IPv4 protocol translator that allows the DA client to connect to Internet resources through a IPv4 web and winsock proxy server, such as the ISA or TMG firewall. This adds more complexity to an already problematic situation.

And there is one more “gotcha” when you use Force tunneling. As I’ve said, all communications between the DA client and server are over IPv6. What this means in practice is that the client application must be IPv6 aware. This is not to say that the server side of the application needs to be IPv6 aware and in most cases the server side will work fine with the help of the UAG NAT64/DNS64 IPv6 protocol translator if the server side is only IPv4 aware – but the client side must always be IPv6 capable.

Thus, Force Tunneling can be a problem in those scenarios where the client side is not IPv6 aware. For example, the Office Communications Server Client (at the time of this writing) is not IPv6 aware. In order for the DA client to reach the OCS server, it will need to use the direct connection to the Internet to connect to the OCS server located on the corpnet. If you try to force the OCS client/server communications over the DA connection, the attempt will fail because the OCS client is not IPv6 aware. Any other non-IPv6 aware client application will fail, as it won’t be able to connect over the Internet because split tunneling is disabled.

Split Tunneling Issues and Considerations

At this point it’s worthwhile to think about split tunneling and the reasons why you wouldn’t want to enable split tunneling to determine if those reasons are actually applicable in a DA client/server solution. It might turn out that the assumptions you made when deciding against split tunneling weren’t as valid as you thought, and that the perceived risks of split tunneling were overstated to the extent that split tunneling may no longer be an issue.

Most network admins developed their opinions regarding split tunneling based on their understanding of how VPN clients work, and in many (most?) cases these opinions were derived from issues that were extant in the early to mid 1990s and with non-Microsoft VPN clients.

What are some of the reasons why you think you need to disable split tunneling? Two of them might include:

• Network security policy requires that all client traffic must go through the corporate web proxy and clients are never allowed to connect to the Internet directly.
  If this is the case, you need to make sure that users aren’t local administrators of their laptops, since a local administrator can disable the Force Tunneling configuration. In addition, you need to be aware that even when Force Tunneling is enabled, users are able to connect to resources before the DA connection is enabled. For example, DA client connections can’t be enabled if the client doesn’t have Internet access, and in some cases the client needs to connect to a portal to get that Internet access – so there is some degree of access available even before the DA client/server connection is established.
• You think that disabling Force Split Tunneling will protect Internet bound traffic since it has to go over the DA connection to reach the Internet
  If this is the reason to disable split tunneling, then it’s not a good one, since the traffic sent to the Internet through one of your corporate proxies to the Internet it as susceptible to detection and interception as any other Internet communication once it leaves your proxy, .

Now let’s examine the relationship to VPN and split tunneling, since this is usually the basis for wanting to disable split tunneling:

• With a VPN configuration, when split tunneling is disabled, users must connect to the Internet over the VPN link. But when the user disconnects from the VPN, that user is able to directly connect to Internet resources. This means that you are comfortable with having that user access the Internet without gateway inspection from time to time – and more likely most of the time, since users typically only connect to the corporate VPN when they need to.
• If the previous is true, then your primary concern is that split tunneling is undesirable because there is some perceived security issue with having a user connected to both the Internet and the intranet (over DA) at the same time.

So the question at this point should be “what are the problems with allowing users to connect to the Internet and the intranet at the same time?” – as this appears to the crux of the split tunneling issue.

• The first issue that most VPN administrators are concerned about when it comes to split tunneling is the prospect of an Internet intruder somehow “routing” a connection from the Internet through the DA client into the intranet. The problem with this reasoning is that it would require bridging to be enabled on the DA client computer, which is not something enabled by default. This prevents any of the forwarding that the VPN admin might be concerned about. You can even use Group Policy to make sure that the user cannot enable connection bridging, assuming that the user even knows how to do this.
• The second issue relates to malware that is run on the VPN client computer. Perhaps the malware is a network worm that can spread to the intranet, or some other type of malware that can gain access to information on the corpnet and bring it to the VPN client. Perhaps the malware could even enable bridging.
• Regarding the second issue, turning off split tunneling does not solve this problem. When you allow clients to connect to the Internet, or to any non-filtered device (USB key, DVD, CD, etc) you have the same risk regardless of whether split tunneling is enabled or not.
• Another thing when considering the second issue is that the software industry as a whole has become very good at dealing with situations where a network is unavailable for a period of time. The malware writers also know this and their code is just as effective in these scenarios. Malware can check-in on a periodic basis to see if there is something accessible on the corpnet, it doesn’t depend on an “always on” connection to be effective. So, the malware checks to see if the intranet is available, when it is, it grabs the information it’s looking for. Then after the VPN connection is dropped, the malware can connect to its “master” over the local connection to the Internet. Again, disabling split tunneling did nothing to prevent this problem.
• Force Tunneling is a more complex solution, and can limit access to resources required by your users. Do the perceived benefits of disabling split tunneling really make up for the productivity losses due to lack of resource access?
• Force Tunneling will be more expensive, since you’ll need to increase the bandwidth available to Internet connections, and scale up your proxy server deployment to handle the additional traffic. You also need to factor in the additional operational costs against the marginal (if any) benefits gained by disabling split tunneling
• Enabling Force Tunneling could reduce Internet accessibility, because there are more components in the path between the client and server. Incremental losses of productivity per user could end up being significant when factored over the entire population of users.

Conclusion

From this assessment, it seems clear that there is only one valid scenario where you would want to disable split tunneling and that’s when you want to force all traffic through the corporate web and/or winsock proxy server so that the traffic is filtered to reduce the risk that malware can be downloaded to the DA client over the Internet. I admit, that if there is a weak link in the DA story, that this is it.

However, this weak link isn’t a DA issue because the fact is that there are no longer any “bolted down” corpnet clients. Most organizations have moved to laptops for their employees, and those mobile devices travel between the Internet filtered corpnet and the non-filtered Internet on whatever external network those clients are connected to. Therefore, unless you’re using a 3rd party solution that enforces Internet access policy to computers that aren’t connected to the corpnet, there is little to be gained by forcing the DA clients over the corporate web filters. Of course, the ideal situation would be to use an Internet based web filtering solution so that the DA clients have corporate web access policy forced on them as well.

Another thing that should be clear at this point is that the issue of “routing” communications from an Internet based host to the corpnet doesn’t happen on Windows clients of today. So that concern, perhaps inherited from the 1990s, is no longer an issue and doesn’t represent a security issue for VPN or DirectAccess clients. Whether the client is connected intermittently (as with VPN clients) or is “always on” (as with DA clients) really doesn’t make a difference in terms of the overall security posture provided by the DA client.

In sum, I highly recommend that you do not disable split tunneling for your DirectAccess clients. The benefits from doing so are virtually none, but the cost, complexity and productivity hits imposed by enabling Force Tunneling can be substantial.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISDiX/SCDiX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

You’re learning about DirectAccess and you like what you see. The next step is to build out a test lab. You can build out your own, or you can let me to the heavy lifting for you and use the UAG DirectAccess Step by Step Guide over at http://technet.microsoft.com/en-us/library/ee861167.aspx You’ll save a lot of time by using the lab I put together for you, and you’ll learn a lot about DirectAccess terminology and configuration issues.

When you do put your Test Lab together, you’ll find that there are a lot of technologies and a lot of steps involved with making it work. The reason for this is that DirectAccess is really a collection of product and platform technologies that work together to create a working remote access solution that we’ve named DirectAccess. All the components of the solution need to be configured correctly for it to work.

And that will likely be your first challenge when you start working with DirectAccess. You’ll have gone through all the steps in the Step by Step guide and BAM! It didn’t work. Don’t worry – a lot of the technologies are probably new to you. That means there’s a good chance that you missed a step. I’ve done it, other DirectAccess experts have done it. Consider this a normal part of the DirectAccess learning process. After you’ve gone through the test lab a few times, all the concepts and technologies will fall into place in your mind and you’ll actually get to a place where you’ll forget what it was like not to understand how all the DirectAccess pieces fit together.

With that in mind, I wanted to take a few minutes to talk to you about using ping to test DirectAccess connectivity. We’re all accustomed to using ping to test connectivity issues – this is something firmly ingrained in all of our years with working with the Windows network operating system. And while you definitely can take advantage of ping to help you troubleshoot DirectAccess connectivity issues, there are a few things that you need to keep in mind about ICMP and DirectAccess connectivity.

DirectAccess Tunnels are IPsec Tunnels

First, remember that DirectAccess uses IPsec tunnels between the DirectAccess client and DirectAccess server to allow DirectAccess clients access to intranet resources. There are two tunnels:

• The Infrastructure Tunnel – the purpose of this tunnel is to allow the DirectAccess client to a subset of servers on the intranet that are required for name resolution (DNS servers) and authentication (domain controllers) and health checking (NAP servers) and remediation (update servers). There may also be other servers you want to include in this list, such as management servers (Configuration Manager). The infrastructure IPsec tunnel is established after both computer certificate and computer account (NTLMv2) authentication is successful. Enabling the user account (normally computer account) access allows the Infrastructure tunnel to come up before the user logs on.
• The Intranet Tunnel – the purpose of this tunnel is to allow the DirectAccess clients access to the rest of the network. It should be clear that DirectAccess is not a firewall solution and should not be considered one. DirectAccess is meant to replicate the intranet experience and the DirectAccess client should be considered the same as any client on the intranet. For that reason, there are no access controls places on the DirectAccess client after the DirectAccess client authenticates with the DirectAccess server. The intranet IPsec tunnel is established after computer certificate and user account (the logged on user) (Kerberos) authentication is successful.

It is commonly said by DirectAccess experts (including myself) that all traffic moving through the DirectAccess client to resources on the intranet is through one of these tunnels. This is true for all traffic except ICMP traffic. In a UAG DirectAccess scenario, IPsec policy is configured to exempt ICMP from IPsec authentication and encryption. Therefore when you ping a resource on the intranet, you are sending those pings outside of the infrastructure and intranet IPsec DirectAccess tunnels.

Now you might be asking yourself “If the ping traffic isn’t going through the DirectAccess tunnels, how it is getting to the intranet”? That’s a good question and unless you’ve been in the IPv6  transition technology game for awhile, the answer is definitely not obvious.

A Tale of Two Tunnels

Take a look at the figure below. What I tried to draw here are two tunnels. The larger tunnel is an IPv6 transition technology tunnel. IPv6 transition technologies can be used to allow the IPv6 communications between the DirectAccess client and DirectAccess server to be carried over the IPv4 Internet. The DirectAccess client can use one of three IPv6 transition technologies over the Internet: 6to4, Teredo or IP-HTTPS. The details of each these isn’t important here.

What is important is to understand is that each of these IPv6 transition technologies tunnel IPv6 packets inside an IPv4 header. Inside of the IPv6 transition technology IPv4 tunnel is the IPsec tunnel – where IPsec is used to authenticate and encrypt the IPv6 packets. When you think about DirectAccess tunnels, you should think of two tunnels – the IPv6 transition technology tunnel and the IPsec tunnel.

The above figure shows that ICMP messages are carried over the IPv6 transition technology tunnel, but that they are outside the IPsec tunnel.  The reason why we decided to do this is to make Teredo work correctly, as Teredo requires ICMP access outside the IPv6 IPsec tunnel to determine what type of NAT device the DirectAccess client might be located.

What are the Issues Related to ICMP Being Passed Outside the IPsec Tunnel?

Because of this decision, you need to be aware of a couple of issues:

• Since the ICMP traffic is not encrypted, it can potentially be read by a device that is IPv6 transition technology aware. This information might be of interest to attackers or other curious individuals. For information on this issue, please see http://technet.microsoft.com/en-us/library/ee809059.aspx Be aware that if you force ICMP through the DirectAccess IPsec tunnels, you will not be able to use Teredo.
• When troubleshooting DirectAccess connectivity issues, the ability to ping resources on the intranet indicates that the IPv6 transition technology is working, but does not provide any information regarding whether or not the infrastructure or intranet IPsec tunnels were established.

Before going into the details of ICMP traffic and troubleshooting, I wanted to point out where the ICMP exemptions for IPsec traffic are configured. In the first figure below you can see the Group Policy Object (GPO) for the DirectAccess servers. When you right click the Windows Firewall with Advanced Security – LDAP {GUID} entry and click Properties, you’ll see what appears in the figure right below it – in the Windows Firewall with Advanced Security dialog box, on the IPsec Settings tab. In the IPsec exemptions frame, you’ll see the Exempt ICMP from IPsec option is set to Yes.

 

 

 

ICMP, Ping and Troubleshooting DirectAccess Connectivity

Now let’s take a look at what happens when the IPsec infrastructure and intranet tunnels fail. In this example, I took a working DirectAccess setup and broke it by configuring the UAG DirectAccess server to use the wrong root certificate for mutual computer authentication. Since the root certificate configured in the UAG DirectAccess configuration points to a root CA that didn’t issue the computer certificates used for computer certificate authentication, all IPsec tunnel connection attempts will fail.

One of the standard things we do when troubleshooting DirectAccess connections is to see if we can ping the 6to4 address of the UAG DirectAccess server itself. You can get this address by using the

netsh namespace show effectivepolicy

command on the DirectAccess client, as seen in the figure below.

Now that we have that address, let’s try and ping it.

Yay! That worked and shows that we have IPv6 connectivity with the DirectAccess server. This proves that at least the IPv6 transition technology is working enough so that we can ping the UAG DirectAccess server side of the Teredo (in this example) tunnel. What it doesn’t tell us is if the other components that allow address to resources behind the UAG DirectAccess server are functional.

To enable ICMP access to resources behind the UAG DirectAccess server, you will need to know the IPv6 address of the resource you want to connect to. This can be an ISATAP address or a native IPv6 address (or as well see later, a NAT64 address). It doesn’t matter which type – what matters is the fact that the DirectAccess client only communicates with the DirectAccess server and the networks behind it using IPv6 (except when NAT64/DNS64 is used, in which case the communications are “NATed” by the UAG DirectAccess server, so that between the DirectAccess client and the UAG DirectAccess server IPv6 is used and communications between the UAG DirectAccess server and the IPv4 resource on the intranet, IPv4 is used).

We can go to the domain controller on the network and use ipconfig /all to check it’s ISATAP address. In this example the ISATAP address of the domain controller (DC1) is 2002:836b:2:8000:5efe:10.0.0.1 so we’ll ping that ISATAP IPv6 address from the DirectAccess client on the Internet.

Yay again! It worked. Now we know that the Teredo tunnel between the DirectAccess client and the DirectAccess server is up, and that the Teredo relay configured on the UAG DirectAccess is working.

What About IPv4 Only Resources – How Do I Ping Them?

What if you’re not using ISATAP and you’re not using native IPv6 addresses behind the UAG DirectAccess server? This is a common scenario where you have an IPv4-only network behind the UAG DirectAccess server. In this case, you’re taking advantage of the UAG DirectAccess server’s NAT64/DNS64 capabilities. If you want to learn more about NAT64/DNS64, I highly recommend you read Meir Mendelovich’s excellent coverage of this subject over at  http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx

The problem we have to solve is how do we figure out what the NAT64 address is of an IPv4 only host? Well, the answer comes from an exceptional blog post by Ben Bernstein over at http://blogs.technet.com/b/edgeaccessblog/archive/2009/10/13/deep-dive-into-uag-directaccess-ipv6-and-directaccess.aspx 

The UAG NAT64 address of an IPv4 only host is:

2002:WWXX:YYZZ:8001:[Hex of IPv4 address] /96 (the /96 means that the prefix is 96 bits of the 128 bit IPv6 address)

The WWXX:YYZZ is the Hex representation of the first of the two consecutive IPv4 public address on the UAG DirectAccess Server. You can figure this out if you like, but UAG has already done this work for you. If you look in the figure above, you can see these components of the IPv6 address:

836b:2: – this is the WWXX:YYZZ Hex representation of the IPv4 address

8000: – this is the value used to represent the ISATAP prefix (this is covered in more detail in Ben’s article if you want more information in this)

What we can do is take this information and build out our NAT64 address for the IPv4 only resource. First, we can define our prefix, which is:

2002:836b:2:8001 /96 (the 8001 value is used to represent the NAT64 prefix)

The last 32 bits of the address is Hex representation of the IPv4 only resource. In this example, the IPv4 only resource has the IPv4 address 10.0.0.4. We convert to this to Hex:

10 = 0a in Hex (8 bits)

0   = 00 in Hex (8 bits)

0   = 00 in Hex (8 bits)

4   = 04 in Hex (8 bits)

Or – 0a00:0004 (32 bits represented by two 16 bit blocks)

Now we can put our prefix and address together and get:

2002:836b:2:8001:0000:0000:0a00:0004 /96

You might be wondering where the 0000:0000 entry came from. First, you need to know that each “block” (the value between the colons) represents 16 bits. There are eight blocks in a 128 bit IPv6 address. We defined the first 64 bits of the NAT64 prefix with the four blocks 2002:836b:2:8001. However, the NAT64 prefix is 96 bits, so we need to add another 32 bits to the prefix to make it add up to 96. We can do this by adding two blocks of zeros. That gives us the 96 bit prefix. Then we just append the Hex presentation of the 32 bit IPv4 address at the end.

NOTE:
There is something called “zero suppression” when describing IPv6 addresses where leading zeros can be left out and where they can be replaced with a double colon “::”. We don’t need to get into that now, but you’ll notice that is done automatically by the operating system when it converts the WWXX:YYZZ and also in the ping responses.

Let’s give it a try.

Yay for a third time! It worked again. This proves that we have ICMP connectivity to both IPv6 and IPv4 resources on the intranet. At this point we must be feeling pretty good, as we’ve successfully pinged the UAG DirectAccess server and a IPv4 and IPv6 resources on the intranet.

But what about traffic isn’t ICMP? A quick check can be done by using the web browser. In the figure below I’m using the ISATAP address of a web server on the intranet. Notice that if you want to use IPv6 addresses in Internet Explorer, you have to surround them with brackets.

This connection fails because it’s using HTTP, which isn’t ICMP. The reason for the failure is that in order to transport HTTP, the DirectAccess IPsec tunnels must be available. And because I broke IPsec, there are no tunnels. You can prove that to yourself by using the Windows Firewall with Advanced Security console and finding no Main Mode or Quick Mode Security Associations. There is a process to troubleshoot IPsec tunnel establishment failure, but that’s not why we’re here today :)

Summary

The key points I want you to remember from this article include:

• DirectAccess uses two tunnels: IPv6 transition technology tunnels and an IPsec tunnels
• ICMP is exempted from IPsec protection
• You can ping the UAG DirectAccess server and resources behind it without establishing an IPsec tunnel
• If the IPsec tunnels do not come up, you will not be able to use any non-ICMP protocol to connect to the the UAG DirectAccess server or resources behind it
• The ability to ping gives you no information about IPsec tunnel establishment.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)

An interesting case came in last week and I thought it would be useful to share it with you all. It’s especially interesting because it covers some not so well documented features of the IP-HTTPS client configuration and how it works.

For those of you who haven’t worked with DirectAccess, or who are in the process of learning about it, IP-HTTPS is a new protocol introduced with Windows 7 and Windows Server 2008 R2 for Microsoft DirectAccess that allows a DirectAccess client to connect to the DirectAccess (DA) server by using HTTP (SSL) as a transport. This enables the DA client to connect to the DA server even when the client is located behind a firewall or web proxy that only allows outbound HTTP/HTTPS.

In this example, the admin had a problem with getting IP-HTTPS connectivity to work. As part of his troubleshooting process, he ran the command

netsh interface httpstunnel show interface

The results were:

Role                       : client

URL                        : https://da.domain.com:443/IPHTTPS

Last Error Code            : 0x103

Interface Status           : no usable certificate(s) found

The problem seemed to be related to the interface status: no usable certificate(s) found.

When the admin checked whether there was a computer certificate installed on the computer, he saw that there was, so it didn’t make sense that there was no usable certificate. Perhaps there was something missing from the computer certificate itself?

To understand the problem, it helps to understand how the computer certificate is used in establishing the IP-HTTPS connection. The DA IP-HTTPS client uses the computer certificate to establish the IPsec tunnel,  just as it does when it’s acting as a 6to4 or Teredo client. However, when acting as an IP-HTTS client, the computer certificate is also used to provide credentials for client authentication when connecting to the IP-HTTPS listener on the DA server.

Client certificate authentication is a default setting on the UAG DA server when the client connects over IP-HTTPS, but it is not a default setting on the Windows DA server. If you want to require client certificate authentication to the Windows DA server (which protects the IP-HTTPS listener against denial of service attacks) you can configure the setting manually by using the information in the article Configure Client Authentication and Certificate Mapping for IP-HTTPS Connections. These instructions will enable the DS Mapper usage feature on the DA server. However, keep in mind that if you are using a UAG DA server, you do not need to do this – the UAG DA wizard takes care of this configuration for you.

You can confirm that DS Mapper Usage is enabled by using the netsh http show sslcert command on the DA server, as seen in the figure below.

Notice the title of that article. Not only does the setting configure Client Authentication, but it also configure Certificate Mapping.

What is this certificate mapping of which I speak?

If you look in Active Directory Users and Computers and right click on a DA client computer account, you will see the Name Mappings option in the context menu, as seen in the figure below.

After selecting the Name Mappings option, you’ll see the Security Identity Mapping dialog box, as seen in the figure below. Here you see that the mapped user account (which is mapped in the Active Directory) is to domain1.corp.company.com/Computers/CLIENT2.

This name maps to the DNS name assigned to the computer account, which you can see in the Properties dialog box of the computer account, as seen in the figure below.

In order for client certificate authentication to work, the subject name or a SAN on the certificate must match the DNS name assigned to the computer account. For example, in the figure below you can see that the first SAN shows the DNS name of the computer, which is the same DNS name used by the computer account for this DA client computer.

So what could cause this problem? It might be that the certificate template used to create the computer certificate didn’t include DNS name of the computer account in the subject name or the first SAN. If you use the default Computer certificate template, you will see that the DNS computer name is used as the subject name in the certificate, as shown in the figure below.

(Note: the certificate above is from a different client computer than those shown in the other figures, that’s why it shows CLIENT1 instead of CLIENT2).

However, if you use a custom certificate or another certificate template to assign the computer certificate, you will need to configure the template so that the DNS name of the computer is included in the subject name or in a SAN entry.

For example, look at the Properties dialog box for the Workstation Authentication certificate template. On the Subject Name tab, you can select the option Build from this Active Directory information option and then select your preferred Subject name format. If you don’t choose the Common Name or DNS Name option, then you’ll want to make sure that the DNS Name checkbox is selected from the Include this information in alternate subject name list. In fact, even if you choose the Common Name or DNS name option, it’s not a bad idea to select the DNS name entry for the first SAN, as there are scenarios that require this.

It is important to note that this is one of the reasons why you want to use an Enterprise CA in your environment, so that this AD mapping takes place automatically. When the UAG DA server receives the computer certificate from the DA IP-HTTPS client, it will use the DNS name to forward to the domain controller for authentication. If this name does not match the name associated with the computer’s account, authentication will fail.

CONCLUSIONS:

• On the Windows DA server, client certificate authentication is not enabled by default for DA IP-HTTPS clients
• On the UAG DA server, client certificate authentication is enabled by default for DA IP-HTTPS clients
• When client certificate authentication is enabled on the DA server, the client must provide a computer certificate to authenticate to the DA server’s IP-HTTPS listener
• The subject name or a SAN on the computer certificate must include the DNS name listed for that computer account in Active Directory
• If the computer certificate does not include the DNS name of the computer, as listed in AD, in its subject name or SAN entry, then you will see that the Interface status will state that there is no usable certificate(s) found after running the netsh interface httpstunnel show interface command
• If you create a custom certificate template to computer certificates for your DA clients, make sure you include the DNS name to be included in the subject name or a SAN name.

Let me know if you have any questions on this and I’ll follow up in another blog post.

[Props to Billy Price for coming up with this solution]

Thanks!

Tom

Tom Shinder
tomsh@microsoft.com
MS ISD iX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)

As a member of the Anywhere Access Team with a primary focus on UAG DirectAccess (DA), one of the questions that I hear a lot relates to the security of the solution, due to the fact that split tunneling is enabled by default.

If you’re a VPN guy, you are probably aware of the issue of split tunneling. When split tunneling is disabled, the VPN client uses the VPN gateway as its default gateway, so that all off subnet communications must go through the VPN gateway. It also prevents the the VPN clients from potentially routing communications between two networks, such as the client’s network and the corporate network.

For this reason, most experienced VPN admins disable split tunneling by default. This has become a habit for VPN admins and they don’t think twice about it. However, what they gain in security is lost in performance for the corporate Internet connection.

The reason for this is that the VPN client must go through the VPN gateway to access Internet content, so that the request/response path for Internet content is from the VPN client, to the VPN gateway, to an Internet gateway on the corpnet, to the Internet, and then the response is returned using the same path in the opposite direction.

As you can imagine, if you have more than a few VPN clients, this could become a major bottleneck on your Internet bandwidth.

The DA team understands this problem very well. If the DA client connection isn’t highly performant, users will likely be unsatisfied with the solution. The productivity gains you expected will evaporate, as users won’t use DA to connect to the corpnet, and they’ll return to their old inefficient ways of working.

So, DirectAccess by default enables split tunneling. All traffic destined to the corpnet is sent over the DA IPsec tunnels, and all traffic destined for the Internet is sent directly to the Internet over the local interface. This prevents DA clients from bringing the corporate Internet connection to its knees.

However, it has left the issue of potential risks of split tunneling in the minds of admins who are considering DA. One option is to use “force tunneling”. You can find out more about force tunneling at http://technet.microsoft.com/en-us/library/dd637812(WS.10).aspx One of the primary disadvantages of force tunneling is reduced performance, especially in the context of reaching IPv4 only resources.

But this begs the question: is DA split tunneling really a problem? The answer is no.

Why? Because the risks that exist with VPNs, where the machine can act as a router between the Internet and the corporate network is  not valid with DirectAccess. IPsec rules on the UAG server require that traffic be from an authenticated source, and all traffic between the DA client and server is protected with IPsec.

Thus, in the scenario where the DA client might be configured as a router, the source of the traffic isn’t going to be the DA client, and authentication will fail – hence preventing the type of routing that VPN admins are concerned about.

HTH,

Tom

Tom Shinder
Microsoft ISDUA
Anywhere Access Team/UAG DirectAccess