Here’s an interesting idea. The “Cloud Backup” business seems to be expanding rapidly, I stumble upon new ones all the time always toting the same message – “Keep your data backed up here for $X per month”. Sounds great, but the problem is that $X per month usually turns into $10X or even $100X per month once you realize how much data you actually own and would cry over if you lost.

So why not create automatic, offsite backups for yourself? FOR FREE

I’m a Microsoft DirectAccess enthusiast, and as such I am always trying to keep my eyes open for new ways in which it can be used to make life easier on IT. This is absolutely one of those areas. If you have DirectAccess, you already have the infrastructure needed to establish a remote backup site – at any physical location of your choosing. All you have to do is:

1. Build out your backup machine – This can be a desktop, laptop or server and it can be running Windows 7 or Server 2008 R2 (yes, Server 2008 R2 can also be a DirectAccess client).

2. Enable DirectAccess on this machine – Add this new machine to your Security Group or OU for DirectAccess so that it receives the DA connectivity settings and the necessary certificate from your CA server.

3. Move the machine to a remote location of your choosing.

That’s it! As long as the machine gets internet connectivity at the remote location it will establish itself some DirectAccess IPsec tunnels, and you will have a 24×7x365 connection to your new offsite backup server. You can now use whatever backup methods you choose, and push the results at this offsite machine just as if it were another machine sitting inside your corporate network.

Keep in mind that as with any DirectAccess client, you will need to create Firewall rules that allow the necessary ports for whatever backup method you are using. I recommend doing this with a GPO. Create a new one, add the inbound firewall rule or rules to it, and assign it to this client machine. For example, if you are using a backup utility that simply needs access to be able to push files at a file share that is running on the offsite backup server, open up TCP 445 inbound and you should be all set.

This method for offsite backups could prove especially helpful for businesses that do not have a second location or if they do it may not have an expensive WAN link keeping the two connected. This offsite backup server could be placed anywhere, at an employee’s home for example. You will have complete management access of this backup server at all times because it is connected via DirectAccess. You can push patches and GPO settings at it, remotely control it, whatever you might need to do to ensure safety and security of your data.

Jordan Krause
IVO Networks
jordan.krause@ivonetworks.com

A handful of cases have rolled across my desk recently involving laptops that will not connect via DirectAccess from particular internet connections. In working on these cases I discovered a commonality – all of the laptops in question were being assigned a native IPv6 address onto the NIC in addition to the expected IPv4 address:

Some of these laptops were getting this IPv6 address from a home router, and some were getting an IPv6 address assigned to them by a new 4G card that the user had recently acquired. The clients were also getting an IPv6 address for Teredo or IP-HTTPS, but the problem showed up near the bottom of the DirectAccess Connectivity Assistant logs:

The DirectAccess IPsec tunnels (at least some of them) were attempting to establish themselves using the native IPv6 address instead of the Teredo/IP-HTTPS addresses. The resolution to the problem on all machines was to disable that native IPv6 address from being assigned to the laptops. Since we didn’t want to try walking the users through reconfiguring their home routers we unchecked TCP/IPv6 from the NIC properties and that took care of it for the home users:

And for the 4G card users we found a setting in the software for the 4G card – it was basically just a checkbox for “IPv6” that the user was able to uncheck and the next time they connected with the 4G card, it issued only an IPv4 address, not an IPv6 address and then the tunnels established correctly over Teredo/IP-HTTPS.

The official word from Microsoft is that client-side IPv6 is supported, but after reviewing the details of these cases they agreed that the best solution to this issue is to simply stop those native IPv6 addresses from being assigned to the client machines.

Jordan Krause
IVO Networks
jordan.krause@ivonetworks.com

Update 1 for UAG SP1 has been released and is ready for download on IVO Networks appliances. Some of the changes contained in this update are:

-          Lync web services publishing

-          Dynamics CRM 2011 publishing

-          SharePoint 2010 with Office Web Apps

-          Improved browser support

Full details are available here – http://technet.microsoft.com/en-us/library/hh490321.aspx

Additionally, UAG SP1 Update 1 includes the recently released MS11-079 security update.

Download Update 1 here – http://www.ivonetworks.com/downloads/uag_sp1_update1.zip

If you are running UAG before SP1, you cannot make use of this new update and therefore should install the standalone hotfix for MS11-079 which corresponds to your current UAG level. Visit the link below for a list of downloads available:

http://technet.microsoft.com/en-us/security/bulletin/ms11-079

As always, please contact your IVO support engineer should you have any questions at all. Thanks!

Jordan Krause
IVO Networks
jordan.krause@ivonetworks.com

Many companies have multiple datacenters. Depending on the organization’s needs, these datacenters will obviously have different purposes and ways that the users connect. In this article we are going to explore some of the ways that DirectAccess provided by UAG can be used across multiple entry points.

The traveling user connecting to a home datacenter:

Sometimes users travel, and you want them always connected back to their primary datacenter to reach their information. For example, you may have a US employee traveling to India, but their primary email and file servers are located in the US, and so when they are in India you would want DirectAccess to connect them back to their US datacenter. This is what happens by default, and there is nothing special whatsoever you would need to establish to make DirectAccess function like this. But maybe you also have a datacenter in India that is the primary location for email and files provided to India based employees. So your requirements are basically the same – you want US employees to connect to the US datacenter no matter where they are in the world, but you want India employees to connect to the India datacenter no matter where they are in the world. This “manual distribution of DirectAccess clients” is possible with UAG DirectAccess today. You can place a DirectAccess entry point in the US, and another DA entry point in India, and by utilizing separate GPOs for the client connectivity settings, you can create this scenario very easily by simply adding the US computer accounts to the “DA_Clients_US” group, and adding the India computer accounts to the “DA_Clients_India” group. If you ever had a need to move a laptop from one entry point to another, you simply move the computer account from one group to the other, and the next time that laptop receives its Group Policy refresh, it is automatically reconfigured to connect through the new entry point.

The traveling user connecting to geographically local datacenters:

What if you have traveling users that you would rather have connected through the datacenter in the local geographic region they are located? Unfortunately this is not a scenario that DirectAccess is (yet) capable of providing on its own, but with UAG in the mix it makes for a pretty easy solution to this requirement. Simply create a UAG portal in each of your datacenters that allows employees to login and have a VPN session created. So when that US user travels to India, they can launch a simple web address from their browser, login, and then have full network connectivity to the India datacenter. If for some reason they forget to establish this connection, their DirectAccess will still be connecting them automatically to the US datacenter where they can work like normal, as if they are still in the US office.

To summarize, I believe the need for scenario #2 where users have to connect to their geographically local datacenter is dwindling. With internet speeds being what they are today, even reaching “across the pond” is not a big deal. I would personally like my users continuing to connect through their usual point of entry and always having access to the same resources that they do from anywhere else, this is certain to reduce helpdesk calls. But, if ever there is some specific reason that users would be expected to connect to a datacenter other than their home, it is easily accomplished with UAG.

Jordan Krause
IVO Networks
Jordan.Krause@ivonetworks.com

Those DCA log files can be incredibly helpful in diagnosing a broken DirectAccess connection, and they can be very overwhelming at the same time. Here’s my take on a summary of each section, and some of the common statuses that could indicate trouble. I am basing this on the average, “normal” implementation so I won’t go into extended detail on a few of the results that are not used in the average installation:

Top of log file
At the very top you’ll see a quick summary of whether or not the DCA “thinks” it can see inside the corporate network successfully. It’s important to note that this overall status is not always accurate. For instance, if you have configured the DCA to probe more than one internal resource, it might be able to see one and not the other, and even though the DirectAccess tunnels are established correctly, it may still report “Corporate connectivity is not working correctly” – which is actually untrue.

Ipconfig /all
Pretty self-explanatory here. This shows all IP addresses on the client computer. You should have a local LAN IP address as well as at least one IPv6 address assigned from the Transition Technologies (6to4, Teredo or IP-HTTPS).

Netsh int teredo show state
This shows the particulars of Teredo. You want “Type” to be either “client” or “enterpriseclient” and when Teredo is successfully connected, it will show a “State” of “qualified”. If Teredo cannot connect, it is likely because of a port restricted firewall blocking UDP on the user’s internet connection, and Teredo will report “Primary server unreachable over UDP”. However, this should not cause too much concern, because if Teredo is unable to connect, IP-HTTPS should automatically connect and establish the DA tunnels that way.

Netsh int httpstunnel show interfaces
This shows the details of the IP-HTTPS connection. If 6to4 or Teredo has made a successful connection, IP-HTTPS will show as “Disabled”. If you do not have 6to4 or Teredo connectivity, IP-HTTPS will show either “Active” or it will display an error code that will be useful for tracking down anything potentially wrong with the IP-HTTPS connection. Problems with IP-HTTPS are typically certificate related.

Netsh dns show state
These are the 3 important pieces here that you want to ensure are set correctly:
Network Location Behavior : Let Network ID determine when Direct Access settings are to be used
Machine Location : Outside corporate network
Direct Access Settings : Configured and Enabled

Netsh name show policy
This should reflect the information you provided during the DirectAccess configuration wizards on the “DNS Suffixes” screen. This lists the NRPT (Name Resolution Policy Table) which determines what names go through the DA tunnels, and what names do not. If you do not have any information listed here, your machine has probably not received the settings from the DA Client GPO yet, and you should bring the laptop back into the corporate network for a “gpupdate /force”.

Netsh name show effective
When outside the corporate network, this should show the same information as “netsh name show policy” above. If it does not, then you likely have a problem of the client machine not correctly realizing that it is outside of the corporate network, or the NRPT being forced to turn off for some reason (double check the settings in “netsh dns show state” to ensure they are set correctly as indicated above).

Netsh adv mon show mmsa
This is a listing of your Security Associations, which are basically your IPsec tunnels. You should have tunnels here that have a second authentication of “UserNTLM” which indicates the “Infrastructure Tunnel”, as well as tunnels with a second authentication of “UserKerb” indicating the “Intranet Tunnel”. If you do not have any tunnels listed here, DA is not working. You could have a problem with the Transition Technologies not establishing (6to4, Teredo, IP-HTTPS), or you could have a problem with your computer certificate that is assigned to your computer not authenticating properly.

Netsh nap client show state
This lists information on the status of Network Access Protection on the client. If you are not using NAP certificates with your DA environment, this section can be ignored.

Wevtutil query –event Microsoft-Windows-NetworkAccessProtection…
Another section dedicated to NAP that can be ignored if NAP is not enforced.

Netsh int ipv6 show int level=verbose
Some statistics on your IPv6 interfaces, I have never found a case where the data here was necessary for any troubleshooting.

Netsh advf show currentprofile
This shows which Windows Firewall profile your current internet connection has been assigned. You want to ensure that you have either “Public” or “Private” Profile Settings because the DirectAccess Connection Security Rules are only activated while connected to network in which Windows Firewall has been set to use the Public or Private profile settings. You also want to ensure that the Firewall “State” is ON. If set to OFF, you need to figure out what is disabling your Windows Firewall and change it, because WFAS is necessary for a successful DirectAccess connection.

Netsh advfirewall monitor show consec
Some additional information about your firewall settings here, as well as another listing of the Security Associations (IPsec tunnels). The useful information here is really whether or not you can see your IPsec tunnels established, but that information is already available elsewhere in the logs.

Certutil –store my
This command lists the certificates that are installed on your client computer. For a successful DirectAccess connection, you must have a “Machine” certificate issued by your internal CA server that is valid.

Systeminfo
Some general information about the client computer where you are running DirectAccess. Typically I only check the “OS Name” – you want to make sure the client is running either Windows 7 Enterprise, Windows 7 Ultimate, or Server 2008 R2, because those are the only Operating Systems that can be DirectAccess client computers.

Whoami /groups
Listing of the local computer groups that you are part of.

If there is anything you would like added to this list or detailed our further, please let me know and I will update accordingly. Thanks!

Jordan Krause
IVO Networks
Jordan.Krause@ivonetworks.com

I have seen this a handful of times recently and thought it was worth a post, as the culprit is very easy to overlook. Suppose you have a machine that, though it was built from the same image and setup the same way as your other client machines, will not connect over DirectAccess. In fact, when you look at the DirectAccess Connectivity Assistant log files, it seems that DirectAccess is not turning itself on for some reason. Netsh name show effective gives us:

DNS Effective Name Resolution Policy Table Settings
Note: DirectAccess settings would be turned off when computer is inside corporate network

Must be a problem with NLS right? Maybe you forgot to exclude it from the NRPT? Maybe not – remember, this is an environment where DA works just fine on other computers. So let’s take another look at the log file. We’ll make sure the client machine is recognizing correctly that it is outside of the corporate network. Netsh dns show state:

Name Resolution Policy Table Options
Query Failure Behavior : Always fall back to LLMNR and NetBIOS if the name does not exist in DNS or if the DNS servers are unreachable when on a private network
Query Resolution Behavior : Resolve only IPv6 addresses for names
Network Location Behavior : Never use Direct Access settings
Machine Location : Outside corporate network
Direct Access Settings : Configured and Disabled
DNSSEC Settings : Not Configured

Hmm, so it is correctly identifying that it is externally connected. But take a closer look at the output of that command:

Name Resolution Policy Table Options
Query Failure Behavior : Always fall back to LLMNR and NetBIOS if the name does not exist in DNS or if the DNS servers are unreachable when on a private network
Query Resolution Behavior : Resolve only IPv6 addresses for names
Network Location Behavior : Never use Direct Access settings
Machine Location : Outside corporate network
Direct Access Settings : Configured and Disabled
DNSSEC Settings : Not Configured

“Never use Direct Access settings” – that sounds wrong, doesn’t it? Sure enough. This is a simple registry key to change from “Never use” to “Automatic” where it should be set. So far a cause for this registry key being incorrectly set has not been brought to my attention, but at least it’s a simple fix. Head over to this registry key on the client machine and change it from “2” to “0” (zero):

HKLM\Software\Policies\Microsoft\Windows NT\DNSClient
EnableDAForAllNetworks=0

Jordan Krause
IVO Networks
Jordan.Krause@ivonetworks.com

To Force Tunnel or not to Force Tunnel, that is the question…

Unfortunately, the phrase “Split Tunneling” has caused many a VPN administrator to cringe over the past 20 years. Many of the reasons why that mentality exists are the fault of those original VPN technologies from decades ago, and have been resolved for quite some time. Here are a couple of the points that I regularly hear:

1. Bridging the connection. Say you are sitting in your favorite coffee shop, enjoying their free WiFi and justifying your longer-than-allotted lunch break by flipping open the lid of your laptop. Apparently there is this idea out there that, once you connect to the corporate network via VPN, somehow any yahoo also sitting in that coffee shop is going to be able to bridge the connection and gain access to your network. Now, there may or may not be a way to configure your work computer to be able to accomplish this, but it would certainly require administrative rights and a good amount of technical knowledge to be able to setup. So in a VPN world, if you are concerned that your users may be maliciously attempting to create a network bridge for other users to drive across, disable their ability to do so by restricting their rights (they should be anyway) or killing their access to any bridging tools they might potentially use to accomplish this. By the way, this section of the conversation is not really anything to do with DirectAccess, but rather regular VPN connections. When talking about DirectAccess (which is what this article is really about) you needn’t be concerned anyway, because all of the traffic coming across the IPsec tunnels is going to be authenticated as having come from the source computer of the DirectAccess client, and thus traffic initiated from a different computer is not going to make its way across the tunnels.
2. Malware. If you allow DirectAccess split tunneling, you are basically sending all corporate traffic to the corporate network, and sending all “other” internet traffic directly to the internet. What if the user hits a malicious link on a social media site and gets infected? My response to this – How is this any different than any VPN? Malware doesn’t care whether or not it’s connected to a corporate network “right now”. It’s more than happy to hang out and wait until you establish that VPN connection! So even if you force tunnel VPN currently, unless you disable the user’s ability to access the internet AT ALL while disconnected from the VPN, this is not a valid concern. In this case, DirectAccess is actually much better than VPN because with DA, as soon as the internet connection is established, so are your tunnels, and thus if you are using DA Force Tunneling, all of your internet traffic flows through the datacenter (and your web filtering devices) all the time. The user cannot turn it off.

So when deciding on a configuration path for DirectAccess, Split Tunnel or Force Tunnel? This article is intended to alleviate any fears (sorry thrillseekers) surrounding Split Tunneling, because they just aren’t valid. However, in some instances Force Tunneling may still be the way to go. If you have a written security policy, for example, stating that all internet traffic from remote machines has to flow through the corporate datacenter all the time, there you go – DirectAccess in Force Tunnel mode will fit the bill. If your company has such a policy, give me a shout. I would love to hear what current technology is being used that can actually accomplish that.

There are also some downsides to using DirectAccess Force Tunneling. Primarily, it is slower. This really is twofold. First, Force Tunneling DirectAccess means that you are restricting your connections to only use the IP-HTTPS connectivity platform, which is less efficient than 6to4 or Teredo that could potentially be used in Split Tunneling. So the user’s experience will be slightly slower. Also, you will be pumping all internet traffic from these machines through the datacenter all the time, so your bandwidth utilization is going to increase, and that means increased costs.

I’ll leave it at that for now, if you have any questions or concerns (I’m always open to being corrected by somebody smarter than I), as always please feel free to contact me.

Jordan Krause
IVO Networks
Jordan.Krause@IVOnetworks.com

Think about a world where you have a one point solution for all of your remote access needs, a world where you can manage all of your remote clients from a single location, and a world where your Mac and Smart phone users have access to their documents and internal resources. Finally imagine this on a hardened edge-of-the-network device with embedded chipsets for encryption and decryption with 2.5 GB throughput.

That world is now a reality with Windows 7 DirectAccess and an IVO Networks DirectAccess Concentrator.

What, you have a question? “Yea, we do not run IPv6 inside our network so I am assuming that this is not a solution.” Well, you assumed wrong. The DirectAccess Concentrator will handle all the translation for you. Matter of fact, you need to know very little about IPv6 to make this work within your network.  

There are three things needed to capitalize on Microsoft DirectAccess. First you would need Windows 7 clients that are running either Enterprise or Ultimate versions. Second, you need to have a PKI infrastructure to handle the certificates that need to be assigned to your remote clients. This is simply a Windows CA server. Finally, you need an internal website that is used for network location purposes.

Most companies know the headaches associated with allowing remote access to their network. In most cases they are using a multi-vendor solution to allow remote network access. This is neither efficient nor cost effective.  This also taxes your IT staff with increased support and reduces the time they can spend on critical business needs.  In today’s business world and economy, IT staffs are being asked to do more with less and operate as efficiently as possible. Also because of the current climate more companies are looking at allowing workers to work remotely.

Gone are the days where your workforce cannot access their resources from hotels or other public internet connections.  DirectAccess will eliminate that hassle for your users. It uses three different technologies that assure your users can gain access from any location.

One of the best advantages with DirectAccess, is that the users do not need to do anything. There is no client installed on the corporate laptop, it just works. All your users need to do is log into their machine and it is no different than if they were sitting at their desktop in the office.

Windows 7 roll-outs are underway and it makes sense to look at how you can capitalize on the technology that already exists in your Windows 7 clients. IVO’s DirectAccess Concentrator makes implementation fast and secure. 

Give yourself one simple solution, on one appliance by one vendor and reduce time and costs associated with remote access.

There is a strong business case for looking at DirectAccess and UAG as a one point solution. 

Learn more by contacting us, or visiting us at TechEd 2011 in Atlanta, GA. We are located at booth 1709.

Schedule an online demo by contacting Eric Bettermann – eric.bettermann@ivonetworks.com

We have been fielding numerous calls and emails lately about Service Pack 1 for Server 2008 R2. Basically, everyone wants to know if and when IVO is planning to support its installation on our appliances.

The answer is: Yes, and Now! SP1 has been fully tested and is approved for installation on any of our appliance models based on Server 2008 R2. This includes UAG appliances, TMG appliances, BRC and of course DAC appliances.

Note: As with any Service Pack install, a restart is required at the end to wrap things up. After the restart you may notice that the “mscorsvw.exe” process consumes a bunch of your CPU for a while. This is normal. This is a background .NET process and it is running at a lower priority than your normal functions, so it won’t interfere with regular user resource utilization on your appliance. This process will typically finish and disappear about 10 minutes after the restart.

Please contact your IVO support engineer (or myself) if you have any questions regarding installation.

Jordan Krause
IVO Networks
Jordan.Krause@IVOnetworks.com

Troubleshooting IPsec tunnels can be a pain. Most of the standard steps to troubleshoot the DirectAccess Infrastructure and Intranet tunnels involve carpal tunnel inducing command line entries and log files that will turn you cross-eyed. However, in my experience I have found that a common scenario begins with the following question:

“I can ping my servers, but I can’t access them over RDP or HTTP or anything else…any ideas?”

Which most of the time (see note below) translates into:

“My primary (Infrastructure) IPsec tunnel is established, but my secondary (Intranet) will not…any ideas?”

Note: Now, those of you who have been doing this a while will realize that ICMP traffic (a ping) moves outside of the IPsec tunnels, so the ability to ping resources but not access them could actually indicate that there are no IPsec tunnels established, but like I said this is based on my personal experience and so far it has been the case every time where the Infrastructure tunnel was in fact established.

To verify what tunnels are active, attempt to open a corporate resource (try to RDP into a server for instance) and then open “wf.msc” on the DirectAccess client computer. Drop down to “Windows Firewall with Advanced Security > Monitoring > Security Associations > Main Mode” and compare your results to the following samples:

Infrastructure tunnel only:

Infrastructure and Intranet tunnels both active:

As you can see, the primary tunnels are established using the computer certificate and show up as NTLMv2 in the 2^nd Authentication Method, and the secondary tunnels require the Kerberos V5 authentication. Whether or not you have an SA listed here that is authenticated via Kerberos typically indicates whether you have one or both of the IPsec tunnels that you need for a successful DirectAccess connection.

So, back to the matter at hand…what if I only have NTLMv2 (Infrastructure) Security Associations?

The first place I always check is the certificate store on the DirectAccess server. The IPsec tunnels are authenticated by checking the certificate that is issued to your DA laptop from your internal CA against the certificate that is issued to your DA server by your internal CA. Since the Infrastructure IPsec tunnel is able to establish itself successfully, you would think this means that this “Machine” certificate checks out okay, but that’s not necessarily true. Make sure that you don’t have any extra, unused certificates in the certificate store of your DA server. On numerous occasions this problem has been resolved by simply deleting an extra certificate that was assigned by the CA for one reason or another and then restarting the DA server. After the restart, everything starts working. If you continue to experience problems, ensure that your TMG is setup correctly to allow communications to your CA as outlined in http://www.ivonetworks.com/news/?p=43 and then re-issue that Computer certificate to the DA appliance. Once again, make sure you delete the old, unused certificate from the store or you could be putting yourself right back into the same position. 

Jordan Krause
IVO Networks
Jordan.Krause@IVOnetworks.com