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:

• NAT64 – this feature allows the IPv6 communications from the DA client to the DA server to be NATed from an IPv6 address (the DA client) to a IPv4 address (the destination server)
• DNS64 – this feature allows the DA client to believe it’s connecting to an IPv6 host when connecting to an IPv4 server on the IPv4 only network. DNS64 on the UAG DA server will send a DNS query for the name requested by the DA client, and then replace an IPv6 address for the IPv4 address returned by the DNS query and forward the IPv6 address to the DA client. The DA server stores this IPv4 to IPv6 address mapping. When the DA client tries to connect to the IPv4 only resource, it uses this mapped IPv6 address to connect. The DA server then forwards the connection to the IPv4 address associated with the IPv6 using NAT64

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:

• Any application protocol that imbeds IP addresses in the protocol header may not work, since the NAT64 feature doesn’t include NAT editors for any specific application protocol. This is especially problematic when there are IPv4 addresses imbedded in the application layer header
• You cannot fully “manage out” DA clients when NAT64 is required, because our implementation of NAT64 doesn’t enable “reverse NAT” mappings.

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.

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

What might make the NLS server unreachable? Consider the following:

• The web servers that that host the NLS URL are offline
• Network connectivity between the DA client and the NLS server is disrupted, perhaps due to a router failure or problems with the routing tables or other components of the routing infrastructure, such as failed cables or switches
• Misconfiguration of the DNS host record entry for the NLS server name or IP address
• Network connectivity issues between the DA client and the DNS server hosting the A record for the NLS server
• Issues with the web site certificate installed on the NLS servers, such as an expired certificate or a revoked certificate
• Issues with contacting the server(s) hosting the Certificate Revocation List – the DA client must be able to access the CRL in order to establish an HTTPS connection to the NLS
• For branch office users, perhaps a WAN link failure, or failure of a site to site VPN could prevent name resolution for the NLS server, or prevent access to the NLS server, or prevent access to the server(s) hosting the CRL

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?

• The DA client will assume that it still on the outside, and the NRPT will be used to determine what DNS server to send name query requests to, and the DA client will not use the DNS server address configured on its NIC. In a UAG DA environment, that means that the DA client will send name query requests to the UAG DA server’s DNS proxy component, using the IPv6 address of the UAG DA server. Name query requests are for the names configured on the NRPT, which will include the names on the corpnet, with an exemption for the NLS, so that it will use its locally configured DNS settings on the NIC to find the name of the NLS server (which won’t help in this circumstance, since some other issue is causing the DA client to not connect to the NLS server).
• The Domain profile will not be activated, and either a public or private profile will be enabled, depending on which network type the user selected when connecting to the corpnet (private profile for home/work and public profile if the user selected public). This means that the DA client computer will try to connect to corpnet resources over the UAG DA server, by using the IPsec tunnels that are defined in the DA clients Connection Security Rules.

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?

• The client tries to resolve the FQDN of an internal resource. The DNS server on the corpnet cannot be contacted, since the UAG DA client isn’t able to connect to the UAG DA server’s DNS proxy, so the connection times out. There is no fall back for FQDNs, so the chosen fall back mechanism doesn’t activate. End result: failed connection attempt.
• The client tries to resolve a single-label (local) name on the internal network. In this case the client will first fully qualify the single-label name with it’s own domain name (that is to say, the name of the domain that the DA client belongs to, since all DA clients must be domain members) and any DNS suffixes that the client might have been configured to use. Since the DA client won’t be able to contact the UAG DA server’s DNS proxy, the DNS queries will time out and fail. However, since this was a single-label name query, fall back will take place based on the method you choose when you set up DA on the UAG server. The fall back mechanism also depends on the type of network the user chose when connecting to the corpnet. Check out http://blogs.technet.com/tomshinder/archive/2010/04/02/directaccess-client-location-awareness-nrpt-name-resolution.aspx where I talk about the fall back mechanisms in more detail. There are a number of factors involved with fall back, such as whether the resource is on the local link, and whether or not a WINS server is available and has a name mapping for the requested resource.

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 DA client establishes the IPsec tunnels to the external interface of the UA DA server
• The client connects to corporate resources through these tunnels, both the intranet and the infrastructure tunnels
• The requests are forwarded through the UAG DA server to the destination server on the corpnet
• The destination server responds to the request and the response is routed back through the DA server
• The response makes it back to the DA client through whatever gateway the DA client used to send the outbound request

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.

Preparing and Preventing Failure

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?

• Make sure your NLS servers are highly available – use NLB or an external load balancer
• Have a certificate lifecycle management process in place and pay strict attention to that management process so that certificates do not expire
• Make sure that your CRLs are highly available – a highly available deployment of NLS servers is of little use if the CRL is not available.
• Locate your NLS servers at multiple locations so that a single point of network failure does not impact the DA clients; consider installing NLS servers at branch offices where the risk of WAN failure is relatively high
• Review DNS record management processes and point out that the NLS server is a high priority name, on par with the names of the domain controllers and other critical network assets

There are some additional measures you can take to make sure that NLS failure causes the least disruption as possible:

• Think about what fall back setting is best for your organization. While the default setting is a balance between security and accessibility, you might want to favor the latter over the former, depending on your assessment of the actual security risks imposed by allowing DA clients to broadcast names over untrusted networks when single-label name resolution fail over occurs.
• Deploy the DirectAccess Group Policy Objects and settings only to computers that will act as DirectAccess clients. This is a critical point of distinction and worth repeating early and often. This means that you need to create custom groups to apply these Group Policy settings, or at least create custom OUs for the settings. Don’t apply the DA GPO settings to any of the default groups, and don’t apply them to machines that will never act as DA clients, such as servers and domain controllers.
• Train your users on what to do in the event that a DA failure occurs. The DirectAccess Connectivity Assistant (DCA) which you can download at http://www.microsoft.com/downloads/details.aspx?FamilyID=9A87EFE8-E254-4473-8A26-678ADEA6D9E9&displaylang=en will inform users when there is a problem with the DA connection. Users can then right click the DCA icon in the system tray (notification area) and click Prefer Local DNS Names. When the users select this option, the DA related entries in the NRPT are removed, and the DA client will then be able to resolve names using the the DNS server address configured on the DA client’s NIC, and will connect to resources using their IPv4 address. Note that when there’s a connectivity change (network status change) the normal DA client behavior will start again, and if the DCA continues to show connectivity issues, the user will need to enable the Prefer Local Names option again.

Summary

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.

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)

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.

• DA client off the corporate network – DA client components are turned on
• DA client on the corporate network – DA client components are turned off
• When the DA client components are turned on, the DA client tries to reach corporate resources though a connection through the DA server.
• If the DA client components are not turned on, then the DA client connects directly to the resources.

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.

The Name Resolution Policy Table (NRPT)

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:

• *.corp.contoso.com This entry will cause all DNS queries for the corp.contoso.com domain to go to the UAG DA server for name resolution using the UAG DA DNS proxy that is installed on the UAG DA server.
• nls.corp.contoso.com This entry is an NRPT exemption entry. The purpose of this entry is to make sure that even though the FQDN would qualify as part of the first entry (that is to say, nls.corp.contoso.com would match the first entry and therefore queries for this name would be sent to the UAG DA server), the query will not be sent to the UAG DA server for name resolution because there is an exemption rule for this name. This prevents the DA client from using the UAG DA server DNS proxy to resolve the NLS server name on the internal network, and therefore prevents the DA client from thinking that it’s on the corpnet when it is not.

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.

Name Resolution for the DA client when the NRPT is Active

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):

1. The user needs to connect to a resource using a FQDN and enters that name into the application, or the application might already be configured to connect to that FQDN in some automated way.
2. However, there might be times when the user or the application needs to connect to the resource using a single-label name, and not the FQDN. In this case, the DNS client resolver will append a DNS suffix to the request. By default, the client will append the DNS suffix based on the DA client’s domain membership. But in many cases, you will have configured a DNS suffix search list – and so the single-label name will be appended with those DNS suffixes as well.
3. The FQDN, or the single-label name with the appended DNS suffix, will be compared to the entries in the NRPT. So, if the application needs to connect to exchange.corp.contoso.com is would see that it matches the first entry in the NRPT shown above, and the DNS query would be sent to the DNS proxy on the UAG DA server for name resolution on the corpnet. If the DA client were a member of the corp.contoso.com domain, and the request was for EXCHANGE (single-label name), then the default DNS suffix for that client (assuming that the DA client belongs to the corp.contoso.com domain) will be for exchange.corp.contoso.com and that will match the first rule in the NRPT as shown above. If the name the application is seeking for is nls.corp.contoso.com then it will match the second entry on the NRPT, and since this is an exemption rule, it will not send the request to the DNS proxy on the UAG DA server and instead will send the DNS query request to a DNS server configured on the DA client’s NIC for public address name resolution.
4. For single-label names, if after queries with the appended DNS suffixes fail, name resolution will continue using Local Link Multicast Name Resolution (LLMNR) or NetBIOS name resolution (if available, which includes WINS name resolution if the client is configured to use a WINS server, and depending on the NetBIOS Node Type of the client). For more information about LLMNR, check out http://technet.microsoft.com/en-us/library/bb878128.aspx

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.

Conclusion

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.

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)

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:

• Placing the UAG DA server between a front-end and back-end firewall
• Place the UAG DA server in parallel with your front-end firewall
• Place the UAG DA server behind a front-end firewall, with no back-end firewall

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:

• Allow TCP destination port 443 inbound to and TCP source port 443 outbound from the external interface of the UAG DA server (this is required to support the IP-HTTPS IPv6 transition protocol that enables IPv6 messages to be tunneled over the IPv4 Internet)
• Allow destination port 3544 inbound to and UDP source 3544 outbound from the UAG DA server’s external interface (this is required to support the Teredo protocol, which is another IPv6 transition technology that allows you to tunnel IPv6 messages over an IPv4 Internet)
• Allow IP protocol 41 inbound to and outbound from the UAG DA server’s external interface (this is required to support the 6to4, which is yet another IPv6 transition technology that enables IPv6 messages to be sent over an IPv4 Internet).

The back-end firewall must be configured to:

• Allow IP protocol 41 inbound to and outbound from the UAG DA server’s internal interface (this is to allow ISATAP messages to be communicated between the UAG DA server and machines on the corpnet)
• Allow all IPv4 and IPv6 traffic inbound to and outbound from the UAG DA server’s internal interface (this should be thought of a starting place, because most organizations aren’t aware of their traffic profile, and limiting the protocols could cause service disruptions)

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.

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