What will happen with TMG?

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

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

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

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

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.

netsh in ipv6 sh in

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

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

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

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

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

UAG DirectAccess Wizard

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

Configure IPv6 on Internal DA interface

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

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

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.