Tuesday, February 02, 2010
How to prevent ipv6 tunneling across firewalls and routers
Perhaps it is a company policy or someone on your IT team feels it is important to block IPv6 tunneling across your network to 6to4 relays or Teredo relay servers or perhaps you only want internal folks using your delegated IPv6 address block. Do you have any options available to you to block this sort of traffic?
As it seems with all things tech related the answer is, it depends on what you want to do. Both 6to4 and ISATAP utilize IPv4 protocol 41 to tunnel their traffic. Therefore, it is easy enough to block IPv6 protocol 41 from traversing internally (which would stop ISATAP and 6to4) or at the edge firewall (which would stop 6to4 but might not stop ISATAP.) On Cisco IOS it might look like this on an internal router or switch:
access-list 100 deny 41 any any
access-list 100 permit any any (or whatever traffic you DO want to permit)
In addition, to this step you can blackhole the IPv4 route to 192.88.99.1 which is the IPv4 anycast address used for the 6to4 IPv4 relay. On Cisco IOS you could do:
ip route 192.88.99.1 255.255.255.255 null0
Teredo clients can be blocked in a simple method because by design it utilizes UDP over IPv4 to establish and build it's NAT traversal tunnel traffic. Simply blocking outbound UDP traffic solves the problem but certainly breaks a lot of other functions for end client machines.
If you are running a Microsoft Windows AD configuration with clients belonging to the domain you can poison the Teredo entry that is used by default on a Microsoft client machine. All Microsoft clients from Windows XP on up make use of the dns name teredo.ipv6.microsoft.com to resolve if they can utilize Teredo to build out an IPv6 connection. This likely isn't the best method but it can be effective and some might say required because from Windows Vista on up Teredo is enabled by default but is inactive. This means if an application gets installed that wants to make use of Teredo it activates the Teredo client and attempts to use it.
You can also use a GPO to change the registry keys to keep Teredo off. You can push firewall changes to the Windows clients (Vista and Windows 7) that would block Teredo or you could turn off IPv6 which would solve the problem also. Microsoft has documentation on all of those options, you can start looking here, here or here to find out more.
So, in those cases where you actually need to turn off IPv6 tunneling technologies there are options available. The next question is do you really want to block these technologies?
- Ed
As it seems with all things tech related the answer is, it depends on what you want to do. Both 6to4 and ISATAP utilize IPv4 protocol 41 to tunnel their traffic. Therefore, it is easy enough to block IPv6 protocol 41 from traversing internally (which would stop ISATAP and 6to4) or at the edge firewall (which would stop 6to4 but might not stop ISATAP.) On Cisco IOS it might look like this on an internal router or switch:
access-list 100 deny 41 any any
access-list 100 permit any any (or whatever traffic you DO want to permit)
In addition, to this step you can blackhole the IPv4 route to 192.88.99.1 which is the IPv4 anycast address used for the 6to4 IPv4 relay. On Cisco IOS you could do:
ip route 192.88.99.1 255.255.255.255 null0
Teredo clients can be blocked in a simple method because by design it utilizes UDP over IPv4 to establish and build it's NAT traversal tunnel traffic. Simply blocking outbound UDP traffic solves the problem but certainly breaks a lot of other functions for end client machines.
If you are running a Microsoft Windows AD configuration with clients belonging to the domain you can poison the Teredo entry that is used by default on a Microsoft client machine. All Microsoft clients from Windows XP on up make use of the dns name teredo.ipv6.microsoft.com to resolve if they can utilize Teredo to build out an IPv6 connection. This likely isn't the best method but it can be effective and some might say required because from Windows Vista on up Teredo is enabled by default but is inactive. This means if an application gets installed that wants to make use of Teredo it activates the Teredo client and attempts to use it.
You can also use a GPO to change the registry keys to keep Teredo off. You can push firewall changes to the Windows clients (Vista and Windows 7) that would block Teredo or you could turn off IPv6 which would solve the problem also. Microsoft has documentation on all of those options, you can start looking here, here or here to find out more.
So, in those cases where you actually need to turn off IPv6 tunneling technologies there are options available. The next question is do you really want to block these technologies?
- Ed
Labels: IPv6, Microsoft, Security
Tuesday, October 06, 2009
Some IPv6 information link updates
I am doing some work for a client getting their public IPv4 blocks from ARIN so I thought I would share some useful IPv6 links they have now up at the ARIN site since I was looking around anyway.
ARIN now as an IPv6 Wiki page that has some good content and an IPv6 Information Page which has additional links that might interest someone who is getting started with IPv6.
I still really recommend that folks check out Hurricane Electric's excellent free IPv6 tunnel broker services. For those that want to start playing with IPv6 this is an awesome resource.
Check out the ARIN Number Resource Policy Manual regarding IPv6, some interesting stuff is in there regarding the goals of IP address space management. Its worth a quick read, especially if you are securing IPv6 address space for a client or your own company. If you don't have IPv6 on your roadmap yet as something to address I think the year 2010 will be when you really need to add it to your list of items.
If you want some fast training on IPv6 but there are some e-learning sites like 6diss.org and there are some excellent white papers at Microsoft and at Cisco also.
- Ed
ARIN now as an IPv6 Wiki page that has some good content and an IPv6 Information Page which has additional links that might interest someone who is getting started with IPv6.
I still really recommend that folks check out Hurricane Electric's excellent free IPv6 tunnel broker services. For those that want to start playing with IPv6 this is an awesome resource.
Check out the ARIN Number Resource Policy Manual regarding IPv6, some interesting stuff is in there regarding the goals of IP address space management. Its worth a quick read, especially if you are securing IPv6 address space for a client or your own company. If you don't have IPv6 on your roadmap yet as something to address I think the year 2010 will be when you really need to add it to your list of items.
If you want some fast training on IPv6 but there are some e-learning sites like 6diss.org and there are some excellent white papers at Microsoft and at Cisco also.
- Ed
Wednesday, July 15, 2009
DirectAccess and Forefront UAG plus IPv6
For those who are watching the happenings in Microsoft's DirectAccess solution the most interesting news as of late is from the Forefront Unified Access Gateway product group. They announced at the end of last month the availability of a UAG DirectAccess solution.
I participated in one of the Microsoft MVP LiveMeeting session on it and I think the most compelling part of using UAG for DirectAccess is the easy of provisioning the solution. They have a nice wizard driven deployment set up which I think will make getting DirectAccess up and going much easier. The nice part is that they handle setting up the NAT-PT (NAT64) and other transition tunneling needed to get the solution up and working.
I downloaded the beta and will be trying it out next week at our office. We just finished rolling out native IPv6, IPv6 routing and even got IPv6 working over Cisco DMVPN. We have Windows Server 2008, Windows 7, Ubuntu 8.10 and 9.04 all working on IPv6 and we even have our Cisco Communication Manager and IP handsets working on IPv6 now.
With the addition of the UAG DirectAccess we will have a complete solution that also integrates Microsoft OCS and MOC with our Cisco Unified Communications infrastructure. Pretty cool stuff.
- Ed
I participated in one of the Microsoft MVP LiveMeeting session on it and I think the most compelling part of using UAG for DirectAccess is the easy of provisioning the solution. They have a nice wizard driven deployment set up which I think will make getting DirectAccess up and going much easier. The nice part is that they handle setting up the NAT-PT (NAT64) and other transition tunneling needed to get the solution up and working.
I downloaded the beta and will be trying it out next week at our office. We just finished rolling out native IPv6, IPv6 routing and even got IPv6 working over Cisco DMVPN. We have Windows Server 2008, Windows 7, Ubuntu 8.10 and 9.04 all working on IPv6 and we even have our Cisco Communication Manager and IP handsets working on IPv6 now.
With the addition of the UAG DirectAccess we will have a complete solution that also integrates Microsoft OCS and MOC with our Cisco Unified Communications infrastructure. Pretty cool stuff.
- Ed
Labels: IPv6, Microsoft DirectAccess, Microsoft Windows 7
Friday, May 15, 2009
Microsoft DirectAccess - some brief thoughts
I think out of anything coming out of the Microsoft Server 2008 R2 and Windows 7 releases the feature I am most excited about is DirectAccess (anyone remember DirectConnect?) Microsoft has some excellent content starting to build up at http://www.microsoft.com/directaccess which gives an overview of how DirectAccess works and how it can be utilized so I won't repeat that here.
I have had the chance due to both my Microsoft MVP status and Springboard STEP status to have access to some deployment guides that are not generally available. After reviewing these and after playing with gear I have some opinions on what Microsoft should be recommending to IT Pros to do as initial trials of DirectAccess.
In a nutshell, I believe that people should set up an initial native IPv6 deployment with a tunnel broker (use Hurricane Electric) and get native IPv6 addresses working in their environment. In addition, I would minimize the deployment model to utilize proxy services or a NAT-PT device for resources on the network that are available via DA. This model comes pretty close to many VPN deployments today but does not have the pain involved with doing a functional overlay technology like ISATAP.
So, what do I mean by proxy services in this case? Well, for those deploying DA, I would set up a new Server 2008 R2 machine to front end file servers that are still running Server 2003 or older by utilizing SharePoint, that same server or an additional one could potentially do Exchange OWA or front end services depending on what Exchange environment you are on. I would utilizes a NAT-PT for specific line of business applications but I would narrow the selected application list initially to reduce troubleshooting on the NAT-PT device. There are options for NAT-PT devices, Cisco can do it in software on their routers and there is the Forefront UAG from Microsoft.
Most importantly, I would set expectations that there are a lot of moving parts with DirectAccess to get a deployment done correctly. You need to have PKI with a public CRL, IPv6, Windows Server 2008 R2 and Windows 7 just as minimum requirements, that doesn't say anything about the networking technologies you have to learn.
DirectAccess has the potential to bring about some of the most exciting changes in how people will work in the future on Windows but it will take a lot of planning and testing to get it all right.
I'll post more thought shortly.
- Ed
I have had the chance due to both my Microsoft MVP status and Springboard STEP status to have access to some deployment guides that are not generally available. After reviewing these and after playing with gear I have some opinions on what Microsoft should be recommending to IT Pros to do as initial trials of DirectAccess.
In a nutshell, I believe that people should set up an initial native IPv6 deployment with a tunnel broker (use Hurricane Electric) and get native IPv6 addresses working in their environment. In addition, I would minimize the deployment model to utilize proxy services or a NAT-PT device for resources on the network that are available via DA. This model comes pretty close to many VPN deployments today but does not have the pain involved with doing a functional overlay technology like ISATAP.
So, what do I mean by proxy services in this case? Well, for those deploying DA, I would set up a new Server 2008 R2 machine to front end file servers that are still running Server 2003 or older by utilizing SharePoint, that same server or an additional one could potentially do Exchange OWA or front end services depending on what Exchange environment you are on. I would utilizes a NAT-PT for specific line of business applications but I would narrow the selected application list initially to reduce troubleshooting on the NAT-PT device. There are options for NAT-PT devices, Cisco can do it in software on their routers and there is the Forefront UAG from Microsoft.
Most importantly, I would set expectations that there are a lot of moving parts with DirectAccess to get a deployment done correctly. You need to have PKI with a public CRL, IPv6, Windows Server 2008 R2 and Windows 7 just as minimum requirements, that doesn't say anything about the networking technologies you have to learn.
DirectAccess has the potential to bring about some of the most exciting changes in how people will work in the future on Windows but it will take a lot of planning and testing to get it all right.
I'll post more thought shortly.
- Ed
Labels: IPv6, Microsoft DirectAccess, NAT-PT
Tuesday, April 21, 2009
Microsoft Springboard on Windows 7
I've been lucky enough to be added as part of the Microsoft Springboard Series Technical Expert Panel or STEP program for Windows 7. I've been developing IPv6 content for people participating in the Springboard series to present to their local IT Pro User groups. Check out the Springboard series, Stephen Rose has been doing a great job getting all this content together, its a huge effort.
After the IPv6 content I will likely move on to a quick guide for Direct Access. Direct Access requires Windows Server 2008R2 and remember that Server 2008R2 is 64bit only.
I also just finished chatting with Charley Wen with Microsoft on all things related to QoS within Windows. It will be interesting seeing what solutions Microsoft comes up with for Server and Hyper-V that account for QoS and virtual switch infrastructure.
I am also betting that the RC for Windows7 and Server2008R2 will be out next week. I need to get stuff built out and I would like to use the RC's if possible.
- Ed
After the IPv6 content I will likely move on to a quick guide for Direct Access. Direct Access requires Windows Server 2008R2 and remember that Server 2008R2 is 64bit only.
I also just finished chatting with Charley Wen with Microsoft on all things related to QoS within Windows. It will be interesting seeing what solutions Microsoft comes up with for Server and Hyper-V that account for QoS and virtual switch infrastructure.
I am also betting that the RC for Windows7 and Server2008R2 will be out next week. I need to get stuff built out and I would like to use the RC's if possible.
- Ed
Labels: IPv6, Microsoft Windows 7
Thursday, March 05, 2009
Microsoft 2009 MVP Summit - thoughts
I wasn't sure if I was going to attend the Microsoft MVP Summit this year. After the MVP program decided to remove the Windows Server - Networking category I didn't think I had much reason to attend and honestly was expecting to not be renewed because of the category going away.
I am now very happy I changed my mind and I attended. It seems that my new category of Enterprise Security felt that it was important to add networking sessions back to the mix.
A ton of folks from the MS Networking Team showed up! From Sandeep Singhal, Sean Siler, Dave Thaler, Ravi Rao, Tyler Barton, Devrim Asli Iyigun, Mahesh Prakriya, to Joseph Davies - thanks to you all for taking the time and effort to listen to my feedback and opinion about networking and what Microsoft is doing right and wrong.
So, without violating my NDA what was I most excited about from the event? Honestly, it is things that were already on my radar (NDA or not) - specifically Direct Access, Branch Cache and IPv6. I think any Enterprise that is running AD and has a large mobile workforce will adopt Direct Access just to make remote support of that mobile workforce easier, there is literally nothing the end user has to do at all (well, you have to turn the computer on and have some sort of Internet connection) to make it work and the initial scaling numbers I have heard put it on par with a typical traditional VPN deployment. Just as many Enterprises have adopted rpc over http/s for Outlook to Exchange the next natural step is to adopt a paradigm that allows ALL corporate applications the same flexibility and access that Outlook and Exchange currently have today - that solution is Direct Access.
Microsoft is pushing more advanced services into both Windows Server 2008R2 and Windows 7 - Branch Cache is one of these services and one that makes a lot of sense for folks to use (big and small IT shops will win with this one - and it is free to turn it on - how cool is that). It does not replace WAN accelerations devices (though with the changes in Windows Vista / Windows 7 / Server 2008 networking you could argue you might not need the acceleration part) but specifically targets the caching of file content. Given the cost point and relative easy of deployment I think it will have a good adoption rate.
Finally, IPv6 - there are several solutions in both Windows 7 and Windows Server 2008R2 that just won't work without IPv6. There is no getting around it and you need to start learning it - period. In Windows 7 there is HomeGroup and for Windows Server 2008R2 if you want Direct Access you will need to get up to speed on IPv6. There are more subtle IPv6 items but those two alone should make folks stand up and notice.
- Ed
I am now very happy I changed my mind and I attended. It seems that my new category of Enterprise Security felt that it was important to add networking sessions back to the mix.
A ton of folks from the MS Networking Team showed up! From Sandeep Singhal, Sean Siler, Dave Thaler, Ravi Rao, Tyler Barton, Devrim Asli Iyigun, Mahesh Prakriya, to Joseph Davies - thanks to you all for taking the time and effort to listen to my feedback and opinion about networking and what Microsoft is doing right and wrong.
So, without violating my NDA what was I most excited about from the event? Honestly, it is things that were already on my radar (NDA or not) - specifically Direct Access, Branch Cache and IPv6. I think any Enterprise that is running AD and has a large mobile workforce will adopt Direct Access just to make remote support of that mobile workforce easier, there is literally nothing the end user has to do at all (well, you have to turn the computer on and have some sort of Internet connection) to make it work and the initial scaling numbers I have heard put it on par with a typical traditional VPN deployment. Just as many Enterprises have adopted rpc over http/s for Outlook to Exchange the next natural step is to adopt a paradigm that allows ALL corporate applications the same flexibility and access that Outlook and Exchange currently have today - that solution is Direct Access.
Microsoft is pushing more advanced services into both Windows Server 2008R2 and Windows 7 - Branch Cache is one of these services and one that makes a lot of sense for folks to use (big and small IT shops will win with this one - and it is free to turn it on - how cool is that). It does not replace WAN accelerations devices (though with the changes in Windows Vista / Windows 7 / Server 2008 networking you could argue you might not need the acceleration part) but specifically targets the caching of file content. Given the cost point and relative easy of deployment I think it will have a good adoption rate.
Finally, IPv6 - there are several solutions in both Windows 7 and Windows Server 2008R2 that just won't work without IPv6. There is no getting around it and you need to start learning it - period. In Windows 7 there is HomeGroup and for Windows Server 2008R2 if you want Direct Access you will need to get up to speed on IPv6. There are more subtle IPv6 items but those two alone should make folks stand up and notice.
- Ed
Labels: Branch Cache, Direct Access, IPv6, Microsoft DirectAccess, Microsoft MVP, Microsoft Windows 7
Sunday, April 27, 2008
IPv6 - folks seem to be paying more attention?
Well, one of my observations for the Microsoft MVP Summit was that the network team at Microsoft is still very interested in hearing about what is happening with IPv6 and if anyone has done anything with IPv6. I am not sure that Microsoft has a good road map of what needs to happen to make IPv6 a reality in North America but they are paying attention.
Microsoft has several reasons for getting IPv6 out to the consumer space as quickly as possible. IPv6 will allow Microsoft devices to do peer to peer easily and allow them to get back to the model of all hosts being available and accessible which is a desirable thing when you build an OS platform for PC's.
In addition to all this, there appears to be in the works some cool applications that will be IPv6 only that will leverage that peer to peer openness that IPv6 allows. I think the next generation of Groove would be a great starting point myself.
With Server 2008 having the same network stack as Vista and both being IPv6/IPv4 I think there is an opportunity for IPv6 services to leapfrog some of the IPv4 technologies and potentially allow IPv6 to grow more quickly then originally anticipated. Only time will tell.
- Ed
Microsoft has several reasons for getting IPv6 out to the consumer space as quickly as possible. IPv6 will allow Microsoft devices to do peer to peer easily and allow them to get back to the model of all hosts being available and accessible which is a desirable thing when you build an OS platform for PC's.
In addition to all this, there appears to be in the works some cool applications that will be IPv6 only that will leverage that peer to peer openness that IPv6 allows. I think the next generation of Groove would be a great starting point myself.
With Server 2008 having the same network stack as Vista and both being IPv6/IPv4 I think there is an opportunity for IPv6 services to leapfrog some of the IPv4 technologies and potentially allow IPv6 to grow more quickly then originally anticipated. Only time will tell.
- Ed
Labels: IPv6
Unless otherwise expressly stated, all original material of whatever nature created by Ed Horley and included in this weblog and any related pages, including the weblog's archives, is licensed under a Creative Commons License.
