While DirectAccess seems like an attractive proposition to most network admins, there is often a concern about IPv6. These admins have read about the Windows Server version of DirectAccess (DA) and they’re concerned that they’ll need to upgrade their servers and configure their routers and other network gear to support IPv6. In other cases, network security personnel have issued edicts stating that “no IPv6 will traverse our networks”.
Will DirectAccess work in a no IPv6 environment? What do I mean by a no IPv6 network? I mean that you either have no computers or applications that are IPv6 aware, or you have machines and applications that are IPv6 aware, but do not take advantage of IPv6 transition technologies (such as ISATAP, which is typically used on a network that has IPv6 capable hosts, but the entire network isn’t IPv6 capable yet).
----------------------------------------------------------------------------------------- Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag -----------------------------------------------------------------------------------------
DirectAccess will work in an IPv4 only network, but only if you deploy DirectAccess with Forefront UAG. The reason why you can have a no IPv6 (or a IPv4 only network, it’s the same thing) network using UAG DA servers is that UAG includes two key pieces of functionality not included with the Windows only DA solution that allow the DA client to connect to a IPv4 only network:
However, like any other NAT based solution, there are going to be some limitations. That’s just the nature of NAT. When using NAT64 to enable your DA clients to connect to your IPv4 only network, there are several issues of which you need to be aware:
Note that I say that you cannot “fully” manage out DA clients. The reason why I say this is in the vast majority of management scenarios, there is an agent on the client that calls the management server and uses a “pull” method to receive updates, configuration information and other settings that are required to make the DA client a fully managed client. This works fine with NAT64. However, if you want to initiate the connection from a management computer located on the corpnet, that won’t work, because that would require a reverse NAT mapping and we don’t have that capability at this time.
There are also some corner-case issues that might take place on an IPv4 only network. For example, if the DA client is able to resolve the name of the IP-HTTPS when it is on the corpnet, and is able to reach the IP-HTTPS listener, the IP-HTTPS adapter on the DA client will stay up. This can have some unintended side effects that I’ll share with you in a blog post in the near future.
For more information on NAT64/DNS64, check out:
http://blogs.technet.com/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
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
In a recent article on The Edge Man blog, I talked about the Network Location Server (NLS) and how it’s used to help the DirectAccess (DA) client determine if it’s on or off the corporate network. If you missed that article, or need a refresher, check it out at http://blogs.technet.com/tomshinder/archive/2010/04/02/directaccess-client-location-awareness-nrpt-name-resolution.aspx
Now that you have a basic understanding of what the NLS server does and its critical role in a DirectAccess solution, the next step is to figure out what happens when the NLS server is unreachable by the DA client when the DA client is on the corpnet.
What might make the NLS server unreachable? Consider the following:
There are probably many other things that could cause problems when the DA client tries to connect to the NLS server. If this happens, what is the result?
What happens at this point is determined by whether or not the DA client on the corpnet has connectivity to the UAG DA server on the Internet. That is to say, the results differ depending on whether or not the DA client on the corpnet can connect to the external IP address on the UAG DA server.
What happens when the DA client is not able to connect to the UAG DA server’s external IP address when a connection to the NLS fails?
Next, what happens when the DA client is able to connect to the external interface of the UAG DA server? Remember, the UAG DA server cannot enable outbound connections from hosts on the internal network, not even outbound connections from its internal interface to its external interface. That means that some other gateway on the network must be available to allow the connection to the external interface of the UAG DA server.
In this case the DA client tries to connect to the resource first by using a FQDN. Depending on the connectivity the DA client has with the external interface of the UAG DA server, the client might use Teredo or IP-HTTPS to bounce back to the internal network through the UAG DA server. Since the DA client can connect to the UAG DA server’s DNS proxy, it will be able to resolve the name of the internal network destination host.
However, the request/response path is not going to be efficient:
The request/response path will look something like this (from a very high level view):
As you can imagine, performance is likely to suffer, depending on the number of interposed devices and the traffic profiles on the networks that the packets have to traverse. Also, there are a number of potential points of failure, which doesn’t help either. However, this scenario does allow the DA clients to connect to corporate resources in the event of a NLS failure, which could buy you time while you’re trying to fix the primary problem.
The fact is that bad things happen to good computers. Server failure is not a matter of “if” it will happen, it’s a matter of “when” it will happen. Since you know that your NLS servers and all the other dependent components are going to fail at some point in time, what can you do to mitigate these failures and have your users experience the least amount of pain during the event?
There are some additional measures you can take to make sure that NLS failure causes the least disruption as possible:
The Network Location Server allows the DA client to know when it’s on or off the corpnet. However, when there is an issue preventing the DA client from connecting to the NLS server when the DA client is on the corpnet, the client will act as if it off the corpnet, and this can cause a number of problems, depending on the current network configuration and whether or not the DA client can reach the external interface of the UAG DA server when the DA client is on the corpnet. This article summarized a number of things you can do to mitigate NLS connectivity failures and help insure that these failures have less negative impact on network operations and your users when they occur.
In the near future we will publish a white paper on this issue and it will expand a bit on what I’ve covered in these two blog posts on Network Location Servers. I’ll make sure to post the URL to that paper on this blog when it becomes available.
(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)
In order for the DirectAccess (DA) client to determine whether to turn on it’s DirectAccess client configuration (which connects the DA client to the DA server), it must know if it is on the corporate network or not. If the DA client is not on the corporate network, then the DA client components are turned on, and if the DA client is on the corporate network, then the DA client components are not turned on.
The DA client uses a Network Location Server (NLS) to find out if it is on the corporate network. The NLS is a web server that is accessible only when the client is on the corporate network. That means there must never be a DNS entry on the public Internet that matches the name of your NLS server. For example, if the name of your NLS server is nls.contoso.com, then that name must not be resolvable by any public DNS server. However, that name must be resolvable by your internal NLS servers.
The URL used to connect to the NLS server is contained in the Registry of the DA client, and this setting is delivered over Group Policy. The Registry setting is stored at:
HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\ CorporateConnectivity\DomainLocationDeterminationUrl
and is pictured in the figure below.
The DA client always assumes that it is on the outside. Whenever the DA client detects that there has been a network status change (such as when the network interface is unplugged and then plugged in again, or after waking from sleep), the DA client tries to connect to the NLS server URL over an HTTPS connection. If the DA client receives a 200 HTTP success code, then it assumes that it on the corporate network and will then use Network Location Awareness to determine if it should switch the the domain profile. NLA is part of the users decision making process when they select “which type of network are you on” when they change networks. When they choose the “work network” the Domain Profile (part of the Windows Firewall with Advanced Security) is enabled, which turns off the DA client components.
NOTE: In order to successfully connect to the NLS server, the DA client must have access to the CRL location(s) listed on the web site certificate presented by the NLS server. If the CRL checks, then the connection will fail, and the DA client components will remain enabled, even if the DA client is on the corporate network.
This is an important point to understand. The DA client configuration is driven by Group Policy settings and Windows Firewall for Advanced Security. The Windows Firewall with Advanced Security maintains three profiles: public, private, and domain. When the client is on a public or private network, the DA client components are enabled via the WFAS configuration for those profiles. When the DA client is on the corpnet and the domain profile is enabled, the DA client settings in WFAS are disabled.
When the DA client has disabled its DA client components, it resolves names based on the DNS server IP address settings on its NIC. However, when the DA client has enabled its DA client configuration, name resolution depends on the settings on the Name Resolution Policy Table or NRPT.
The NRPT provides a form of “DNS server routing” based on the names configured on the NRPT. You configure the NRPT during the setup of the Windows DA server or the UAG DA server. The figure below shows the configuration interface for the NRPT using the UAG DA wizard. Notice that there are two entries in this example:
NOTE: The UAG DA server DNS proxy is a component of the UAG DNS64 feature set. You can learn more about this feature at http://blogs.technet.com/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
If a name does not match any entry on the NRPT, then the name resolution request is sent to the DNS server configured on the DA client computer’s NIC. Since public DNS servers do not contain entries for your private network addresses, connection are made to public servers over the local connection the client has to the Internet and not over the DA link to the UAG DA server.
Let’s take a closer look at what happens when the NRPT name resolution policies are active (and remember that they are only active when the DA client components are turned on):
At this point things get a bit more tricky, because name resolution fallback depends on what type of name was queried for initially. This relates into the options seen on the bottom of the figure above and reproduced in the figure below. If the original query to the UAG DA server was for a FQDN and the query fails, then that’s it and there’s no fall back. However, if the name query was for a single-label name (note that the user interface assumes that you know that local name resolution is the same as “single-label name”), then there are three fall back options for name resolution.
Fall back for single label names will always happen if the client receives a “name not found” response from the UAG DA DNS proxy.
However, if the Fall back to local name resolution if the name does not exist in DNS or the DNS servers are unreachable when the client computer is on a private network (recommended) option is selected, fall back will take place if the name doesn’t exist in DNS or if DNS server isn’t reachable and the user selected the “Home” or “Work” option for the type of network their connected to. (that is to say, they didn’t select the “public” network option).
However, if the Fall back to local name resolution for any kind of DNS resolution error (least secure) option is selected, fall back will also take place for any kind of DNS query error and will take place if the user is located on a public Network. As you can imagine, this can be a bit problematic if you’re concerned about your private names being broadcasted to the DA client’s local link. A determined attacker might be able to leverage this information in a focused attack on your network.
It’s worth repeating that fall back only takes place for single-label names and never takes place for FQDNs. Another thing to be aware of is that LLMNR only works on the local segment (similar to NetBIOS Name Query broadcasts) and that NetBIOS name resolution only works on the local segment (actually subnet) unless a WINS server is configured, and it’s unlikely that the client is going to be assigned a WINS server that’s going to resolve the name of the server the client is actually interested in, and if there is a name match in WINS, it’s almost impossible that this is going to be the correct computer, since the DA client computer is not located on the corpnet.
At this point you now should have a better understanding of the Network Location Server and how its used to determine whether the DA client is on or of the corpnet. You should also understand how DNS query behavior changes when the DA client components are enabled – and that the NRPT determines what DNS server will be used to service a DNS query when the DA components are enabled on the client.
In the next blog post on network location awareness and detection, we’ll build on this understanding and looking into what happens when the DA client is unable to determine if it’s on the corpnet, and what happens to corpnet located clients when they are not able to turn off their DA client configuration.
A question that I see frequently regarding UAG DirectAccess is “what topology options are available to me? Where’s the best place to put the UAG DA server?”. As with all questions of this type, the answer depends on what your requirements are and what you existing infrastructure looks like.
While there’s probably an unlimited number of options available for placement of the UAG DA server, I think there are three general scenarios on which you can build out a deployment plan. These three scenarios are:
Figure1 show a high level overview of what the UAG between a front-end and back-end firewall configuration would look like. Of course, the nature of the DMZ between the firewalls might be more complex than this. In the figure, I describe only a single segment in front of the UAG DA server and a single segment behind the UAG DA server. Typical enterprise networks will have multiple segments on their DMZs.
In this configuration the front-end firewall must be configured to:
The back-end firewall must be configured to:
We assume that this is going to be the most common deployment model for the UAG DA server, and that’s why you’ll see it as the only one described on TechNet. Something that should be made clear at this point is that just because this is the only deployment model described on TechNet doesn’t mean that it’s the only supported configuration. The following two configurations to be discussed are also viable options and are supported.
Figure 1: UAG DA server placed between two firewalls
Figure 2 describes a deployment model where the UAG DA server is placed in parallel with the front-end firewall. This is a secure option because the UAG DA server and the network behind it are protected by the TMG firewall that is also installed on the UAG DA server. It’s important to note that while the TMG firewall is installed on the UAG DA server, it is not to be used outside of its ability to protect the UAG DA server and the network behind the UAG DA server. No outbound traffic is supported through the UAG DA server, and no DMZ NICs are supported on the UAG DA server (by DMZ, I refer to the fact that TMG supports an unlimited number of network interfaces; the UAG DA server will always have only two interfaces).
In this configuration, the UAG DA server does not require any packet filters on a front-end firewall, since there is no front-end firewall in front of the UAG DA Server. The UAG DA server sits in parallel with the current firewall. In addition, there is no back-end firewall, so no filters need to be configured on a back-end firewall.
One could argue that just because you have the UAG DA server sitting in parallel with the current front-end firewall, then way not put a back-end firewall “just in case”. There’s no reason why you can’t do that. However, noting the packet filters used on the back-end firewall in the first scenario, there’s really no point in placing another point of failure between the UAG DA server and the resources behind it – since the back-end firewall is essentially allowing all traffic between its internal interface and the corpnet behind it.
Figure 2: UAG server placed in parallel with front-end firewall
Figure 3 represents the third general deployment option. In this scenario, the UAG DA server sits behind a front-end firewall with no back-end firewall behind it. In this configuration, the packet filters for the front-end firewall as the same as those applied in the first scenario. And the back-end packet filters don’t apply, since there is no back-end firewall. This might be considered the preferred solution by many organizations, since the packet filters required on the back-end firewall (at least at the beginning of the deployment) essentially allow all traffic between the internal interface of the UAG DA server and the corpnet. I suspect that this will be a persistent configuration in most organizations, so why not simplify the configuration and delete a point of failure by eliminating the back-end firewall entirely?
Figure 3: UAG server placed behind front-end firewall with no back-end firewall
It’s important to note that all of these are supported deployment scenarios and none is necessarily superior to the other. However, there may be performance advantages to putting the UAG DA server behind a front-end firewall, since this will reduce that packet processing overhead on the UAG DA server and end up improving the overall performance of the UAG DA solution. A similar argument can be made for the back-end firewall, but that can only be said if you have worked up your traffic profiles and know what traffic is going to be required between the UAG DA server and all the servers and other networked devices the UAG DA clients are going to connect to on the corpnet.
Finally, be aware that these are simplified diagrams that only include the salient components of the deployment model. There are going to be other network devices that you need to take into account, like bandwidth shapers, Network IDS devices, layer 3 switches that might do more than layer 3, and other devices. While you’ll need to take those into account in your overall design, they don’t impact the basic designs discussed in this article.