UAG – Page 2 – Kent Nordström

What will happen with TMG?

Posted on May 28, 2011 by Kent

What is the plan for TMG in the future? Will it vanish or will it just be a part of the next generation where TMG and UAG become one “Unified Gateway”?

Why suddenly ask these questions you might wonder, well…

The last Gartner report, published 25 May 2011, on Secure Web Gateways presents the following Maqic Quadrant for Secure Web Gateways.

Magic Quadrant for Secure Web Gateway

As you can see it does not list TMG and the report contains the following text:

“Microsoft has informed Gartner that it does not plan to ship another full version release of its SWG product, the Forefront Threat Management Gateway (TMG). The product is effectively in sustaining mode, with Microsoft continuing to ship Service Pack (SP) updates; the next one, SP2, is planned for 3Q11. Microsoft will also continue to support TMG for the standard support life cycle — five years of mainstream support and five years of extended support. In the SWG category, TMG will become less competitive over time, since Microsoft’s goal is not to compete head-to-head with other vendors in that space. We believe that Microsoft will repurpose TMG technologies in other products and services as part of its overall cloud strategy.”

I have spent the last few days trying to get some “official” comments on this from Microsoft but has so far failed. So we can only speculate what this means.

My speculation around this is that this is part of the cloud strategy as mentioned in the Gartner report and UAG is the gateway product prepared for the cloud. My guess and speculation is that this is not the end of TMG as function but maybe as standalone product. I think we will see TMG and UAG merge into one “Unified Gateway”.

[Update 2011-05-31]

During the last 48 hours I have recieved information leading me to believe my guess and speculation above is not entirely correct. The “truth” is not yet revealed but hopefully Microsoft realize that customers and partners are waiting for clarification on the product roadmap of TMG and UAG.

[End of Update]

As soon as any official statement is presented I will add that to this post.

[Update 2012-09-17]

Important changes to Forefront product roadmaps

[End of Update]

Article on Adding IPv6 to your UAG

Posted on May 1, 2011 by Kent

So finally a new article i finished. Managing IPv6 addresses in a DirectAccess environment is not easy. Hopefully my new article Adding IPv6 to your UAG Environment will help you understand how IPv6 on the DA server works.

Adding IPv6 to your UAG Environment

Posted on April 30, 2011 by Kent

It’s not a question of “if”, it’s “when”. I am talking about when you will implement IPv6 on your UAG. In this article I will show you how to do it.

In this guide I use UAG 2010 SP1 for all my screenshots. If you do not have SP1 yet I suggest you stop reading and upgrade your UAG environment to SP1 before continuing.

IPv6 and DirectAccess (DA)
Many of you might think that if you implement IPv6 in your internal environment you will no longer need UAG as DA server. Well your wrong, the main reason is that you will still need DNS64 and NAT64 to access the resources in your network still in IPv4 address range. UAG also gives you a much better configuration interface, especially with SP1. There are more reasons, but this article is not to convince you to use UAG, I will assume the reader is already convinced.

UAG with DA is already IPv6 configured
When you configured DA on your UAG you noticed that IPv6 is a big part of DA. If you do a simple “ipconfig” you will notice several IPv6 addresses, if you then do a “route print” you will see a lot of IPv6 routing going on. But if you in the DA configuration look at the step, where you configure the external and internal addresses UAG should use, you will notice that you cannot choose an internal IPv6 address.

A basic knowledge on IPv6 addressing is required to follow me in this article, but let me just refresh your memory on some of the prefixes we use in UAG that I will talk about. 6to4: 2002::/16, Teredo: 2001::/32 and Link Local Unicast: FE80::/10

Adding IPv6 address to UAG
Although you could have UAG use some dynamic method to get it’s IPv6 address I strongly recommend you to do manual configuration of the IPv6 address. Hopefully this article will show you why. So lets take a look some things you need to configure in order to assign UAG an IPv6 address.

Internal IPv6 Address on UAG

Even if you can use netsh to assign the IPv6 address I will show the UI way.
Open up the IPv6 properties of your “internal” adapter.
Before you assign an address you need to know the internal prefix used in your IPv6 deployment. In my example this is 2001:1630:100:10::/64 which is the /64 range I use in my server VLAN, this is from the 2001:1630:100::/48 my company was assigned by the ISP. I assign the address 2001:1630:100:10::12 to the interface but NO default gateway. I will soon explain why.
I also assign the interface two internal DNS servers.

After adding the IPv6 address we need to take a look at the interface in more detail and understand why we did not add a default gateway.

Start an elevated command prompt and run
“netsh int ipv6 sh int” this will list the UAGs interfaces in the IPv6 world. As you can see there are quite a few. Find the internal interface and notice the number or name.

netsh in ipv6 sh ro – with routerdiscovery enabled

If you run netsh int ipv6 sh ro you will see the routing information UAG has regarding IPv6 traffic. As you may notice UAG has multiple default gateways (::/0 in the IPv6 world). This is due to the fact that router discovery is automatically enabled causing us to have a very complex routing situation. We need to take control over the routing… So lets look at that.

Manage IPv6 Routing in UAG
First we need to understand that apart from DirectAccess traffic UAG cannot operate as IPv6 router. Since you during setup probably enabled IPv6 on the external interface, you might have a situation where UAG automatically picked up an external IPv6 address. UAG will however not route traffic between it’s internal and external interface, the local TMG will prevent that.

netsh in ipv6 sh in 11 – Internal interface

Run “netsh int ipv6 sh int 11”, where 11 is the number of the internal interface in my example. You will then get the settings for the internal interface. Some of these you need to understand if you will be able to configure your UAG correctly.

Router Discovery = enabled/disabled, tells UAG to or not to, listen to router messages on the network. If disabled we will need to configure static routing on UAG if there are other subnets that UAG needs to know about. If this is set to enabled troubleshooting routing on UAG will be a lot more tricky. I recommend that you disable this on both the internal and external interface using the command. Netsh int ipv6 int 11 set routerdisc=dis. Where “11” is the number of the interface. Be careful so that you do not touch any of the DA related interfaces.
IMHO I think that router discovery should be disabled on all IPv6 machines that has static IP’s. Otherwise they will end up with two, one static and one dynamic from the network advertised by the router.

Advertising=disabled tells UAG not to advertise routes on the interface. I prefer to use a dedicated IPv6 router doing the advertising of routes on the network, and UAG as we stated earlier is not an IPv6 router in that sense. UAG will “own” several prefixes in your IPv6 world and your internal IPv6 router will need to handle that.

After configuring the interface we do a new check on the routing table

netsh in ipv6 sh ro – routerdiscovery disabled

After disabling router discovery we now only have one default gateway on the UAG. This points to it’s own 6to4 router interface gateway.

netsh in ipv6 sh in iphttpsinterface

UAG will still advertise its routes to the DirectAccess clients, which you can verify by checking the Advertise flag on these interfaces.

Configure DA to use IPv6 internally
After fixing the IPv6 address and routing it is time to configure UAG DirectAccess to use the internal IPv6 address.

UAG DirectAccess Wizard

This is quite simple, just open the DirectAccess configuration and and edit step 2.

Configure IPv6 on Internal DA interface

You will now have the choice to select your IPv6 address as Internal IPv6 address.

You will then be asked to tell UAG what prefixes it should use for different purposes.

Configure DA IPv6 Prefixes

In my example the “company” prefix is 2001:1630:100::/48
I have decided to use 2001:1630:100:20::/64 for IPHTTPS Clients and 2001:1630:100:30::/64 for NAT64. UAG will not use the whole /64 prefix for NAT64, but for internal routing purposes it is easier to declare that the whole /64 prefix is “owned” by UAG.

IPv6 Router – Route Table

So on my IPv6 router I have the routes above pointing the following routes to UAG.
2001:1630:100:20::/64 – IPHTTPS
2001:1630:100:30::/64 – NAT64
2002::/16 – 6to4
2001::/32 – Teredo

When this is configured your are good to go, publish in AD and activate the configuration.

What about ISATAP?
You might have noticed that UAG tells you it will no longer work as ISATAP router when using IPv6. This is because logically you would not need ISATAP since you have IPv6 on the Internal network. However you might still in some scenarios have the need for ISATAP, and if so, I suggest you configure a separate ISATAP router, and tell this ISATAP router how to route the traffic to the IPv6 prefixes operated by UAG.

Conclusion
To summarize, it is not difficult to configure UAG in an IPv6 environment, as long as you have control over your internal IPv6 addressing and routing.

Ping using 6to4 tunnel not working

Posted on April 17, 2011 by Kent

UAG can be used as both DA server and to publish applications over SSL.

In a scenario where UAG has both roles you might run into a situation where ping does not work when connected using DirectAccess over 6to4 tunnel.

This is due the fact that if UAG has multiple roles it will have multiple IP’s on external interface. In my example the UAG has the following IP’s on the external interface.

UAG External adapter IPs

The first two .67 and .68 are used for trunks, publishing applications, and .77, .78 are used by DA.

When a client is connected using 6to4 tunnel and tries to ping an internal resource it fails. Lets look at this in a network monitor trace on the UAG server.

Echo Request from 6to4 Client

The client send a ping request to internal resource 2001:1630:100:10::120, using its 6to4 tunnel endpoint .77. So far all looks good.However lets look at the next packet the echo reply.

Echo reply from UAG to 6to4 Client

UAG sends the reply from the resource back to the client on the internet. But uses the wrong source address, instead of .77 UAG uses it default IP on the external interface .67.

This does not mean DA is not working, just that ping will not work.

Dr. Shinder has written a good article on using ping to troubleshoot DA that explains this.

Solution to this issue is to make sure that UAG has it’s first DA IP as the primary IP. I have for the moment not been able to test this in a load balanced environment. But looking at the current fact, I would guess ping will not work when using load balanced UAG’s since I believe that UAG will use its primary IP in that case as well when sending the reply.

Use KCD to secure your infrastructure

Posted on April 4, 2011 by Kent

In todays world, working remotely, and accessing information from outside the corporate network, is a demand. One huge problem with many solutions today is that this will make us expose our domain password on un-secure clients like mobile phones and internet café’s. On these un-secure devices it is very hard for us to know if there is some kind of password snatcher, and if the password is stolen this can often be used to logon to our corporate resources.

KCD (Kerberos Constrained Delegation) makes it possible for us to build solutions that do not require the domain password to access resources like ActiveSync, OWA and Sharepoint. Microsoft ForeFront UAG and TMG are two great products that can make use of KCD to secure your infrastructure.

How to make it work…
What you do is that you configure TMG/UAG to authenticate using a method that do not require the users domain password. This could be an OTP (One Time Password) for example. You then configure delegation to use KCD and UAG/TMG will request a Kerberos ticket on behalf of the user and present that as credentials to the service. In many scenarios you will find that UAG´s more flexible authentication options will make this much easier using UAG then TMG.

The ActiveSync example…
ActiveSync is widely used to access email based on Microsoft Exchange. Usually this means the username and password of the domain account is stored in the device. A mobile phone, no matter how “smart”, is not a secure platform. What you can do is to configure a second identity store where the username and “activesync password” is stored. You then use UAG/TMG to authenticate against that store and then use KCD to get the users data from Exchange. This way the password stored in the device is not the same as the domain password and you can also enforce a different password complexity and change policy.

Prerequisites…
First of all we need to understand that in order for KCD to work there are some demands on the infrastructure.

The UAG/TMG server must be a member of the same domain as the resource the user tries to access.
UAG/TMG needs to be trusted for delegation for the specific service
The username needs to be the same if using multiple identity stores.
The resource needs to accept Kerberos authentication.

More to come…
I am currently working on a more detailed article to show how to configure the ActiveSync example using UAG and AD LDS as the ActiveSync user store. I might even throw in a section on how FIM (ForeFront Identity Manager) can be used to automate the process of managing the second identity store required in this example.

NLB and Procurve – Not the best combination

Posted on February 4, 2011 by Kent

Using NLB to build TMG (or UAG) clusters is heavily dependent on switches used. HP Procurve has shown to not being “up to the job” in many cases.

After spending the last days helping a customer Migrate from ISA to TMG and trying to figure out how to get NLB to work in their environment I thought i should share some findings.

Unicast or Multicast
It is important to remember that TMG does not care if you use Uni- or Multicast. This is entirely a switch problem. Problem is that many network guys do not know how to pick the right one for the specific switch model at hand.

NLB in Procurve
When using typical Procurve switches (like 2800-series) you will find yourself stuck on using Unicast NLB and also having to add some static MAC-address entries in the environment.

When trying to use Multicast NLB we discovered that HP switches will not let you add Multicast MAC-addresses as static entry’s in many models.

One thing that i noted in this project is total lack of information from HP on how to integrate NLB with there different models.

Why NLB?
Many of you might say… Stop using NLB and get a HW LB instead…
In my opinion NLB should always be the first load balancing you should consider when building TMG and UAG clusters.

Why?… Simply because this is the one integrated into the product. If using any other LB you will not benefit from TMG’s integrated management. Configuring a stand-alone LB to detect service failures in TMG to cause a node-drop is not an easy task. I have also found that when using external LB you will in many cases not be able to use routed relations and will have some serious problems to get bi-directional affinity to work, especially in protocols like RPC.

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: