If you’ve ever worked with Microsoft DirectAccess, you know that at its core, DirectAccess runs on IPv6. In the early days of DirectAccess this was a blocker for implementation for many companies, because the only resources that your DirectAccess clients could communicate with were IPv6 resources, and there are very few companies running IPv6 inside their networks even today. In 2010 the implementation of DirectAccess was made significantly easier by removing all IPv6 requirements. This was accomplished by a couple of new technologies that were placed inside the Unified Access Gateway (UAG) platform that could handle translating the DirectAccess IPv6 packets into IPv4 packets when needed. These translation technologies are called NAT64 and DNS64, and they exist out of the box in any UAG DirectAccess deployment, as well as any Server 2012 DirectAccess deployment. This means that DirectAccess traffic comes in over the internet as IPv6 traffic, but when the internal resource that you are trying to contact is IPv4, those packets get translated on the fly by the DirectAccess server into IPv4 packets so that they can make their way successfully across the internal network. This all works great out of the box, with no extra configuration steps needed.

However, the key statement above is that “DirectAccess traffic comes in over the internet as IPv6 traffic”. No matter what version of DirectAccess you are running or how you have configured your settings, the DirectAccess traffic that is going over the internet, between the client computers and the DirectAccess gateway server, is always IPv6. So if your users are launching an application, and that application on the client machine is not capable of generating IPv6 packets, that application will not work over a DirectAccess tunnel. Most client-side applications these days are capable of generating both IPv4 and IPv6 packets, and so no matter what the network looks like, those applications will just push out whatever packets they need to make a connection. As DirectAccess becomes more popular, we are discovering that not all applications are coded equally, and there are many out there that are incapable of talking IPv6. Some software vendors are working on new releases of their software to make it IPv6 compatible, but many companies use applications that are homegrown, or customized, or legacy to the point where the software vendor just doesn’t exist anymore, and some of these apps are never going to be IPv6 capable.

Enter App46

IVO Networks has developed a solution to this problem that we call App46. App46 (pronounced App-four-to-six) is an agent that when incorporated into any DirectAccess environment, whether it be UAG or 2012 based, can intercept traffic from these IPv4-only applications, flip those packets into IPv6, and then send them on their way successfully across the DirectAccess tunnels! We have used App46 to successfully fix numerous applications that could not previously function over DirectAccess.

Autonomy’s WorkSite over DirectAccess – Using App46

Probably the most popular uptake of App46 so far has been in the legal industry, specifically for an application called WorkSite. WS also goes by a couple of other names, depending on how you use it – FileSite, iManage, iManage WorkSite. It is a document management system that many law firms use, and it is not truly IPv6 capable, and therefore does not work over DirectAccess natively. We now have WorkSite functioning over DirectAccess in numerous organizations by using App46.

If you have any questions regarding App46, or DirectAccess in general, always feel free to reach out to me directly. Thanks!

Jordan Krause
Microsoft MVP | Enterprise Security
jordan.krause@ivonetworks.com

For IVO Networks – Software Sales, please contact:
Eric Bettermann – eric.bettermann@ivonetworks.com
651.503.5632

Service Pack 3 was recently released for the UAG platform, and now Hotfix Rollup 1 is available to lay on top of it.

Download it here

This is a hotfix rollup and is intended to correct specific problems, and does not bring any new functionality to UAG. Here is the list of KBs that this Rollup addresses:

• KB2810229 – You cannot redirect local computer resources in an RDS session after you disable the client endpoint components in Forefront Unified Access Gateway 2010
• KB2831570 – “The URL you requested cannot be accessed” error message may be returned when a client sends an HTTP POST request to a portal in Forefront Unified Access Gateway 2010
• KB2831573 – Traffic is not forwarded or you receive an error message about ADVAPI32.dll when you use a Windows XP client to start an application from a Forefront Unified Access Gateway 2010 Service Pack 3 portal
• KB2831865 – The endpoint policy expression “Any Personal Firewall (Windows)” is incorrect for Windows 7 and Windows 8 in Service Pack 3 for Forefront Unified Access Gateway (UAG) 2010
• KB2831868 – Endpoint policies for existing trunks are not updated after you install Forefront Unified Access Gateway 2010 Service Pack 3
• KB2832679 – You receive a 500 Internal Server error when you run the File Access application from the Forefront Unified Access Gateway 2010 Service Pack 3 portal trunk
• KB2832681 – You receive a script error that prevents file access configuration in the Management Console in Forefront Unified Access Gateway 2010
• KB2832685 – The Forefront Unified Access Gateway 2010 portal may intermittently become unresponsive to clients after Service Pack 2 is installed

It is a privilege to have had the chance to write an article for the latest Microsoft Security Newsletter. Thanks for continuing to spread the word on DirectAccess!

http://technet.microsoft.com/en-us/security/jj991832.aspx

Jordan Krause
Microsoft MVP | Enterprise Security

Microsoft recently released Service Pack 3 for Forefront Unified Access Gateway! The most sought-after features of this update that I have heard are UAG portal compatibility for Windows 8 clients running IE10, and UAG portal compatibility for connections from computers that are running the new 8.0 version of RDC.

Running a Windows 8 DirectAccess client through UAG is now also officially supported, though as we know that has always worked anyway, even prior to SP2. See below for a full set of the items that this Service Pack brings to the table.

Download it here

Installation instructions

As with any update to the UAG or TMG platform, we recommend launching the installer from an elevated command prompt. You must also make sure that you already have UAG Service Pack 2 running before you install SP3. If you open UAG Management and check your Help > About screen, SP2 is build number 4.0.2095.10000. Double check that this is true before attempting to install SP3.

Post-installation note – DNS64 service

Following installation you may find that DirectAccess clients cannot connect to IPv4 resources inside your corporate network. This is because the SP3 installer, like some other UAG update installers in the past, doesn’t always finish setting one of the services back to Automatic and starting it back up following installation of the Service Pack. So immediately following this install, head into Services on your DirectAccess gateway and make sure that the Microsoft Forefront UAG DNS64 Service is set to Automatic and is Started.

List of new features (see http://support.microsoft.com/kb/2744025 for the full list)

• Windows 8 and Windows RT
  UAG SP3 supports Windows 8 and Windows RT client computers using IE10 on the desktop. 
• Windows Phone 8
  UAG SP3 supports mobile phones running Windows Phone 8.
• Support for Office 2013 client applications
• Support for Remote Desktop Client 8.0
• Exchange 2013 publishing template
• SharePoint 2013 publishing template

Side note – File Access

I have seen numerous reports now that using the File Access application inside a UAG portal from Internet Explorer no longer works after installing SP3. It does still appear to work from other browsers, and there is a workaround to allow File Access to accept connections from IE again if so needed. Feel free to contact me directly if you need further information on this topic.

Jordan Krause
Microsoft MVP | Enterprise Security
jordan.krause@ivonetworks.com

Now that we are shipping DirectAccess Concentrator appliances in two different flavors, UAG DirectAccess and Server 2012 DirectAccess, we tend to have conversations everyday with customers about the differences between the two, and which better suits their needs. Many folks assume that Server 2012 DA is the way to go, because it’s the newest, but this is definitely not true for everyone. What we are finding in practice so far is that, once reviewing the options, UAG is still the platform of choice for many customers. It all depends on what is most important to you, what you want to accomplish in your remote access environment.

Since I currently have a stack of emails in my Inbox which are all waiting to hear the same information, a comparison of features between the two, I thought this an appropriate time to put this information somewhere more centralized. I won’t get too technical in this review, but here are some of the real-world differences you are going to find between UAG DirectAccess, and Server 2012 DirectAccess:

Items that are essentially the same between both solutions:

Load Balancing (in the same site) – Both solutions have built-in mechanisms to create arrays of servers and can take advantage of either integrated load balancing, or external hardware load balancers. Load Balancing is for DirectAccess machines that are located in the same subnet, for either UAG or 2012.

Network Access Protection (NAP) Integration – Both UAG and Server 2012 can be integrated with NAP to require the clients to have health certificates before being allowed to connect.

One-Time-Password (OTP) – Both UAG and Server 2012 can be configured to require a one-time-password pin to be entered before the users are allowed to connect over DirectAccess.

Is IPv6 required inside my network? – No. Both UAG and Server 2012 contain NAT64/DNS64 which are the translation technologies that enable your entire internal network to be IPv4.

Items that are different between the solutions. These are typically the deciding factors on which solution is best for you:

Do I need public IP addresses for my DirectAccess server?

UAG: Yes. With UAG DirectAccess it is required that you have two consecutive public IP addresses on the external interface of the server.

2012: Not necessarily. With 2012 you can now use a single IP address on the external interface, and that IP can even be a private IP (in a DMZ perhaps) that is sitting behind a NAT. This can enable small companies that do not have access to public IP addresses the opportunity to use DirectAccess. I personally feel that most implementations will continue to have two public IP addresses on the external interface, because that is still required if you desire to have the Teredo protocol as a connectivity method for your client computers. Moving to a single external IP, be it public or NAT’d, limits you to only the IP-HTTPS protocol. I have seen many cases where a certificate expires or some other configuration setting gets changed or broken that can take down one of the transition technologies (as some of you know, there are three – 6to4, Teredo, IP-HTTPS), and if something were to inadvertently happen to one of those transition technologies, it is nice to have multiple ways for the client computers to be able to connect instead of relying on just one.

Do I need an internal PKI infrastructure to use DirectAccess?

UAG: Yes, though the requirements are very easy to meet. As long as you have a Windows Enterprise CA server running somewhere in your environment, you meet the requirements already. All that is left is configuring a cert template, and in many cases we don’t even have to do that. Ultimately though, yes this is a requirement, you must be able to issue machine certificates from an internal CA server out to your DirectAccess client machines for them to use on IPsec tunnel authentication.

2012: Probably yes, but not necessarily. In Server 2012 DirectAccess you can get DA up and running without having a CA server in your network at all. The fine print here is that you will have a limited DirectAccess implementation, and will be missing out on some of the features available to you. Also, most importantly, Windows 7 clients will NOT be able to connect without PKI. In my experience, everyone still has Windows 7 client computers they want to connect through DirectAccess. If you want to connect Windows 7 clients, you must have PKI. Also, if you want to use NAP integration, you must have PKI. If you want to use OTP, you must have PKI. If you want to use DirectAccess Force Tunneling, you must have PKI. If you want to use Multi-Site DirectAccess, you must have PKI.

Multi-Site

UAG: I have many customers running “Multi-Site UAG DirectAccess” where they have multiple DirectAccess appliances in multiple physical locations. The catch is that you have to manually assign, via simple group membership, where the client computers connect. Essentially “GroupA” connects to “DatacenterA”, and “GroupB” connects to “DatacenterB”. There is not automatic failover between sites, so we typically run a VPN portal on each UAG box that allows users to connect a manual VPN session to the backup datacenter in the event of a site failure.

2012: Here is the biggest advantage of Server 2012 DirectAccess in my eyes, though unfortunately it is ONLY for Windows 8 client computers. In 2012 DA you have the ability to setup multiple DirectAccess entry points in multiple physical locations. Your Windows 8 client machines will be aware of each location, and will be able to choose automatically which site they want to connect to. This can be an automatic decision that the users have no control over, or you can give users the ability to connect to a site of their choice if you so desire. For your Windows 7 clients, you will be assigning them to one and only DirectAccess entry point, just like we do with UAG.

Publishing applications (reverse proxy) and connecting non-DirectAccess machines to the network

UAG: Here is the biggest advantage that UAG has over 2012. There is way too much functionality in UAG for me to write about on this post, but basically on a UAG DirectAccess box you have the ability to not only run DirectAccess connections, but you can also publish SSLVPN portals on the web which allow your users to hit a webpage, login, and have access to their applications inside a web portal, from wherever they are. This could be home computers, a kiosk machine at an airport, or even a cell phone. Some of the common uses of these portals are publishing Exchange (OWA, OA, ActiveSync), publishing SharePoint, publishing RDP connectors, and publishing full VPN access. This is a way for your users that don’t have a DirectAccess machine in front of them to gain access to the information they need, when they need it.

2012: In Server 2012 you can combine DirectAccess with traditional RRAS VPN access. This enables you to connect non-DirectAccess client machines to the network by using traditional VPN connectivity methods. Unfortunately, Server 2012 has no capability of publishing web portals or reverse proxying applications.

Conclusion

This is not an all-inclusive list of the differences between the two platforms, but rather the common questions that I see coming from real people in real companies. These are the things that we care about, these are the decision points that will steer us into the correct implementation of DirectAccess. For me, I see the decision many times come down to: ”Is it more beneficial for me to have Multi-Site DirectAccess? Or to have the ability to publish applications using the UAG portals?”

Whichever you choose, DirectAccess is an amazing remote access technology that blows every other solution out of the water, in my opinion.

Jordan Krause
Microsoft MVP – Enterprise Security
jordan.krause@ivonetworks.com

I am honored to have had the opportunity to be technical reviewer for the latest book on my favorite remote access technology! This book includes heaps of information that will help you administer Unified Remote Access in your environment. The most popular component of URA being, of course, DirectAccess – which we are so passionate about over here at IVO!

http://www.packtpub.com/windows-server-2012-unified-remote-access-planning-and-deployment/book

Ben and Bala did a tremendous job on this, be sure to check it out!

Jordan Krause
Microsoft MVP – Enterprise Security
jordan.krause@ivonetworks.com

“We recently added a new subnet in the corporate network, why can’t my DirectAccess computers access it?”

This is a common question that I receive and the answer is a simple two-step process. But first, a little background information on why there are steps required here at all, because you may be thinking “I configured my routers so they know how to reach this new subnet, isn’t this the router’s job?”

The reason that new subnets are not automatically identified by DirectAccess client computers is because the UAG server itself is not aware of this new subnet. When we configure a UAG box, we require two legs, an External and an Internal. One core requirement is that there is only one Default Gateway address, and that it resides on the External NIC. Therefore, the Internal NIC does not have a Default Gateway address assigned and does not know how to route on the internal network beyond the subnet that it is physically connected to. Because of this, when a network consists of more than one subnet, we need to define our own routing table on the UAG server. If you are the person who installed the UAG box in the first place you are probably already aware of this, but if you recently moved into the role of supporting this box it is likely new information.

Let’s head over to the UAG server and start with a route print:

As you can see, we have persistent routes defined for the internal subnets that need to be routable. *Lightbulb*, we need to add the route for this new network. Let’s go ahead and do this now:

Step 1: Add a route for the new subnet into Windows

route add –p <SUBNET> MASK <SUBNET_MASK> <GATEWAY> IF <INTERNAL INTERFACE ID>

For example, if I am plugged into the 10.0.0.x network and my default gateway on that network (even though I don’t have a default gateway defined on my NIC, there is still a router there somewhere connecting me to the other subnets) is 10.0.0.254, and my new subnet is 10.0.3.x, then the statement would be:

route add –p 10.0.3.0 mask 255.255.255.0 10.0.0.254 if 13

(“if 13” at the end stands for “Interface 13” – 13 is the Interface ID number of the Internal NIC of the UAG server in my lab. Defining the Interface ID number to a route statement ensures that the computer knows this route is dedicated to this particular NIC. In most cases the routes will work just fine without specifying the IF at the end of the route statement, but I always add it just to be safe. You can figure out what the Interface ID number of your Internal NIC is by looking at the very top part of your route print)

Note: If you have an array of UAG boxes, you will have to manually add this route on each node.

Now you head back to your DirectAccess client computer and…nope, still doesn’t work. You may or may not remember that back when you first setup UAG, you had to run through a networking wizard that asked you to define the IP address ranges that made up your internal network. This is essentially a “UAG will trust these IPs as part of the internal network” list. You must re-run that wizard and add the new subnet.

Step 2: Add the new subnet into UAG’s internal network definition list

Start by opening up UAG Management. Then run the Network Interfaces wizard from the Admin menu:

Clicking Next twice will bring you to the screen where we define the IP address ranges that make up our internal network. Simply add the new subnet’s range in here, and finish out the wizard:

Once you finish out the wizard, UAG should prompt you to run an Activation which will push this new setting into action.

Now when you head over to your DirectAccess laptop, you should have access to resources that are inside your new subnet.

Jordan Krause
jordan.krause@ivonetworks.com

I recently ran into this message when trying to activate a UAG DirectAccess box after changing the public IP addresses. It immediately rang a bell, as I have written before about the “Forwarding on the 6to4 network interface cannot be enabled” and how that one is usually corrected by heading to Device Manager and deleting out the multiple instances of the 6to4 adapter that have plugged themselves in there. However, when receiving “Forwarding on the Teredo network interface cannot be enabled” you would follow the same logic, head over to Device Manager, and discover that there is only one Teredo adapter listed. Furthermore, deleting that adapter and restarting the server does not correct the UAG activation error message.

What gives?

The inability to enable forwarding on the Teredo interface seems to be related not to having multiple adapters, but rather some confusion between the Teredo adapter and the SSL Network Tunneling adapter. If you take a look at “ipconfig /all” on your server, you will likely notice that there are two interfaces with the same name – “Local Area Connection* 9” – one of these is your Teredo Tunneling adapter, and the other is your SSL Network Tunneling adapter.

The solution: Uninstall the SSL Network Tunneling adapter from Device Manager, and restart the server. UAG should now activate successfully.

Before resorting to doing this I tried running many commands and different things to force the enabling of forwarding on the interface, but nothing I tried worked. Ultimately, deleting the SSL Network Tunneling interface will not negatively affect a DirectAccess system, because the SSL Network Tunneling adapter would be used by the Network Connector VPN, and it is not supported to run Network Connector VPN and DirectAccess connections on the same UAG server. Maybe this adapter confusion trouble is part of the reason why. After deleting the adapter and restarting, UAG was able to activate successfully and both DirectAccess and SSTP VPN connections (which are supported to run at the same time) are working great on this machine.

Jordan Krause
jordan.krause@ivonetworks.com

In almost all cases, once DirectAccess connectivity is established, Outlook’s connection to Exchange inside the network starts working instantly over the IPsec tunnels, without any special considerations. There is one exception that I have come across a few times, and that is when running multiple Exchange 2010 servers that are load balanced. In such implementations, Outlook often cannot establish a connection to Exchange over the DirectAccess tunnels. This happens because TMG recognizes that the IP address of the CAS response doesn’t match the source IP for the load balancer, and TMG decides to drop the traffic.

Thankfully, there is an easy fix! Simply run the following script on your DirectAccess gateway(s) and then restart it, and Outlook should start connecting for your users:

    Dim oFPC
    Dim oFirewallFilter
    Dim oVPS 

    on error resume next

    err.Clear

    Set oFPC = CreateObject(“FPC.Root”)

    ‘Get the filter admin object
    Set oFirewallFilter = oFPC.GetContainingArray.Extensions.ApplicationFilters(“{E331F638-AB86-4AA5-9B6A-2B0248C7B4FB}”)
    if oFirewallFilter is nothing then
         Wscript.Echo “RPC filter ({E331F638-AB86-4AA5-9B6A-2B0248C7B4FB}) is not installed in array”
         WScript.Quit
    end if 

    ‘Get the filters vendor parameters set object
    Set oVPS = oFirewallFilter.VendorParametersSets(“{E331F638-AB86-4AA5-9B6A-2B0248C7B4FB}”) 

    ‘If this vendor parameters set does not exist, create it
    If oVPS Is Nothing Then
         WScript.Echo “Adding vendor parameters set ({E331F638-AB86-4AA5-9B6A-2B0248C7B4FB})”
         err.Clear
        Set oVPS = oFirewallFilter.VendorParametersSets.Add(“{E331F638-AB86-4AA5-9B6A-2B0248C7B4FB}”,False)
        oFirewallFilter.VendorParametersSets.Save
    End If 

    ‘Add the needed parameters 

    oVPS.Value(“AllowAuthEndpointMapper”) = 1  

    oVPS.Save 

    ‘Inform the user of the result
    if err.Number <>0 then
         Wscript.Echo “Fail to set parameters. error code is:” & err.number & ” Desc:” & err.description
    else
        Wscript.Echo “Paramters were successfully added”
    end if

Jordan Krause
jordan.krause@ivonetworks.com

Certificates are a key piece to the puzzle that is DirectAccess. What is the biggest problem with certificates? They expire! This post is the direct result of too many calls lately regarding strange problems within a DirectAccess environment, which could have been prevented with a simple calendar reminder. Here are a couple of common scenarios that I see:

Nobody can connect when they are inside the office!

When troubleshooting connectivity problems for client machines that are inside your network, your mind doesn’t automatically move into thinking about your remote access solution as being the problem. And on top of that, in most of these cases I work with when there are inner-network connectivity problems, you quickly come to find out that your DirectAccess users who are sitting at home or a hotel are working just fine. What gives? Your Network Location Server (NLS), that’s what. NLS is a critical component to the way that DirectAccess fits into a network. In some ways the NLS website is even more important than the DirectAccess gateway box itself because if the DA gateway goes down, you don’t have remote connectivity. But if your NLS goes down, you don’t have INTERNAL connectivity – which likely affects way more users. Because the Network Location Server is so critical, we always recommend making it a highly available website. This takes away a lot of the worry. However, whether you have one or ten NLS websites running, chances are that you are using the same SSL certificate on every single one. So what happens when that certificate expires? NLS doesn’t work for anybody, and so none of your DirectAccess enabled machines are able to drop their NRPT tables and they continue to try and pump corporate traffic through IPsec tunnels which, depending on routing in your environment, likely do not exist. This will cause all corporate traffic to fail on those client machines. Mark your calendars well in advance for the expiration date of the NLS certificate so you can have sufficient time to plan and replace it with a new one! Or better yet, if you use a certificate issued from your internal CA for the NLS website, try to get it configured so that it auto-renews.

Intermittent connectivity problems for DirectAccess client computers

DirectAccess is a very solid connectivity platform, and when there are random problems connecting even from just a few client computers, it is typically an indicator that something is wrong. There are many moving parts in DirectAccess, and so there is not always a hard “stop” when something happens. Many times a particular component can break (or expire) and only cause some client machines to have problems. Such is the case with the expiring IP-HTTPS certificate. This is an SSL certificate that is placed on your DirectAccess gateway(s) and authenticates the IP-HTTPS traffic stream. As you probably know, IP-HTTPS is a protocol of last resort for most implementations, and so many of your users are not utilizing it unless they are sitting behind a port restricted firewall somewhere. Because of this, when the SSL certificate expires you may not notice it right away. I have worked with companies who did not realize it for over 6 months! In my experience the majority of DA connections are Teredo, and when clients are connected with Teredo, this certificate doesn’t even matter. But the first time a user sits down at a location where UDP is not allowed, their machine will attempt to connect to IP-HTTPS, and will fail if there is not a valid certificate on that gateway. These certificates are even more likely to expire than the NLS certificate, because we always recommend that the IP-HTTPS cert be one purchased from a public CA and so there is generally a procurement process to take when purchasing a new copy. The IP-HTTPS certificate expiring is a much bigger deal for those that choose the Force Tunnel option with DirectAccess, as force tunneled clients always use IP-HTTPS and an expired certificate will break DirectAccess for everybody.

That’s it for today! Just a gentle reminder to make sure both of your key DirectAccess certificates are included in your annual renewals.

Jordan Krause | Microsoft MVP
IVO Networks
jordan.krause@ivonetworks.com