Monday, March 22, 2010 2:28 PM
Does anyone know when IPv6 will be fully supported in Forefront TMG 2010? This, I would like to known, because we are currently making our IPv4 platform ready for IPv6, but in our current platform we are making use of ISA 2006 (which does not support IPv6) and we might want to upgrade to TMG 2010, but as far as I have found, currently TMG 2010 only supports IPv6 for DirectAcces... I can't find any information about when TMG 2010 might fully support IPv6, so I am hoping someone could has more information on this topic!
With kind regards,
Monday, March 22, 2010 5:18 PMModeratorI wouldn't hold your breath any time soon :(
Jason Jones | Forefront MVP | Silversands Ltd
Thursday, March 25, 2010 4:21 PMModerator
Thank you for the post.
Just like you know, Forefront TMG does not support IPv6(IPv6 isn’t part of any current TMG planning). For your reference, please see: http://technet.microsoft.com/en-us/library/ee796231.aspx
Nick Gu - MSFT
- Marked As Answer by Nick Gu - MSFTMicrosoft Contingent Staff, Moderator Thursday, March 25, 2010 4:21 PM
Friday, April 02, 2010 11:05 AMGood question. I'm amazed myself that the long awaited successor of ISA 2006, TMG2010, does not support IPv6. The urge of migrating to IPv6 is getting bigger by the day and Microsoft manages to set IPv6 support aside for THE firewall and routing product they're offering just like that. We're migrating our networks to IPv6 as well and are looking for alternatives to phase out TMG2010 because it is the last piece that is stopping us from migrating fully to IPv6.
.NET Software Developer (MCP)
Friday, April 02, 2010 12:16 PM
Thanks for your reply! You've mentioned that you are looking for alternatives to phase out TMG2010 because of the lack of IPv6 support, so I was wondering, have you already found some alternatives? Because we are also looking at possible alternatives to TMG2010, because the current TMG2006 has an important role in our infrastructure.
Friday, April 02, 2010 12:32 PM
only recently all connections are supplied with IPv6 support by the ISPs so the migration to IPv6 is still fresh and ongoing. The TMG2010 block on the IPv6 digital highway was not encountered till earlier this week, so I haven't had the time yet to look into alternatives. Actually, seeking for alternatives, I found this forum topic. I guess it depends highly on what features you use of TMG2010. If it's mainly just the routing and firewall, there are alternatives to be found. Mostly based on *nix though, but they should be easy enough to set up without extensive *nix knowledge. For example, http://m0n0.ch/wall/ . If you're also using site-to-site VPN links, like I am, it gets a bit more tricky. I have no experience yet with this MoNoWall product, but it seems to have VPN support as well. I've also looked into using OpenVPN which does support site to site VPN and does have an extension to support IPv6, but still in an early phase and only in a bit odd and thus undesired fashion. I have my doubts if TMG2010/ISA2006 follows VPN protocol standards enough to be compatible with other VPN products, so it would probably mean that on all sites TMG2010 and ISA2006 would have to be phased out at once, which is quite a job.
I did already start to phase out TMG2010 for inbound client VPN connections using OpenVPN. My experiences so far with it are superb. It is very easy to set up, flexible in its options when it comes to routing traffic, can run on Hyper-V with an already built Ubuntu image in a matter of minutes and only takes 256 megs of RAM. It also only requires one customizable TCP network port to be opened, so its success rate on company networks is much higher as with standard VPN protocols.
That's kind of all I know at the moment, so I am open to suggestions/sharing experience on this matter.
.NET Software Developer (MCP)
Friday, April 02, 2010 4:05 PM
I've been giving this some more thoughts. In a small lab setup I've created the following environment. I am curious about your - and possibly other people's - opinion about this "solution".
I have three machines:
- Windows 2008 R2 acting as DHCPv6, DNS and primary Domain Controller
- Windows 2008 R2 acting as TMG2010 gateway
- Windows 2008 R2 acting as a server of non specific kind which uses the network
All servers are equipped with 2 NICs (lan and internet facing).
Servers #1 and #3 have an internal IPv6 address in the block fc00::192:168:50:0/112 on their lan facing NIC as well as an IPv4 address in the block 192.168.50.0/24. Server #2 only has an IPv4 address on its lan facing NIC which resides in the same 192.168.50.0/24 block.
Server #2 has a public IPv4 address on its internet facing NIC but no IPv6 address due to the lack of IPv6 support in TMG2010.
Servers #1 and #3 have a public IPv6 address on their internet facing NICs with accompanying IPv6 gateway on the internet, but no IPv4 address.
The Windows firewall is enabled on servers #1 and #3 for the NIC facing the internet and are configured to block all incoming traffic.
The internal nic on servers #1 and #3 have the internal IPv4 address of server #2 as their gateway.
Now when I want to reach an IPv6 site on the internet from either server #1 or #3, it will use its internet facing IPv6 enabled nic to do so. When trying to reach an IPv4 host on the internet, it will use the internal nic to route the traffic to server #2 which will route it outbound.
This works like a charm. The thing I don't really like though, is that my internal servers #1 and #3 are now directly bound to the internet. They do have the Windows firewall enabled to block all incoming traffic though. How are you in this matter? Is this acceptable?
The downside is that you have to keep an IPv4 and IPv6 administration on your internal network. You can't phase out IPv4 because you're stuck with server #2 on which TMG2010 blocks all IPv6 traffic. I have seen a VB script floating around on the net which can force TMG2010 in allowing IPv6 for the corporate lan though. But even if that works, you're stuck with the next question which is how to tell servers #1 and #3 to route IPv4 traffic to server #2 over IPv6.
.NET Software Developer (MCP)
Monday, April 05, 2010 4:35 PM
It's a bit of a conondrum.. there's a couple of features missing from TMG such as IPv6 support and transparent bridging which would really add value, but the emphasis (sadly) for TMG seems to be on improving management of outbound traffic versus inbound, eschewed in favour of UAG. There's still a lot of things IMO which TMG does have to offer which UAG doesn't "easily" provide; configuration of front-end and back-end authentication is one that springs to mind. Conversely, there are things flat out that TMG doesn't do.. SSL-VPN, (inbound) endpoint management, DirectAccess etc..... I do miss the fact that UAG tho, which sits atop or aside TMG (depending on your perspective), doesn't yet support changes thru the TMG interface, no doubt because this has unforeseen consequences on UAG behaviour, but there continue to be things that TMG does with more fluidity, e.g. , the configuration of listeners versus trunks... maybe because it's a 1.0 product......
Monday, April 05, 2010 5:17 PM
It's a bit of a dilemma :-).. there's a couple of features missing from TMG such as IPv6 support and transparent bridging which would really add value, but the emphasis (sadly) for TMG seems to be on improving management of outbound traffic , eschewed in favour of UAG for inbound management. There's still a lot of things IMO which TMG does have to offer which UAG doesn't "easily" provide; configuration of front-end and back-end authentication is one that springs to mind. Conversely, there are things flat out that TMG doesn't do.. SSL-VPN, (inbound) endpoint management, DirectAccess etc..... I do miss the fact that UAG tho, which sits atop or aside TMG (depending on your perspective), doesn't yet support changes thru the TMG interface, no doubt because this has unforeseen consequences on UAG behaviour, but there continue to be things that TMG does with more fluidity, e.g. , the configuration of listeners versus trunks... maybe it's because it's a 1.0 product, notwithstanding IAG......
Tuesday, April 06, 2010 9:46 AM
I've been giving your idea some thought and as you state, you do not really like that the internal servers #1 and #3 are directly connected to the internet, but on the other hand, that's one of the basic ideas of IPv6, no more need for NAT and every device it's own public IPv6 address... So I think that this could be acceptable, because you could make use of IPSec to connect to an IPv6 site on the internet for example, but how will it work if an IPv6 site on the internet is trying to connect to server #1 of #3?
Bot servers, #1 and #3 block all IPv6 traffic on there NIC facing the IPv6 internet, also the TMG 2010 server is blocking all IPv6 traffic, so it is not possible to connect from an IPv6 site to one of the servers in your network? This, unless you allow the TMG 2010 server to allow all IPv6 tunneled traffic over IPv4, for which then you have to also enable the firewall on the servers #1 and #3 for there internal NICs, because I thougth, TMG 2010, is not able to filter the tunneled traffic, but is only able to or allow all or block all IPv6 tunneled traffic.
In our network, we are also making use of an front and back-net (both IPv4 at the moment) and separated by ISA 2006, so if I look at your idea in combination with our current network, every server that has an front-net connection has to get an extra NIC that is connected to the IPv6 internet directly to allow to connect to IPv6 sites. It is possible I think, but not really preferable in my opinion
I also think that for the near future, you do not want to phase out IPv4, because a lot of networks will keep making use of IPv4 for at least the next few years, and if you phase out IPv4, it is not possible to connect from the IPv4 sites to your IPv6 site anymore.
So what do you think, how can the problem with connecting from an IPv6 site to server #1 or #3 be solved?
Tuesday, April 06, 2010 12:52 PM
thank you for sharing your thoughts! Interesting mind sharing session in my opinion.
Regarding your first paragraph, I felt exactly the same. Connecting i.e. your Domain Controller directly to the internet somewhat feels "scary", though indeed going back to - one of the - reasons why NAT was established is because of the shortage in IPv4 addresses. IPv6 should allow every host - internal or externally faced - to be routable through the internet. And that is exactly what we're doing in this case. With a properly configured firewall, this shouldn't be too much a problem, I think (not totally comfortable with the idea yet).
Regarding your second paragraph, if you willingly choose to offer services of your server to the internet over IPv6, you will decide upon opening the proper ports on the Windows firewall of the server and thus make it accessible over IPv6. Let's say server #3 is set up as a webserver with a public website with the domain name www.mysite.com. If you set the AAAA record for www on mysite.com to the public IPv6 address of server #3 and open up port 80 TCP on server #3, everyone on the internet with an IPv6 link will be able to connect to your server, right? If you want to provide backward compatibility with IPv4, you could set up an A record for www on mydomain.com pointing to the IPv4 public address of your TMG server at server #2. You could configure TMG on server #2 to forward all requests on port 80 with host header www.mydomain.com to the internal IPv4 address of server #3.
Regarding your third paragraph, that's questionable. Drawing a line from the IPv4 "generation" with often separated front- and backend networks into the IPv6 "next generation" networking, you are right. You would require all your servers to have two NICs. But perhaps this idea has also become outdated with the idea of every server being publically routable by its IPv6 address. Why would there be a need of two separate networks over which you can reach the same servers? Couldn't we just maintain the public IPv6 infrastructure and configure the firewalls so that certain "internal" traffic will only be allowed from our own IPv6 CIDR block? This idea was raised by the experience I encountered as described in the next paragraph.
A thing I noticed last weekend in my test setup was that after setting everything up as described in my previous post, that Windows would automatically merge both the internet NIC and lan NIC under the Domain profile. At first I thought "argh why!?!". But giving it another thought, it's actually logical. Since I hadn't configured the firewalls properly yet, server #3 could reach the Domain Controller at server #1 through both the LAN NIC as well as through the internet NIC, so why WOULDN'T Windows threat both network connections as being the domain network? The problem was that, to my knowledge, you can't force a NIC into a specific network profile. With Windows 2008R2 you no longer set firewall permissions on a NIC, but on a network profile instead. I removed IPv6 on my Domain Controller at server #1, rebooted server #3 and Windows would categorize the internal NIC on server #3 as being in the domain profile again and the external NIC on server #3 as being in the public network profile. By setting the proper firewall settings on both network profiles to disallow Domain Controller traffic through the public profile and allow Domain Controller traffic through the domain profile, this "problem/situation" would disappear and Windows would correctly identify the internal NIC as the domain NIC and the internet NIC as the public NIC, thus allowing me to apply different firewall settings to both network profiles.
The firewall configuration becomes quite tricky because of this though. An error in the configuration of the firewall could easily lay open your server to everyone on the internet. And the built in Windows firewall isn't one of the easiest to configure either, so errors are prone to happen.
Better would be a TMG2010/ISA2006 a-like product that would allow setup of a route relationship between the internet and your IPv6 CIDR block, using the public IPv6 addresses on your LAN and allow the proper access by configuring TMG2010/ISA2006. This would make it a breeze to configure and maintain. But since this isn't possible, the question is what alternative products are out there which CAN do this.
Regarding your fourth paragraph, indeed, quite some products are not compliant with IPv6 yet, so they will require the IPv4 infrastructure on your local network to be kept in place. Again, a TMG2010/ISA2006 product capable of IPv6 would be very handy in this case where you could forward traffic for a specific IPv6 interface to an internal IPv4 interface to provide backward compatibility. Keeping IPv4 in place does however, in my opion, keeps the requirement for two NICs per server. Or you must route your internal IPv4 traffic over the same NIC as your internet IPv6 thus sharing one physical network connection. With proper routing tables on your routers the IPv4 traffic can never leave your internal network where the IPv6 traffic can. Though this introduces us to the problem where we only have one NIC and network profile and firewall rule set to configure. I did a test on this with a Windows 7 client (so one NIC with a private IPv4 address and a public IPv6 address), but both IPv4 and IPv6 use the same firewall rules. Simply disallowing IPv6 communication wouldn't work. I tried configuring the Windows firewall to allow RDP over TCP 3389 for IPv4 and disallow it for IPv6, but I couldn't because there is no option to filter by IP version. I guess I could try only allowing traffic on TCP 3389 from my private IPv4 range and own IPv6 CIDR block. I haven't tried that yet. Does raise the question if we're protected against IP address spoofing though and does enable the requirement to create a firewall rule for each and every type of communication you want to allow on every machine - instead of having a by default considered safe for all traffic internal network and a considered dangerous by default external network. ____ of a job.
Of course TMG2010/ISA2006 does more than just routing/firewalling, so by binding all our servers directly to the internet, we also loose the centralized defense mechanisms against i.e. flooding and port scanning. But once again, what other options do we have?
.NET Software Developer (MCP)
Monday, February 07, 2011 3:05 PMpage http://technet.microsoft.com/en-us/library/ee921439.aspx give more ipv6 tips
Thursday, June 02, 2011 9:34 AMThanks for sharing this pointer. Its still an ugly hack into TMG 2010 basically for DirectAccess though. Bring on the IPv6 support in TMG2010 Microsoft!