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

I recently worked with someone who was having trouble getting UAG DirectAccess running. This particular company had not yet purchased the SSL certificate for the IP-HTTPS listener, as they were currently only trying to proof-of-concept the setup using Teredo. Everything appeared to be in order (except IP-HTTPS of course) yet Teredo would not grab an IP address and continually listed “primary teredo server unreachable over UDP”.

Seems pretty obvious, right? There’s a firewall blocking the UDP 3544 traffic that Teredo requires. You’re right, except it’s not so obvious when you don’t realize that your laptops are running a firewall software. It was believed in this case that the client laptops did not have any kind of firewall software installed, therefore it couldn’t be blocked. However, the machines had Symantec Endpoint Protection installed, and one of the components of Symantec Endpoint Protection that gets installed by default is Symantec Network Threat Protection, which is indeed a firewall software. Upon opening the interface for Network Threat Protection, we found a rule blocking IPv6 and a rule specifically blocking Teredo UDP 3544. We simply had to allow this traffic, and Teredo is now happy and working.

Jordan Krause
IVO Networks
Jordan.Krause@IVOnetworks.com

This message is fairly common when trying to activate your UAG configuration after installing UAG SP1. It can also appear after restoring a UAG configuration from backup. This is caused by a duplicate 6to4 interface on your appliance, and is very easily fixed.

Open Device Manager, drop down the View menu and click on Show hidden devices. Then expand your Network adapters and look for Microsoft 6to4 Adapter. Chances are you’ll have two of them listed which is causing the problem.

Simply remove both of them by right-clicking each 6to4 adapter and clicking Uninstall.

Now reboot your appliance and the 6to4 adapter will reinstall itself, but this time only once as it should be. Now you will be able to Activate the configuration in UAG without the error.

Jordan Krause
IVO Networks
Jordan.Krause@IVOnetworks.com

And now the one you’ve all been waiting for…SP1 for UAG!

UAG SP1 is ready for installation on any of our Unified Access Gateway (UAG) or DirectAccess Concentrator (DAC) appliances. Our recommendation as with any update is to download the installer file to your appliance and run it from an elevated command prompt. If you do not have a current system image of your appliance now would be a good time to take one using the built-in imaging utility of your appliance. As always, if you have any questions or would like assistance with installing your update or taking a system image, please contact your IVO support engineer.

Click here to download UAG SP1.

SP1 brings a lot of great features to UAG and DirectAccess. Here are some of the most anticipated changes:

“Manage Out” deployment – It has always been possible to utilize DirectAccess to create a “manage out” only scenario where your DA clients do not have intranet access yet you retain the ability to manage (update, patch, remote control) these machines. However, in the past this has involved some modifications that many dared not attempt. With SP1 you can now choose your deployment model from the configuration wizard.

Force tunneling – Same story here, you are able to enable force tunneling with the outgoing version of UAG, but it required some manual tweaking, this time in Group Policy. However, with the addition of SP1 to your appliance, you can now select the default split tunneling or enable force tunneling right from the configuration wizard.

One-time passwords! – SP1 brings the ability to use OTPs for your DirectAccess client connections. I can’t count the number of times I have been asked about this one!

DirectAccess Connectivity Assistant – The SP1 installation includes a new version of DCA which is now configurable from the DA configuration wizard so you no longer have to move outside of the appliance to configure your clients.

Group Policy Objects (GPO) – Sometimes the default placement of the DA GPOs doesn’t make sense, and having to adjust the script manually every time you make a change can be painful and confusing. Worry no more! With SP1 you can now tell UAG where to place those GPOs and even what to call them.

Enhanced logging and monitoring – Specifically an inclusion of DirectAccess monitoring now in the UAG Web Monitor.

And more! I haven’t listed everything here, but these are the items we are excited to start using in the field. Please get in touch if you have any questions!

Jordan Krause
IVO Networks
Jordan.Krause@IVOnetworks.com

A common message to encounter when installing an IVO UAG or DirectAccess Concentrator (DAC) appliance is “The RPC server is unavailable” when attempting to request your certificate for the appliance from your Certificate Authority server. This is because the default appliance configuration blocks DCOM connectivity between the appliance and your CA. To alleviate this message and to be able to successfully request the necessary certificate from your CA, follow the steps below:

1. On your UAG/DAC appliance, open the Forefront TMG Management console:

2. Left-click on Firewall Policy from the left-hand tree and single left-click on the top rule in the list, PublishingRule::Anchor::Begin. We are not changing anything with this rule, simply clicking on it to highlight it:

3. Now right-click on Firewall Policy and choose New > Access Rule:

4. Name the rule something that makes sense to you, such as Open all communications to CA server. Click Next:

5. This will be an Allow rule. Click Next:

6. This rule applies to: All outbound traffic. Click Next:

7. On the Access Rule Sources page, you want to add the network definition for your UAG/DAC appliance. Click Add… then drop-down Networks and choose Local Host. Click the Add button and it should populate in the list. Click Close then Next:

8. On the Access Rule Destinations page, you want to create a new Computer object for your CA server. Click Add… drop-down New and choose Computer:

9. Type a descriptive name for your CA server and enter its IP address, then click OK:

10. Now drop-down Computers and select the CA Server or whatever you named yours. Then click Add and Close and you should see it in the list of destinations. Click Next:

11. User Sets you want to leave as the default, which is All Users. Click Next:

12. Click Finish to finish creating the new rule.

13. Now right-click on Firewall Policy again, then click on All Tasks > System Policy > Edit System Policy…

14. Click on Active Directory which is listed under Authentication Services and UNCHECK the Enforce strict RPC compliance checkbox:

15. Click OK.

16. You must now click the Apply prompt at the top of the TMG Management console window to push these changes into place. Click Apply and then Apply again to finish the configuration. You should now be able to successfully open the certificates MMC and request the computer template-based certificate from your CA.

Jordan Krause
Senior Customer Engineer and Microsoft Forefront Security Specialist
IVO Networks

Update 2 is now available for your IVO Unified Access Gateway (UAG) and DirectAccess Concentrator (DAC) appliances. Please take time to read the installation notes accompanying the download. Our recommendation as with any update is to download the file to your appliance and run it from an elevated command prompt. As always, if you have any questions or would like assistance with installing your update, please contact your IVO support engineer.

Click here to download UAG Update 2.

Here are details on what is provided with Update 2:

• Citrix publishing support—Forefront UAG fully supports Citrix Presentation Server 4.5 and its replacement Citrix XenApp 5.0.
• Citrix client computer support—Forefront UAG supports client computers with 64-bit operating systems accessing Citrix XenApp applications.
• Client Components—The Forefront UAG SSL Application Tunneling component is now supported on 64-bit Windows 7 operating systems for 32-bit applications.
• Virtual Desktop Infrastructure (VDI)—Forefront UAG fully supports publishing remote desktops using VDI.
• SSTP user and group access control—Forefront UAG now provides a finer authorization mechanism allowing administrators to authorize individual users or groups for SSTP access.
• SSL handshake—Forefront UAG now provides better handling of the SSL handshake including the case when the application server requires client certificate credentials for the negotiation.
• MAC address support—Forefront UAG Network Connector supports a wider range of network adapters with a larger valid MAC address range.

SP1 for Microsoft Threat Management Gateway is now available and approved. This update is available obviously to our TMG customers, but is also a recommended download for our UAG and DAC appliances as well. Both the UAG and DAC appliances are running TMG, and therefore this service pack absolutely applies!

As with all updates to our appliances, ensure that you run the MSP file from an elevated command prompt as opposed to simply double-clicking on the file. Please let us know if there are any questions or if you would like assistance with the installation procedure.

Click here to download TMG SP1.

Here is an overview of features and improvements included with this service pack:

New Reports
• The new User Activity report displays the sites and site categories accessed by any user.
• All Forefront TMG reports have a new look and feel.

Enhancements to URL Filtering
• You can now allow users to override the access restriction on sites blocked by URL filtering. This allows for a more flexible web access policy, in that users can decide for themselves whether to access a blocked site. This is especially useful for websites that have been incorrectly categorized.
• You can now override the categorization of a URL on the enterprise level; the override is then effective for each enterprise-joined array.
• Denial notification pages can now be customized for your organization’s needs.

Enhanced Branch Office Support
• Collocation of Forefront TMG and a domain controller on the same server, which can help reduce the total cost of ownership at branch offices.
• When installed on a computer running Windows Server 2008 R2, SP1 simplifies the deployment of BranchCache at the branch office, using Forefront TMG as the Hosted Cache server.

Support for publishing SharePoint 2010
• Forefront TMG SP1 supports secure publishing of SharePoint 2010.

Virtualization: A topic everyone loves to argue about. So much so that nobody can even agree on the spelling of the word! Is it virtualization? Or virtualisation? Maybe we’ll never know. Okay, so it’s more of a geographically-based preference than anything, but still makes my point that there is plenty of room for differing opinions surrounding the topic. Since my spell-checker is screaming at me to fix the “s” above, I’ll go with virtualization for this writing.

“Why would I want a hardware appliance when I can just create a virtual machine to do the job?”

Here is a question that crosses my desk all the time. Now that virtualization is fairly mainstream and much easier to use than it has ever been in the past, why aren’t companies moving all of their hardware to virtual machines? Answer: Performance, Security and Support. I’ll be speaking largely in relation to the Microsoft Forefront Edge products, as that’s much of what I do in my day job, but these are good topics for thought when considering moving any machine to virtual.

1.       Performance (and reliability)

The obvious limitation with virtual platforms that comes to mind is the sharing of resources. Sure, you can dedicate a certain amount of various resources to a particular virtual instance, but ultimately somewhere between the virtual OS and the “real network” you are flowing information through a physical piece of hardware and operating system of the virtual machine itself that is shared, thus decreasing its efficiency. Are you really going to want a remote access edge device which is hosting thousands of user tunnels to have the potential to share a NIC with another device for example? I wouldn’t. I have also had the “privilege” to be onsite during a failure of a very large virtual machine’s primary operating system, and frankly that is not a level of stress I would care to subject myself to again. Can you say “single point of failure”?

Another point that I discuss regularly in my planning and demonstration meetings is that using virtual machines removes the potential to utilize any hardware specifically designed to accelerate performance of particular edge devices. The best example that comes to mind is IVO Networks Unified Access Gateway (UAG) and DirectAccess Concentrator (DAC) appliances. These appliances are built with encryption processor chipsets integrated into the mainboard to offload the SSL and IPSec load to increase performance for UAG and DirectAccess traffic, something you would not have the benefit of using in a virtual environment.

2.       Security

“It’s difficult to make virtual machines secure”: understatement. Security concerns are the number one reason that edge devices do not make it to production on a virtualized platform. Typically one of the primary purposes of an edge device is to provide a barrier between the internet and your corporate network. Say you have a virtual host running a number of internal application servers and decide to add another virtual machine that is going to act as an edge device. Plug it into the external network, and you have just that quickly connected your entire virtual host to the internet. That reason alone is enough for most companies to call the whole thing off and run back to the safety of an appliance. However, it is still technically possible to proceed with this scenario and attempt to regulate and isolate the traffic, so I’ll discuss a few more points you may want to be aware of.

Defining security settings and traffic profiles on a virtual machine is much more important than on a dedicated appliance for a number of reasons. Your dedicated hardware appliance is likely configured specifically for the job you’re looking to accomplish, which means it’s already restricted and hardened out of the box. When setting up a virtual machine however, you are on your own to regulate and lock down the environment.

Defining security is also critical in a virtual machine because the requirements of one virtual instance will impact those of the other instances on the virtual host. It is quite easy in a virtually hosted environment to make a change on one partition that inadvertently renders security useless for all virtual machines running on that host. You may also run into any form of regulatory compliance requirements that simply prevent you from installing certain functions or applications together on the same virtual host.

While patching and blocking against potential threats is always important, these things become absolutely critical in a virtual environment. If the virtual parent is compromised, all of the child partitions are threatened. Furthermore, the child partitions retain certain amounts of access to the parent, and if just one of the virtual machines is compromised, you risk the parent and therefore all of its child partitions being compromised.

3.       Support

The answer to “Is my virtual configuration supported?” can be complicated. For the Forefront products, it in part depends on your company’s level of support with Microsoft, as well as your virtual platform vendor’s level of partnership with Microsoft. It only takes a few minutes of searching to come across one of a number of articles that state something to the effect of “Microsoft support engineers may request that a customer reproduce a reported problem on real hardware before continuing with the case”.

You will also want to be aware that many times installation and configuration processes change when using a virtual environment. In the case of Forefront Edge products, there are notes scattered throughout the configuration and deployment sections of the documentation detailing the additional steps that need to be taken when running products in a virtual machine.

In summary, I want to make it clear that I am not wholesale against virtualization. It is a great technology and will continue to gain popularity, however there are some definite shortcomings and serious considerations to be taken into account when planning the virtualization of a resource, particularly with products intended to run on the edge.

Jordan Krause is a Senior Customer Engineer and Microsoft Forefront Security Specialist with IVO Networks.