This question comes up frequently when introducing admins to UAG DirectAccess. It makes sense, since public IPv4 addresses are getting more difficult to come by and in fact it’s predicted that there will be an exhaustion of the entire IPv4 address space by next month. So, why do you need two public IP addresses on the external interface of the UAG DirectAccess server?

There’s a short answer and a long answer. Let’s begin with the short answer (hat tip to Ben Ben Ari, Senior Support Engineer at Microsoft):

“When the Teredo adapter is active on the DirectAccess client, it will check the Teredo server’s public IPv4 addresses to determine what type of NAT device the client is located behind. The assessment is performed to determine which on of the follow four types of NAT are in use:

1. One-to-one NAT, also known as Full-cone NAT
2. Address restricted cone NAT
3. Port-restricted cone NAT
4. Symmetric NAT

The detection process starts with the Teredo client sending a Router Solicitation (RS) message to the Teredo server’s IP first address (the first of the two consecutive IPv4 addresses on the external interface on the UAG server used by DirectAccess). UAG then replies from the 2nd IP address. If the Teredo client receives the reply, it deduces that the NAT type is “Cone” (option 1 or 2 above). If the client does not receive this reply, then it issues a second RS message, but this time, UAG will reply from its first IP, instead of the second. If the client gets this reply, it now knows that the NAT type is either Port-restricted cone (type 3) or Symmetric (type 4) NAT. 

Next, the client sends a request to the UAG server’s second IP address (which also acts as a Teredo server), and waits for another answer. When the answer comes, if it is from the same IP as the first, this signals to the client that the NAT type is Port-restricted cone (type 3). If they are different, this means that NAT is mapping the same internal address and port number to different external addresses and port numbers, which means that this is a Symmetric NAT (type 4).”

If you want even more detail, this may help check out the Teredo Overview:

http://technet.microsoft.com/en-us/network/cc917486.aspx

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Forefront 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

UAG 2010 (UAG) supports two types of network level SSL VPN:

• Network Connector
• Secure Socket Tunneling Protocol (SSTP)

Network Connector is aimed at legacy clients and SSTP for Windows 7 clients.

Network Connector supports both split and non-split tunneling configurations while SSTP, when accessed through the UAG portal, supports only non-split tunneled connections.

This can be a problematic for firms that want to enable a split tunneled configuration to reduce the bandwidth drain that VPN clients can extract when split tunneling isn’t supported. And with current network security opinions moving away from disabling split tunneling as a security solution (see my articles on split tunneling for more information at http://blogs.technet.com/b/tomshinder/archive/2010/03/02/why-split-tunneling-is-not-a-security-issue-with-directaccess.aspx), it makes sense that admins would want to enable split tunneling for their UAG SSTP clients.

Faisal Hussain provides a solution on his blog and you can find it at:

http://blogs.technet.com/b/fsl/archive/2011/01/26/uag-sstp-split-tunnel.aspx

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

DirectAccess is about being “always-on”. When I start my laptop in the morning, I’m ready to get to work. Even though I don’t work on the Microsoft campus, I’m able to connect to anything I want (that I have permissions to connect to) on the Microsoft intranet without thinking about connecting to an SSL VPN portal, some web application gateway, or a traditional network layer VPN connection. I just start the laptop and BAM! I’m connected. And IT is always connected to me too, so my laptop is always up to date and managed by Microsoft IT.

DirectAccess connections consist of two IPsec tunnels that fire up when the Private or Public Windows Firewall with Advanced Profiles are assigned to the machine configured as a DirectAccess client. When the Public or Private Profile is active, the machine configured to be a DirectAccess client will attempt to establish two IPsec tunnels with the DirectAccess server:

• the infrastructure tunnel
• the intranet tunnel

The infrastructure tunnel is established after computer certificate authentication and computer account NTLMv2 authentication. The infrastructure tunnel allows the DirectAccess client to connect to key resources on the intranet, such as domain controllers and management servers (WSUS, SCCM, SCOM, etc.). Intranet tunnel connectivity enables you to always manage the DirectAccess client, even if the user isn’t logged on to the computer. In addition, the intranet tunnel provides the connectivity required for the user to log on and establish the intranet tunnel.

The intranet tunnel is established after both computer certificate and user account Kerberos authentication is successful. In order to complete the user account authentication (Kerberos), the user needs access to a domain controller. That’s why you need the infrastructure tunnel to come up before the second tunnel can be established. The intranet tunnel cannot be established by using cached credentials on the client.

How Does 3G Connectivity Influence DirectAccess Always-On Connectivity

So what does this all to do with 3G connectivity? Mobile computers with 3G adapters are becoming increasingly popular. These 3G adapters are tremendously convenient, as you no longer need to depend on being able to connect to whatever local network where you might be physically located . All of us have gone through “the drill” of trying to connect to a customer’s network, a hotel network, or some public Wi-Fi network. Sometimes it’s easy, but more often than not there are some bumps that eat into your productivity. The 3G adapter allows you to get around those time-eating complications.

The problem is that not all 3G adapters and their supporting software are the same. The following describes an interesting issue that came up when a customer was using a particular 3G adapter:

“This morning I tested the “always-on” 3G connection scenario with my Rogers 3G adapter (http://www.rogers.com/web/content/wireless_network) and the built-in 3G GOBI (built-in mobile broadband technology - http://www.gobianywhere.com/) adapter in my HP Tablet and found that when using the Rogers USB 3G adapter an “always-on” connection is not possible, but when using an integrated 3G GOBI module it is possible (it really comes down to the software that is provided). The details of my test methodology and results are below…

Rogers Rocket™ Stick – The Rogers Communication Manager software runs in User Mode only (does not run as a Service), so the connection is invoked when a user is logged on and disconnected when the user logs off. There is an “Auto-Connect” checkbox, but it only makes the connection when a user logs on to the device. Therefore the current software provided by Rogers does not support an “always-on” scenario. I verified this by looking at the activity light on the USB stick itself – Red is device is not ready, solid Blue is network detected, blinking Blue is network connected and active. For the duration of the test the activity light remained sold Blue, indicating that a connection to the 3G network was never established. It only began blinking after I logged in to the computer.

HP Built-In 3G GOBI Adapter – The HP software is installed as a Service that can be configured to automatically start at boot (in the Services console), and there is also an option to “Auto-Connect” to the 3G broadband. Since the HP Tablet does not have external lights to indicate network activity I had to find another method to determine if the 3G connection was active prior to logon, so I did the following:

1. Disabled the wireless adapter, so that the HP Tablet could only connect using the 3G broadband
2. Installed the Windows Live Mesh software on the HP Tablet, added the HP Tablet to my managed device list and configured it to allow remote connections
3. I completely shut down the HP Tablet, then turned it on (cold boot) and left it alone (did not log on)
4. At my other computer (Lenovo laptop), I logged on to http://mesh.live.com and was able to successfully Remote Desktop to my HP Tablet via the website
5. To verify that only the 3G broadband connection was active, from the Remote Desktop session I checked the active network connections on the HP Tablet, then double-checked by logging on to the HP Tablet locally – and yes, throughout the entire time the only active connection was the 3G broadband.

Therefore the HP built-in 3G adapter (with a Rogers SIM), appropriately configured, will allow for an “always-on” 3G connection that could be used for device management prior to user logon. A similar test would have to be run for the any other 3G adapter you will be using to verify if the 3G adapter’s software provides the same capability.”

Later another interesting finding was that with the HP GOBI 3G adapter, if the user logged off the computer the 3G adapter shut down and does not start again until the user logs on again or until the machine is restarted.

Summary

When considering a 3G solution to work with your DirectAccess capable mobile computer, make sure to check on the adapter software’s connectivity behavior. The adapter should be able to initialize and connect to the 3G network before the user logs on to the DirectAccess client computer. You can use the methods described in this article to determine if the adapter is capable of this behavior.

(Hat tip to Pat Telford for informing me of this issue.)

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Forefront 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

Take a look at the figures below and see if you can guess what device is in the request/response path that you don’t typically see a UAG DirectAccess deployment.

First, the ipconfig output on a DirectAccess client located behind a NAT device:

Figure 1

Now let’s ping DC1:

Figure 2

Now let’s do a tracert from CLIENT1 and DC1:

Figure 3

With this information you should be able to figure out what the “novel” device is in the path between CLIENT1 and DC1. If you know, then consider yourself pretty well-versed with IPv6 addressing. If you don’t know, then here’s a great opportunity to learn something new!

UPDATE!

Now take a look at figures 4 and 5 and determine what device was removed from the path:

Figure 4

Figure 5

Think about the solutions and put your answer in the comments section. Give your reasoning. I’ll post the answer and a network diagram of the solution tomorrow.

Have fun!

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Forefront 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

A couple of good questions were asked on a recent blog post and I figured it was worthwhile to answer them in more detail in a separate post.

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

“Can you clarify a couple points related to Certificate Authorities and CRLs?  I plan on getting a commercial certificate for the IP-HTTPS listener as you recommended, but how does that affect all of the other certificate related configurations in the test lab guide?  The CA created on the domain server is completely separate from this commercial certificate, right?…”

The IP-HTTPS Listener Certificate

The IP-HTTPS listener needs a web site certificate (intended use is server authentication) so that DirectAccess clients can establish an IP-HTTPS connection to the UAG DirectAccess server before establishing the DirectAccess IPsec tunnels. This requires mutual client and server authentication, something that is the default setting for UAG DirectAccess (the default for Windows DirectAccess is server authentication only).

The primary advantage of using a commercial certificate for the IP-HTTPS listener is that the commercial certificate provider maintains the Certificate Revocation List (CRL) and Distribution Points for you. Not only do they maintain that list for you, they also make sure that the CRL is highly available. While you could use your private PKI for the IP-HTTPS listener, you would then be responsible for maintaining the CRL and making sure that it it highly available.

Now how does this relate to what we did in the Test Lab Guide: Demonstrate UAG SP1 RC DirectAccess Test Lab Guide (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=71be4b7b-e0e9-4204-b2b5-ac7f3c23b16d)?

In the Test Lab we actually created a certificate template that removed CRL related information so that the DirectAccess client would not fail its IP-HTTPS connection when the CRL wasn’t published. This simplified the TLG environment because we didn’t need to go through the steps of publishing the CRL. In your production environment, you do want to make sure that the CRL is available for your private PKI; so you wouldn’t use the special configuration we did for the web site certificate template we used in the TLG. However, you don’t need to publish your private CRL because the commercial provider is handling the IP-HTTPS certificate’s CRL Distribution Points.

You still want to use your private PKI to distribute computer certificates to the DirectAccess clients and the UAG DirectAccess server. You also want to distribute computer certificates to any machines that you want end-to-end IPsec transport mode protection. And you want to make sure that the CRL is available so that you can revoke certificates (however, revoking certificates for DirectAccess clients is not an effective way to prevent them from connecting to the DirectAccess server – other methods should be used, such as disabling the computer account for the suspect DirectAccess client and changing the password of the user who lost the DirectAccess enabled computer). And you want to be able to use autoenrollment to make is easy to distribute the certificates.

The commercial certificate and the private certificates have no relationship to each other and don’t need any. The commercial certificate provider should be included in the Enterprise Root Certificate Authorities store on all your DirectAccess enabled machines.

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

“And you mentioned that you wouldn't want to host the CRL on the DirectAccess server in a production environment.  Is this only because of performance reasons or because of something else?  And is this CRL not related to the IP-HTTPS listener?  So, just to make sure I'm getting it, there is one CA and a corresponding CRL for the active directory domain, and then another CA/CRL (in this case commercial) for the DirectAccess connections.  Is that right?…”

Public and Private CRL Distribution Points

There are a number of reasons why you wouldn’t want to host the CRL Distribution Point web site on the UAG DirectAccess server, but probably the main one is that every time you reconfigure the DirectAccess settings using the UAG DirectAccess wizard, it will end up resetting your CRL Distribution Point web site. There are also traffic related reasons – since the CRL check requires anonymous access to the CRL Distribution Point web site, you increase both the amount of traffic and the attack surface on the UAG DirectAccess server.

You are correct that there are two CRLs in use in the DirectAccess scenario discussed here:

• The CRL maintained by the commercial certificate provider – they do all the work and you don’t need to worry about it
• The CRL maintained for your private PKI – which is used for revoking certificates delivered by your private certificate servers. You are responsible for managing this CRL and CRL Distribution Point

It’s important to note here that only a “soft” CRL check is done when the DirectAccess client connects to the UAG DirectAccess server. If the DirectAccess client fails the CRL check, it will still be allowed to connect. So whether or not the CRL is available doesn’t determine connectivity for your DirectAccess clients.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Forefront 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