Hi. I'm running WS2008, WS2003 and Win2000 Server on a public network with no routers in my area of control. Internet access is through a multilayer switch set up as a port blocking firewall.
I set up the IPv6 Tunnel Endpoint on my WS2008 machine, set an "Allow" rule for Protocol 41 on the switch and I am now able to ping the local and remote tunnel endpoints, as well as IPv6 sites on the Internet.
However, when I try to set an IPv6 address from the Routed /64 into my NIC on the WS2008 machine, I get no access to/from that IPv6 address. I tried setting the tunnel endpoint as the Gateway, but I get an error message because the gateway (tunnel endpoint) and the NIC address are on different subnets.
My tunnel endpoint is 2001:470:1f04:a85::2
My Routed /64 is 2001:470:1f05:a85::/64
I'm trying to use:
2001:470:1f05:a85::6 on the WS2008 machine
2001:470:1f05:a85::7 on the Win2000 Server machine
2001:470:1f05:a85::9 on the WS2003 machine
2001:470:1f05:a85::10 on the WS2003 machine
But I don't know how to add/set a route between the two subnets to make this work. Adding a router is not an option. I'm sure there is probably some easy way to do this by setting static routes in some routing tables, but the Netsh documentation doesn't amplify much on what the commands really mean in practice. Can anybody steer me in the right direction?
Thanks.
Dave
On the WS2008 machine you need to have a default route for IPv6 pointing through the tunnel interface, so:
netsh int ipv6 add route ::/0 <ifindex or name of tunnel inteface> 2001:470:1f04:a85::1
(but you've probably already done that if you can ping stuff on the IPv6 internet unless it's using Teredo).
Then on all other machines you'd set the default route to the WS2008 machine like so:
netsh int ipv6 add route ::/0 <ifindex or name of LAN interface> 2001:470:1f05:a85::6
This will cause the other machines to send IPv6 traffic for the internet to the WS2008 box which will route it through the tunnel.
As for setting up IPv6 forwarding and firewall rules on the 2008 box to allow it to be an IPv6 router, that's something I haven't done. :P
jimb,
Thanks, but the tunnel route was already set up correctly and that works OK.
The Problem is that the Routed /64 addresses can't reach the tunnel. The Routed /64 addresses are on a different subnet than the tunnel endpoint and I need a way to route from the Routed /64 addresses to the tunnel (without adding a hardware router!).
BTW, I'm not running Windows Firewall, so that's not an issue.
Anybody else?!
Quote from: dawkco on April 03, 2010, 06:31:27 PM
jimb,
Thanks, but the tunnel route was already set up correctly and that works OK.
The Problem is that the Routed /64 addresses can't reach the tunnel. The Routed /64 addresses are on a different subnet than the tunnel endpoint and I need a way to route from the Routed /64 addresses to the tunnel (without adding a hardware router!).
BTW, I'm not running Windows Firewall, so that's not an issue.
Anybody else?!
That WILL route the routed /64 to and through the tunnel.
Both the WS2008 box, and all the boxes on the LAN have connected routes to 2001:470:1f05:a85::/64 by virtue of the fact that they have addresses from that network configured on their LAN interfaces. So they can talk to each other on the LAN.
The WS2008 knows how to get to the IPv6 internet by virtue of the default route whose next hop is set to the HE tunnel server on the other side of the 6in4 tunnel.
The hosts on the LAN know how to get to the IPv6 internet by virtue of the default route whose next hop is the WS2008 box. The WS2008 box needs to be set up as a router. To do that, it needs to have whatever it might need done to it to tell it to forward IPv6 (e.g. act as a router). Not sure how to do THAT. It also needs the firewall set up to allow the traffic, but since you have that turned off (inadvisable since it will make your hosts wide open to the internet) that probably doesn't matter (even though you spoke of the Windows firewall allow rule in your last message).
Try this: ping the WS2008 box's LAN interface from the other hosts. Can you reach them? Now try to ping the WS2008's tunnel interface address. Can you reach that? Now try to ping the other side of the tunnel from one of the LAN boxes. If you can reach that you know the WS2008 box is routing IPv6 traffic.
If not, check logs and such, and look into whatever you need to do to tell windows to be a router, if anything is required (the equivalent net.ipv4.ip_forward = 1 on linux).
The route commands I gave you will take care of the routing side of things though. Any firewall or ip forwarding policy issues you'll have to figure out.
-Jim
EDIT: You also may want to make sure the ipv6 privacy stuff is turned off on at least the WS2008 router machine, since you probably don't want it changing IPv6 addresses automatically. (
netsh int ipv6 set privacy disabled)
Quote from: jimb on April 03, 2010, 07:23:20 PM
That WILL route the routed /64 to and through the tunnel.
... The WS2008 box needs to be set up as a router. To do that, it needs to have whatever it might need done to it to tell it to forward IPv6 (e.g. act as a router). Not sure how to do THAT. It also needs the firewall set up to allow the traffic, but since you have that turned off (inadvisable since it will make your hosts wide open to the internet) that probably doesn't matter (even though you spoke of the Windows firewall allow rule in your last message).
...
If not, check logs and such, and look into whatever you need to do to tell windows to be a router, if anything is required (the equivalent net.ipv4.ip_forward = 1 on linux).
The route commands I gave you will take care of the routing side of things though. ...
-Jim
EDIT: You also may want to make sure the ipv6 privacy stuff is turned off on at least the WS2008 router machine, since you probably don't want it changing IPv6 addresses automatically. (netsh int ipv6 set privacy disabled)
Unfortunately, the "add route" command you recommended, which is what was used to build the tunnel in the first place, does NOT cause the Routed /64 addresses to route to and through the tunnel. Example, if I set my NIC address to 2001:470:1f05:a85::6 (which is in the routed /64) and then try to ping either tunnel endpoint from that address, it fails, as follows:
C:\>ping -6 -S 2001:470:1f05:a85::6 2001:470:1f04:a85::1
Pinging 2001:470:1f04:a85::1 from 2001:470:1f05:a85::6 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 2001:470:1f04:a85::1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping -6 -S 2001:470:1f05:a85::6 2001:470:1f04:a85::2
Pinging 2001:470:1f04:a85::2 from 2001:470:1f05:a85::6 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 2001:470:1f04:a85::2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
BTW, I tried this with no gateway address on the NIC, then with the local tunnel endpoint IP as the NIC gateway address, then with the remote tunnel endpoint IP as the NIC gateway address, and then even with the NIC address as the gateway address. None of those worked.
However, as I noted before, the tunnel does work if you access it from the "IP6Tunnel" interface itself. Example:
C:\>ping -6 2001:470:1f04:a85::1
Pinging 2001:470:1f04:a85::1 from 2001:470:1f04:a85::2 with 32 bytes of data:
Reply from 2001:470:1f04:a85::1: time=17ms
Reply from 2001:470:1f04:a85::1: time=103ms
Reply from 2001:470:1f04:a85::1: time=122ms
Reply from 2001:470:1f04:a85::1: time=62ms
Ping statistics for 2001:470:1f04:a85::1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 17ms, Maximum = 122ms, Average = 76ms
The "Allow" rule I set for Protocol 41 was on the multilayer switch hardware, not Windows Firewall--as I said Windows Firewall is turned OFF.
I'm thinking that netsh interface ipv6 set privacy only applies if you're using Autoconfigured addresses, which I'm not. I'll try disabling privacy, but I doubt it has anything to do with it.
Obviously, my original question was and still is--How do I set up the WS2008 NIC to act as a router? Other than that, we seem to keep repeating ourselves here. I appreciate your effort, but could we get back to my original question, please?
There is a flag you need to set in the "netsh int ipv6 int#" properties
I don't have a Server 2008 or vista machine in front of me, so I can't give you the exact syntax. I know there is a flag you need to set though to tell the OS to act as a router.
Googling around for "netsh ipv6 flags" or something should help.
I'm not finding anything that works.
Your non-working pings are probably do to the router functionality thing I mentioned earlier. It's what cholz was talking about too.
Googling around a bit, I think you have to turn on routing and remote access and enable routing.
These technet sections are probably worth looking at:
http://technet.microsoft.com/en-us/library/cc757719%28WS.10%29.aspx (http://technet.microsoft.com/en-us/library/cc757719%28WS.10%29.aspx)
http://technet.microsoft.com/en-us/library/cc781568%28WS.10%29.aspx (http://technet.microsoft.com/en-us/library/cc781568%28WS.10%29.aspx)
http://technet.microsoft.com/en-us/library/cc730711%28WS.10%29.aspx#BKMK_4 (http://technet.microsoft.com/en-us/library/cc730711%28WS.10%29.aspx#BKMK_4)
Is this Server 2008 R2 or just Server 2008?
Back when I was with Sixxs, I tried using a Server 2008 machine to host my tunnel. Long story short, it didn't work, and I'm trying to remember why. It was caused by Server 2008; I can't remember if it was a bug in the Sixxs program or if it was in Server 2008.
If you can wait, tomorrow when I get to work I can poke around in netsh and let you know what I find.
Quote from: jimb on April 04, 2010, 05:34:35 AM
Your non-working pings are probably do to the router functionality thing I mentioned earlier. It's what cholz was talking about too.
Googling around a bit, I think you have to turn on routing and remote access and enable routing.
These technet sections are probably worth looking at:...
Yeah, that was I was thinking too. I was about to install RRAS, but ran out of time last night. I'll try today. It's looks a bit involved because installing IP Routing requires installing RRAS, which requires installing NAP, and so on. I just want the routing with the least impact otherwise (i.e., admin, side-effects, etc.).
I'll post back later...
Quote from: cholzhauer on April 04, 2010, 06:30:20 AM
Is this Server 2008 R2 or just Server 2008?
Back when I was with Sixxs, I tried using a Server 2008 machine to host my tunnel. Long story short, it didn't work, and I'm trying to remember why. It was caused by Server 2008; I can't remember if it was a bug in the Sixxs program or if it was in Server 2008.
If you can wait, tomorrow when I get to work I can poke around in netsh and let you know what I find.
I'm on Server 2008 Standard. The tunnel is fine--it's just getting the Routed/64 to work that's a problem. If I only had one machine, I could just use the tunnel endpoint and be done, but I have two Name Servers and a Web/Mail Server that I want to start hosting via IPv6 also, so I need the Routed /64. And, I'd like to start taking the IPv6 Cert. exams. Adding another hardware router is just impractical in my setup.
BTW, the tunnel was constructed with the following:
netsh interface teredo set state disabled
netsh interface ipv6 add v6v4tunnel IP6Tunnel 65.168.232.6 72.52.104.74
netsh interface ipv6 add address IP6Tunnel 2001:470:1f04:a85::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:1f04:a85::1
I set the NIC address as follows:
netsh interface ipv6 add address interface="Local Area Connection" address=2001:470:1f05:a85::6
netsh interface ipv6 set interface interface="Local Area Connection" forwarding=enabled advertise=enabled nud=enabled routerdiscovery=enabled
Note: I originally, tried routerdiscovery=disabled along with the following route table entries, which didn't work either. Also, I updated the system registry value IPEnableRouter to (DWORD)1 at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
I tried adding the following route table entries, one at a time--I deleted non-working route table entries as I went--none worked:
netsh interface ipv6 add route prefix=::/0 interface="Local Area Connection" nexthop=2001:470:1f04:a85::1 publish=yes
netsh interface ipv6 add route prefix=::/0 interface="Local Area Connection" nexthop=2001:470:1f04:a85::2 publish=yes
netsh interface ipv6 add route prefix=::/0 interface="Local Area Connection" nexthop=2001:470:1f05:a85::6 publish=yes
netsh interface ipv6 add route prefix=2001:470:1f05:a85::/64 interface="Local Area Connection" nexthop=2001:470:1f04:a85::1 publish=yes
netsh interface ipv6 add route prefix=2001:470:1f05:a85::/64 interface="Local Area Connection" nexthop=2001:470:1f04:a85::2 publish=yes
And, I tried using no default gateway entry at all. Since nothing worked, I just disabled IPv6 on the NIC for now. The tunnel still works and I currently have the following IPv6 route table:
Publish Type Met Prefix Idx Gateway/Interface Name
------- -------- --- ------------------------ --- ------------------------
No Manual 256 ::/0 15 2001:470:1f04:a85::1
No Manual 256 ::1/128 1 Loopback Pseudo-Interface 1
No Manual 256 2001:470:1f04:a85::2/128 15 IP6Tunnel
No Manual 256 fe80::/64 15 IP6Tunnel
No Manual 256 fe80::200:5efe:65.168.232.6/128 16 Local Area Connection* 8
No Manual 256 fe80::4571:e519:fffa:2d7f/128 15 IP6Tunnel
No Manual 256 ff00::/8 1 Loopback Pseudo-Interface 1
No Manual 256 ff00::/8 15 IP6Tunnel
My next move is to try installing RRAS. I've had bad experiences with RRAS in the past (on Win2K and WS2003), so I'm not expecting a miracle...wish me luck.
I think the routing service is needed just for Windows to route packets from one interface to another. Perhaps it does this by sending it off to a service. I don't know enough about windows internal architecture to know for sure.
On linux, IP routing is built into the proto stack in the kernel, but needs to be enabled for security reasons by essentially flipping a bit.
I'm not sure why you would have added some of those routes.
The only default routes you need is the default pointing to the other side of the tunnel on the box which the tunnel lives on (your IPv6 router), and then default routes on the other boxes pointing to the tunnel box.
If you are in a VM environment, might be easier to load up linux or BSD or something and make that your IPv6 router. :P
Quote from: jimb on April 04, 2010, 02:23:59 PM
I think the routing service is needed just for Windows to route packets from one interface to another. Perhaps it does this by sending it off to a service. ...
On linux, IP routing is built into the proto stack in the kernel, but needs to be enabled for security reasons by essentially flipping a bit.
I'm not sure why you would have added some of those routes.
The only default routes you need is the default pointing to the other side of the tunnel on the box which the tunnel lives on (your IPv6 router), and then default routes on the other boxes pointing to the tunnel box.
If you are in a VM environment, might be easier to load up linux or BSD or something and make that your IPv6 router. :P
I was just trying things to see if I could get it to work. Now I'll try RRAS. I guess I just leave the WS2008 NIC Default Gateway setting blank...(?)
I'm not running in VM environment now, so that would be a bigger hassle (I think).
Yes. The WS2008 box is your Ipv6 router, and the route to the IPv6 internet is via the tunnel interface, so the only default route you need on that box is via the tunnel interface. There should be no default route pointing through the LAN NIC since the way "out" is via the 6in4 tunnel virtual NIC.
Do me a favor--see if you can successfully ping the following address:
2001:470:1f05:a85::6
Thanks.
Success! Installing RRAS fixed it. I just enabled LAN Routing (only) during the Setup Wizard's "Custom Setup" option, then started the service and the Routed/64 started working. I didn't even have to add any routes or anything else. That was a relief because the RRAS interface list and routing table didn't show the tunnel interface anywhere and wouldn't allow it to be added to the list--it's hidden and inaccessible in RRAS admin! :o|
Please ping me and confirm--thanks:
2001:470:1f05:a85::6
Now I can start configuring the other servers...
Quote from: dawkco on April 04, 2010, 03:11:38 PM
Do me a favor--see if you can successfully ping the following address:
2001:470:1f05:a85::6
Thanks.
I can. So that at least means HE has the route for your /64 pointed through your tunnel. It may also mean that WS2008 is routing packets, but I'm not sure since that NIC is still "inside" your machine. It all depends on the proto stack framework of windows, etc.
I can also ping your tunnel side interface, BTW.
Quote from: jimb on April 04, 2010, 08:51:09 PM
I can. So that at least means HE has the route for your /64 pointed through your tunnel. It may also mean that WS2008 is routing packets, but I'm not sure since that NIC is still "inside" your machine. It all depends on the proto stack framework of windows, etc.
I can also ping your tunnel side interface, BTW.
Thank you.
The WS2008 machine is definitely routing the packets, and now the Win 2000 Server machine is also as I just finished setting that one up (including RRAS). I also had to set up a v6v4 tunnel between the WS2008 and Win2000 Server machines (my network is IPv4! ::)) and now I'm able to ping through with IPv6.
You should be able to ping my Win 2000 Server now, if you would please:
2001:470:1f05:a85::7
Now, though, there's a new wrinkle in this routing scenario. When I go to the following web site and use their IPv4/IPv6 connection Checker, they detect my IPv4 NIC address correctly, but the IPv6 address detected is my tunnel endpoint [2001:470:1f04:a85::2] instead of my NIC address [2001:470:1f05:a85::6]:
http://www.ipv6forum.com/
I'm wondering if I should enable some more things on the tunnel. For example, forwarding is already enabled, but maybe I should also set advertise=enabled nud=enabled routerdiscovery=enabled. Or, is this due to something else...? It seems to me that if I get this configured correctly, the NIC address should be the detected source address of the connection.
What do you think?
RouterDiscovery is used for getting an IP address via Router Advertisement.
Unless you're doling out IP addresses via DHCP, this should be on.
Quote from: cholzhauer on April 05, 2010, 05:15:06 AM
RouterDiscovery is used for getting an IP address via Router Advertisement.
Unless you're doling out IP addresses via DHCP, this should be on.
Well, I'm not using DHCP, but the NIC public/global addresses are manually configured and static. However, I suppose RouterDiscovery should be enabled for the auto-configured link-local and site-local addresses, correct?
BTW, can you please ping 2001:470:1f05:a85::7 from your location? Let me know if successful. Thanks.
QuoteBTW, can you please ping 2001:470:1f05:a85::7 from your location?
Was able to this morning.
QuoteHowever, I suppose RouterDiscovery should be enabled for the auto-configured link-local and site-local addresses, correct?
AFAIK this will happen regardless if the RouterDiscovery flag is set to true or false.
Why did you have to set up a tunnel from the W2000 machine?
Are they on completely different LANs? My impression was that the WS2008 box and the other machines were on the same LAN and you were using the routed /64 on that LAN. In that case they should have all been able to speak to each other directly over ethernet using IPv6.
If they're separated by an IPv4 only router, then you'd either need to tunnel, or use something like ISATAP to route IPv6 over an IPv4 LAN infrastructure (ISATAP basically works by using IPv4 as a link layer protocol for IPv6). You'd also need to request a routed /48 from HE, since the routed /64 is only good for one LAN and you'd need more subnets.
Quote from: cholzhauer on April 05, 2010, 11:44:08 AM
QuoteBTW, can you please ping 2001:470:1f05:a85::7 from your location?
Was able to this morning.
QuoteHowever, I suppose RouterDiscovery should be enabled for the auto-configured link-local and site-local addresses, correct?
AFAIK this will happen regardless if the RouterDiscovery flag is set to true or false.
OK. Thank you.
Quote from: jimb on April 05, 2010, 05:03:15 PM
Why did you have to set up a tunnel from the W2000 machine?
Are they on completely different LANs? My impression was that the WS2008 box and the other machines were on the same LAN and you were using the routed /64 on that LAN. In that case they should have all been able to speak to each other directly over ethernet using IPv6.
If they're separated by an IPv4 only router, then you'd either need to tunnel, or use something like ISATAP to route IPv6 over an IPv4 LAN infrastructure (ISATAP basically works by using IPv4 as a link layer protocol for IPv6). You'd also need to request a routed /48 from HE, since the routed /64 is only good for one LAN and you'd need more subnets.
I guess my ignorance is showing--I thought that my LAN was not IPv6 capable. The 5 machines are connected together via a D-Link Gbit Switch. If Ethernet is IPv6 compatible, then I guess the D-Link Gbit Switch should be too, so I can just remove the tunnel between the WS2008 and Win2000 Server machines. That would be good--less bottleneck. I'll try it. Thanks for the heads up.
Aside, v6v4 tunnelling is pretty easy. Don't know much about ISATAP (yet).
Quote from: dawkco on April 06, 2010, 01:26:04 AM
Quote from: jimb on April 05, 2010, 05:03:15 PM
Why did you have to set up a tunnel from the W2000 machine?
Are they on completely different LANs? My impression was that the WS2008 box and the other machines were on the same LAN and you were using the routed /64 on that LAN. In that case they should have all been able to speak to each other directly over ethernet using IPv6.
If they're separated by an IPv4 only router, then you'd either need to tunnel, or use something like ISATAP to route IPv6 over an IPv4 LAN infrastructure (ISATAP basically works by using IPv4 as a link layer protocol for IPv6). You'd also need to request a routed /48 from HE, since the routed /64 is only good for one LAN and you'd need more subnets.
I guess my ignorance is showing--I thought that my LAN was not IPv6 capable. The 5 machines are connected together via a D-Link Gbit Switch. If Ethernet is IPv6 compatible, then I guess the D-Link Gbit Switch should be too, so I can just remove the tunnel between the WS2008 and Win2000 Server machines. That would be good--less bottleneck. I'll try it. Thanks for the heads up.
Aside, v6v4 tunnelling is pretty easy. Don't know much about ISATAP (yet).
Yep. IPv6 is just another layer 3 protocol. Just like IPv4. It will run on the same transports as IPv4. Well, except for ones specifically designed for IPv4. :)
But it'll run along side IPv4 on Ethernet with no problems. The only difference in the enet packet is the ethertype, which is set to 0x86DD instead of 0x0800. IPv6 also doesn't have broadcast. Only multicast. And it doesn't use ARP, but a similar mechanism based on multicast called Neighbor Discovery.
ISATAP is only needed in a situation where you have multiple LANs connected by an IPv4 only router(s). The preferable way would be to simply enable IPv6 routing on your router. But if you can't do that, ISATAP is one way you can get around it.
In your case you only have a single LAN, so you don't have to worry about it.
Well, after all that, and getting the Routed /64 to work properly, I'm finding that the IPv6 support in Windows Server 2003 and IIS 6 is unacceptable (and Windows 2000 Server worse yet). Windows Server 2008 IPv6 functionality is quite good, with the exception that they did not include an updated SMTP Service with IIS 7. Instead, they included the old version SMTP Service from IIS 6 which has no support for IPv6 at all.
For anyone wondering about the details, the following document spells it out:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/1ecff3af-36c2-41b5-957a-8bcc6fac8abc.mspx?mfr=true
I still have one issue left with this Routed /64. For some reason, when I access a remote IPv6 site from the machine where the tunnel endpoint is installed, the remote site detects my local tunnel endpoint address as the Source address of the connection instead of my NIC address. However, if I connect from one of the other machines on my network, the NIC address of that machine is detected as the Source address of the connection as it should be. The packets are being routed.
This is a problem for the machine with the tunnel endpoint--the machine's NIC has a public IP in the Routed /64 that is registered in DNS and needs to be recognized as such. I didn't configure a DNS host record for the tunnel endpoint, and I don't think I can or should because it's not delegated to my DNS zone.
I've verified this on more than one remote site. One example is: http://www.apnic.net/, where they display the following--"Your IP: 2001:470:1f04:a85::2". That's my local tunnel endpoint. My NIC address in the Routed /64 is: 2001:470:1f05:a85::6.
???
Any ideas?
Quote
I didn't configure a DNS host record for the tunnel endpoint, and I don't think I can or should because it's not delegated to my DNS zone.
Correct.
Quote
For some reason, when I access a remote IPv6 site from the machine where the tunnel endpoint is installed, the remote site detects my local tunnel endpoint address as the Source address of the connection instead of my NIC address
I haven't heard of that happening before; the machine my tunnel is hosted on will display the assigned address when I ping something or even do a traceroute, so I assume it would browse the web the same way. It almost sounds like something is incorrect in your netsh setup. While you were poking around, did you find any option to tell Windows to prefer one address over the other?
Actually that's pretty normal, at least on Linux. I would think windows would work similarly
Typically if you're connecting from a system with more than one IPv6 address, it will use the IPv6 address of the NIC through which the route to the destination is pointing (that's true for IPv4 too). In this case, since the tunnel is the route to the internet on that machine, any internet site accessed from that machine will use the tunnel IPv6 address.
The other hosts use their LAN NIC IPv6 address since it's the only one they have, and the routes for everything IPv6 is through that NIC.
You may be able to play around with prefixpolicy to have it use the NIC IPv6 as the preferred source (netsh int ipv6 set prefixpolicy). If you google around you'll see some examples. (EDIT2: actually, I'm not sure if this will work in the case of multiple interfaces. I think the routed interface address always takes precedence. I think this is more for picking a source when there's multiple IPv6s on the same interface. So prefixpolicy may not work for this at all. I'm not absolutely sure though).
Another way to do this is to specify the source address to use via a cmd line option or configuration file option if the particular piece of software has such an option to do that.
EDIT: Here's a CG article on it: http://technet.microsoft.com/en-us/library/bb877985.aspx (http://technet.microsoft.com/en-us/library/bb877985.aspx)
Quote from: cholzhauer on April 08, 2010, 05:07:55 AM
Quote
For some reason, when I access a remote IPv6 site from the machine where the tunnel endpoint is installed, the remote site detects my local tunnel endpoint address as the Source address of the connection instead of my NIC address
I haven't heard of that happening before; the machine my tunnel is hosted on will display the assigned address when I ping something or even do a traceroute, so I assume it would browse the web the same way. It almost sounds like something is incorrect in your netsh setup. While you were poking around, did you find any option to tell Windows to prefer one address over the other?
I'm thinking you are probably not using your host as a router for other machines on your LAN the way that I am and that's the difference. While searching, I found another post on this forum by a user having the same problem. Although he was not routing for other machines, he was trying to use the Routed /64 on the same machine where the tunnel was installed.
The following command is supposed to provide Source address selection capability, but it doesn't seem to work in my case:
netsh int ipv6 set prefixpolicy [prefix] [preference] [label]
Quote from: jimb on April 08, 2010, 10:53:02 AM
...
Typically ... the IPv6 address of the NIC through which the route to the destination is pointing ... In this case, since the tunnel is the route to the internet on that machine, any internet site accessed from that machine will use the tunnel IPv6 address.
...
You may be able to play around with prefixpolicy to have it use the NIC IPv6 as the preferred source (netsh int ipv6 set prefixpolicy). If you google around you'll see some examples. (EDIT2: actually, I'm not sure if this will work in the case of multiple interfaces. I think the routed interface address always takes precedence. I think this is more for picking a source when there's multiple IPv6s on the same interface. So prefixpolicy may not work for this at all. I'm not absolutely sure though).
Another way to do this is to specify the source address to use via a cmd line option or configuration file option if the particular piece of software has such an option to do that.
EDIT: Here's a CG article on it: http://technet.microsoft.com/en-us/library/bb877985.aspx (http://technet.microsoft.com/en-us/library/bb877985.aspx)
I tried:
netsh int ipv6 set prefixpolicy <prefix> <preference> <label>, and it didn't work.
I read the technet article and RFC 3484
Default Address Selection for Internet Protocol version 6 (IPv6). If the Windows implementation provided the Administrative Override option allowed in the RFC, it would work, but the Windows implementation differs slightly from the RFC (as usual). In the Windows implementation, the preferred Source address for a routing interface is the next hop address from the origin and it wouldn't allow me to override that. It didn't complain if I tried, but it just had no effect.
This is weird. The tunnel interface is like a virtual interface that's spliced into the IPv4 side of the physical NIC, but the IPv6 side of the physical NIC is a separate routing interface where the hidden and unstated next hop address is the local side of the tunnel. I don't see how I can use this. I need to be able to use the Routed /64 address that's registered in DNS as the Source address.
I don't know of any command-line or configuration file options for Source address selection (other than prefixpolicy). Do you?
Quote from: dawkco on April 09, 2010, 12:18:10 AM
Quote from: cholzhauer on April 08, 2010, 05:07:55 AM
Quote
For some reason, when I access a remote IPv6 site from the machine where the tunnel endpoint is installed, the remote site detects my local tunnel endpoint address as the Source address of the connection instead of my NIC address
I haven't heard of that happening before; the machine my tunnel is hosted on will display the assigned address when I ping something or even do a traceroute, so I assume it would browse the web the same way. It almost sounds like something is incorrect in your netsh setup. While you were poking around, did you find any option to tell Windows to prefer one address over the other?
I'm thinking you are probably not using your host as a router for other machines on your LAN the way that I am and that's the difference. While searching, I found another post on this forum by a user having the same problem. Although he was not routing for other machines, he was trying to use the Routed /64 on the same machine where the tunnel was installed.
The following command is supposed to provide Source address selection capability, but it doesn't seem to work in my case:
netsh int ipv6 set prefixpolicy [prefix] [preference] [label]
Yeah if you read RFC-3484 (http://tools.ietf.org/html/rfc3484), you'll see that the "label(S)==label(D)" step is way down on the list, and the "prefer outbound interface IP" is ahead of it, so it never gets to that step in the case of multi-interface machines. I tried to note that in my last message.
The prefixpolicy RFC-3484 source address selection (http://tools.ietf.org/html/rfc3484#section-5) stuff only seems to apply when you have multiple IPv6 addresses on the
same interface. When everything else in the list is a tie, then you can preference one source address over another using prefixpolicy.
The only surefire way to do it is to actually
specify which source address to use. A lot of software supports this, but not all. I'm not sure if theres any way to make IE or FF use a particular source IP. But I'd think most system services could be manually bound to use a particular address for outbound initiated connections.
Anyway, on my IPv6 router, it behaves the same way. If I want it to use my LAN interface address, I have to tell the particular piece of software to use the particular interface or address. This always overrides prefixpolicy, etc.
Quote from: jimb on April 09, 2010, 01:16:08 AM
Yeah if you read RFC-3484 (http://tools.ietf.org/html/rfc3484), you'll see that the "label(S)==label(D)" step is way down on the list, and the "prefer outbound interface IP" is ahead of it, so it never gets to that step in the case of multi-interface machines. I tried to note that in my last message.
The prefixpolicy RFC-3484 source address selection (http://tools.ietf.org/html/rfc3484#section-5) stuff only seems to apply when you have multiple IPv6 addresses on the same interface. When everything else in the list is a tie, then you can preference one source address over another using prefixpolicy.
The only surefire way to do it is to actually specify which source address to use. A lot of software supports this, but not all. I'm not sure if theres any way to make IE or FF use a particular source IP. But I'd think most system services could be manually bound to use a particular address for outbound initiated connections.
Anyway, on my IPv6 router, it behaves the same way. If I want it to use my LAN interface address, I have to tell the particular piece of software to use the particular interface or address. This always overrides prefixpolicy, etc.
Actually, I only have one NIC interface (enabled) on this machine, but if you mean multiple interfaces in the sense of virtual and pseudo interfaces along with the NIC, then I see your point. And, oh yeah (of course), I will be specifying which address(es) to bind listening sockets to in my services, so source address selection shouldn't be an issue for my listening services.
My point about Windows implementation of RFC 3484 was that, regardless of the ordering of the steps in the source address selection algorithm, the administrative override should take precedence. Anyway...
HOWEVER--I THINK I HAVE IT FIXED! Or at least working the way I want it to. Here's what I ended up with (and don't tell me I'm wrong cuz I'm not listening ;D ).
1. I added a IPv6 Default Gateway Route from the NIC to the remote tunnel endpoint IPv6 address.
2. I deleted the local tunnel endpoint IPv6 address from the tunnel interface.
Now, I can ping out, the outbound ping source address defaults to the NIC Routed /64 address, and remote sites detect my (source) address as the Routed /64 address. Here's what the route table looks like:
netsh interface ipv6 show route
Publish Type Met Prefix Idx Gateway/Interface Name
------- -------- --- ------------------------ --- ------------------------
Yes Manual 1 ::/0 10 2001:470:1f04:a85::1
Yes Manual 1 ::/0 15 2001:470:1f04:a85::1
No Manual 0 ::1/128 1 Loopback Pseudo-Interface 1
No Manual 0 2001:470:1f04:a85::/64 15 IP6Tunnel
No Manual 0 2001:470:1f05:a85::/64 10 Local Area Connection
No Manual 0 2001:470:1f05:a85::6/128 10 Local Area Connection
No Manual 0 fe80::/64 10 Local Area Connection
No Manual 0 fe80::/64 15 IP6Tunnel
No Manual 0 fe80::5d1:3ef0:29cf:740d/128 10 Local Area Connection
No Manual 0 fe80::4571:e519:fffa:2d7f/128 15 IP6Tunnel
No Manual 0 ff00::/8 1 Loopback Pseudo-Interface 1
No Manual 0 ff00::/8 15 IP6Tunnel
No Manual 0 ff00::/8 10 Local Area Connection
And, here's the prefix policy table. Note that I did update it, but it never made a difference until I made the changes in the route table and interface addresses.
netsh interface ipv6 show prefixpolicies
Querying active state...
Precedence Label Prefix
---------- ----- -----------
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
20 3 ::/96
10 4 ::ffff:0:0/96
40 1 2001::/16
I hope that's the end of this issue as I need to start searching for services software that supports IPv6 better than the stuff that comes with Win2K and Windows Server 2003. Oh, and an SMTP server for Windows Server 2008.
I'll reboot and make sure this is all still working afterward. If so, I'll post a final confirmation that this is solved.
Thanks for your help and input.
I was joking when I said "don't tell me I'm wrong."
I was wrong--that last setup didn't work reliably. It seemed fine for a while, but some continuous testing revealed that about every 5 minutes or so, the Routed /64 address assigned to the NIC became unreachable for a minute or two, then the cycle would repeat. I couldn't even ping the address from itself during these episodes.
Back to the drawing board...
Quote from: cholzhauer on April 08, 2010, 05:07:55 AM
Quotefrom dawkco:
For some reason, when I access a remote IPv6 site from the machine where the tunnel endpoint is installed, the remote site detects my local tunnel endpoint address as the Source address of the connection instead of my NIC address
... It almost sounds like something is incorrect in your netsh setup...
I think you're right. I decided to use:
netsh interface ipv6 resetand start over.
I'm wondering--is the following recommended command really necessary?
netsh interface teredo set state disabled
QuoteI'm wondering--is the following recommended command really necessary? netsh interface teredo set state disabled
Necessary? No. Recommended? Definitely
Quote from: cholzhauer on April 09, 2010, 01:20:43 PM
QuoteI'm wondering--is the following recommended command really necessary? netsh interface teredo set state disabled
Necessary? No. Recommended? Definitely
Ok, I see it now--Teredo is for tunneling through NAT devices, which doesn't apply here. No sense cluttering the setup with potential conflicts when it's not needed anyway. Thanks.
Ok, after a reset and removal of the tunnel and routed /64, followed by a reinstall and setup of same, everything seems to be working. However, I still see the wrong Source address when I connect to a remote site--it's the local tunnel endpoint address instead of the routed /64 address assigned to the NIC.
I really need to find a work-around for this...
I've got a work-around that seems to be working and is stable, but it has a (hopefully) trivial drawback. Outbound and inbound pings work; outbound tracert's work fine, but inbound tracert's can't resolve the one hop at the tunnel, although inbound tracert's do continue through successfully to my routed /64 NIC.
The settings are similar to my last failed attempt:
1. Added a Default Gateway route from the routed /64 NIC to the tunnel remote endpoint IPv6 address.
2. Deleted the tunnel local endpoint IPv6 address from the tunnel interface.
The differences in my setup this time are noted below:
- The Default gateway routes for the tunnel and the routed /64 NIC are not Published.
- The routed /64 NIC has Advertising disabled.
- The tunnel interface has Router Discovery disabled.
- The Prefix Policy table is reset to the default values.
(I had tried the opposite route and interface settings, and had added a Source address selection rule to the Prefix Policy table, during my prior attempt.)
Other settings used that are the same this time:
- All interfaces have Forwarding enabled.
The routed /64 NIC has the following:
- Neighbor Discovery enabled
- Neighbor Unreachability Detection enabled
- Router Discovery enabled
- All other interface settings are the default values.
Here's the current route table:
Publish Type Met Prefix Idx Gateway/Interface Name
------- -------- --- ------------------------ --- ------------------------
No Manual 256 ::/0 16 2001:470:1f04:a85::1
No Manual 256 ::/0 10 2001:470:1f04:a85::1
No Manual 256 ::1/128 1 Loopback Pseudo-Interface 1
No Manual 256 2001:470:1f05:a85::/64 10 Local Area Connection
No Manual 256 2001:470:1f05:a85::6/128 10 Local Area Connection
No Manual 256 fe80::/64 16 IP6Tunnel
No Manual 256 fe80::/64 10 Local Area Connection
No Manual 256 fe80::200:5efe:65.168.232.6/128 15 Local Area Connection* 8
No Manual 256 fe80::5d1:3ef0:29cf:740d/128 10 Local Area Connection
No Manual 256 fe80::bd65:2797:80a6:39af/128 16 IP6Tunnel
No Manual 256 ff00::/8 1 Loopback Pseudo-Interface 1
No Manual 256 ff00::/8 16 IP6Tunnel
No Manual 256 ff00::/8 10 Local Area Connection
I noted that a couple of the interface Index values changed following a reboot after the ipv6 reset.
Here's the current Prefix Policy table:
Precedence Label Prefix
---------- ----- --------------
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
20 3 ::/96
10 4 ::ffff:0:0/96
5 5 2001::/32
The prefix policy entries are just the default values.
I don't think the problem of tracert not being able to resolve the tunnel hop of an inbound trace is a big issue. Am I wrong?
When I say multiple NICs I also include virtual NICs, since from a networking standpoint they're just as valid as real hardware NICs.
For services, the listen IPv6 really isn't important, since services will listen on all IPv6s by default. If you for whatever reason don't want a service to accept connections on the Tunnel IPv6, it'd be easier to filter this with firewall rules. The more important factor is which IPv6 that the service uses to originate connections. For services which are "listen only", you don't have to worry. For services such as SMTP which initiate connections, you need to specify the source IPv6 to use.
From on my understanding of RFC3484 The prefixpolicy stuff you listed wouldn't have affected source address selection as the "precedence" part is only used for destination address selection when choosing between a bunch of IPv6s and IPv4s returned by DNS. The only factor which influences source address selection is the "label", which only applies in a tiebreaker situation once many other "tests" are passed through resulting in a tie (they're listed in the RFC in order). It will look up the label entries in the prefixpolicy table for the source addresses and the chosen destination address, and will prefer a source address which has the same label as the destination address. So for example, the destination address matches an entry in a prefixpolicy table which returns a label of 1, if you have an entry in there for your chosen source address which also matches a label of 1, this will cause it to use that matching source address.
As for the routing shenanigans, I can see how that would work, but could also see how it would fail as soon as the HE side sent a Neighbor Discovery for your side of the tunnel interface. And of course as you discovered, it will break traceroute. It also breaks any ability to connect to the machine via the outward facing tunnel interface, which is a good thing to have in many cases. IMHO, doing things like this falls into the area of "unnatural acts" which I tend to avoid because it almost always winds up causing problems in the end.
Personally, I'd just figure out a way to have software which initiates connections to use a particular IPv6 address to do so. And like I said, the listening side doesn't matter, as it will answer to any IPv6 it has. And for non-server software such as web browsers, I'm not sure why it matters which IPv6 it uses.
Quote from: jimb on April 09, 2010, 08:06:33 PM
...
For services, the listen IPv6 really isn't important, since services will listen on all IPv6s by default. ... The more important factor is which IPv6 that the service uses to originate connections. For services which are "listen only", you don't have to worry. For services such as SMTP which initiate connections, you need to specify the source IPv6 to use.
...
As for the routing shenanigans, I can see how that would work, but could also see how it would fail ... It also breaks any ability to connect to the machine via the outward facing tunnel interface, which is a good thing to have in many cases...
Personally, I'd just figure out a way to have software which initiates connections to use a particular IPv6 address to do so...
Unfortunately, just binding a service's outbound communications socket to the routed /64 address would not solve this problem. On the remote end, the connection would still appear to be coming from the tunnel local endpoint IPv6 address. When a web browser connects to a remote site, it does just that--binds a connection socket to the routed /64 address, but as the outbound packets are routed through the tunnel gateway, the IPv6 Prefix Policy source address selection algorithm causes the packets to inherit the tunnel local endpoint Ipv6 address (because it's the outbound interface). Since the source address selection administrative override mechanism either doesn't apply or Windows IPv6 doesn't obey it, it doesn't help in this case. As you mentioned, this is a critical issue for a service such as an SMTP Server.
Believe me, I would prefer not to use any work-around, but I don't seem to have a choice right now. Luckily, everything is working well--better than ever in fact.
However, it appears that I will have to enable the Windows Firewall now. The 6in4 tunnel has created a loop-hole in my layer-4 port blocking hardware firewall. (I had read that was possible, and have confirmed it so using the HE IPv6 Port Scan.)
I must say that I am both impressed with, and grateful to HE for all of this IPv6 support. When the IPv4 address space runs out, we'll be ready! Thank you HE!
The address selection algorithm doesn't override what the software binds as a source address. This is true in both Windows and Unixes. The address selection thing is only for when a source IP isn't specified in the socket call (e.g. it's left as 0.0.0.0 or :: ). Doing so is basically saying "Please fill in the appropriate IP Mr. OS." If the source IP is already filled in by the application, it will use that source IP (IPv4 or IPv6). In fact it will use any IP you fill in there, even one which doesn't live on the machine (this is how certain malware does things like DOS attacks and DNS cache poisoning, etc).
Thus, services like SMTP and DNS servers can be configured to connect outbound using a particular IPv4 or IPv6 address. It's also how you can specify a source IP address in many utilities like ping, wget, ssh, etc, etc,etc. While it's true that the packets are routed out of the tunnel interface, the source address isn't changed.
Yes you definitely need a firewall. I think I mentioned that in a previous post. Setting up an IPv6 tunnel essentially opens all machines with an IPv6 address to the internet.
Quote from: jimb on April 10, 2010, 12:51:16 AM
While it's true that the packets are routed out of the tunnel interface, the source address isn't changed.
Sounds good, but it's not what I was seeing.
Quote from: dawkco on April 10, 2010, 02:56:13 AM
Quote from: jimb on April 10, 2010, 12:51:16 AM
While it's true that the packets are routed out of the tunnel interface, the source address isn't changed.
Sounds good, but it's not what I was seeing.
Well, I can prove it. Here's cygwin wget on my XP box. Yes it's cygwin, but ultimately it results in a call to the windows networking API and drivers. I added an extra IPv6 address to my interface to do this test:
Plain wget without any source address arguments:
wget -6 -O - http://ip6.me |egrep -i 2001
Resolving ip6.me... 2001:4810::110
Connecting to ip6.me|2001:4810::110|:80... connected.
<tr><td align=center colspan=3 bgcolor="D0D0F0"><font face="Arial, Monospace" size=+3>2001:db8:1234::88</font></td></tr>And here specifying a different IPv6:
wget -6 -O - --bind-address=2001:db8:1234:0:213:ceff:fe9b:2d70 http://ip6.me | egrep -i 2001
Resolving ip6.me... 2001:4810::110
Connecting to ip6.me|2001:4810::110|:80... connected.
<tr><td align=center colspan=3 bgcolor="D0D0F0"><font face="Arial, Monospace" size=+3>2001:db8:1234:0:213:ceff:fe9b:2d70</font></td></tr>As you can see in the HTML output (edited out a lot of junk), it sees the IPv6 as the one I set with the "
--bind-address" option of wget.
The same options works the same way on my Linux box which has my HE tunnel interface and my LAN interface. Normally it'll connect with the outward facing interface IPv6. If I give it my LAN interface IPv6 it uses that and ip6.me reports that as my IPv6, just as in the above test.
Try it yourself.
Quote from: jimb on April 10, 2010, 04:13:43 AM
Quote from: dawkco on April 10, 2010, 02:56:13 AM
Quote from: jimb on April 10, 2010, 12:51:16 AM
While it's true that the packets are routed out of the tunnel interface, the source address isn't changed.
Sounds good, but it's not what I was seeing.
Well, I can prove it...
Try it yourself.
Ah, Ok I see it now--in fact, I was logging into the forum to correct myself. I misinterpreted the meaning of how the Prefix Policy table was implemented.
Still, an important feature of the prefix policy is the administrative override of default policies, which Windows doesn't seem to allow for. Example: assuming that my web browser used an unspecified address for its outbound connection, the OS should have preferred my routed /64 address as the source address when I had the following prefix policy table entries:
Precedence Label Prefix
---------- ----- ----------
...
40 1 ::/0
40 1 2001:470:1f05:a85::/64
... etc.
In other words, for any destination address, select the routed /64 address as the source address. But it didn't work.
So, is there a wget for Windows? I'd like to do this test myself.
Quote from: dawkco on April 10, 2010, 10:47:59 AM
So, is there a wget for Windows? I'd like to do this test myself.
I have ActivePerl installed, maybe there's an implementation of something like wget in there...
Quote from: dawkco on April 10, 2010, 10:47:59 AM
Quote from: jimb on April 10, 2010, 04:13:43 AM
Quote from: dawkco on April 10, 2010, 02:56:13 AM
Quote from: jimb on April 10, 2010, 12:51:16 AM
While it's true that the packets are routed out of the tunnel interface, the source address isn't changed.
Sounds good, but it's not what I was seeing.
Well, I can prove it...
Try it yourself.
Ah, Ok I see it now--in fact, I was logging into the forum to correct myself. I misinterpreted the meaning of how the Prefix Policy table was implemented.
Still, an important feature of the prefix policy is the administrative override of default policies, which Windows doesn't seem to allow for. Example: assuming that my web browser used an unspecified address for its outbound connection, the OS should have preferred my routed /64 address as the source address when I had the following prefix policy table entries:
Precedence Label Prefix
---------- ----- ----------
...
40 1 ::/0
40 1 2001:470:1f05:a85::/64
... etc.
In other words, for any destination address, select the routed /64 address as the source address. But it didn't work.
So, is there a wget for Windows? I'd like to do this test myself.
That prefixpolicy thing would only work if the IPv6s in question were on the same interface. In RFC3484, the outbound interface address overrides the prefix-policy table when using an unspecified source address. Although, I've tried it on Linux and it still didn't work even when I had two IPv6 publics on one interface and adjusted the "ip addrlabel" table. But I think this is because of the Linux implementation of it. I think under linux you must use /etc/gai.conf for outbound source stuff 'cause of the way it's implemented.
Googling for "windows wget" gets me a few choices. I'm not sure which ones support IPv6 or not. I know the one in Cygwin does, for Cygwin versions > 1.7.
You could also easily write a perl script to demostrate it. Just connect to something after filling the desired IPv6 source address in and check the destination for which IPv6 is connecting.
Unfortunately many of the common built in windows utilities like ping, telnet, etc, don't allow one to specify a source address to use.
Quote from: jimb on April 10, 2010, 05:28:40 PM
Googling for "windows wget" gets me a few choices. I'm not sure which ones support IPv6 or not. I know the one in Cygwin does, for Cygwin versions > 1.7.
You could also easily write a perl script to demostrate it. Just connect to something after filling the desired IPv6 source address in and check the destination for which IPv6 is connecting.
Unfortunately many of the common built in windows utilities like ping, telnet, etc, don't allow one to specify a source address to use.
The WGet for Windows available from here is IPv6 capable:
http://gnuwin32.sourceforge.net/packages/wget.htm (http://gnuwin32.sourceforge.net/packages/wget.htm)
This page has links to all the GNUWin32 packages:
http://gnuwin32.sourceforge.net/packages.html (http://gnuwin32.sourceforge.net/packages.html)
I returned my IPv6 settings to the original tunnel/gateway configuration, and using WGet I was able to verify that the remotely detected IPv6 source address of a connect was the local IPv6 address that was specifically bound to for the connection by WGet. OK.
BTW, the ping app on WS2003 and WS2008 has a -S option that allows specification of a source address for the ping (only valid for IPv6). The thing that threw me off was that whenever I pinged a remote address without specifying the source address, it would always automatically select the tunnel local endpoint IPv6 address. Of course, now I now why--the Default Address Selection Algorithm and the Default Prefix Policy--and, well, I've learned a lot more than that in the process of figuring it out.
Now, I'm just tinkering with the Windows Firewall to close up a few remaining holes...
Ah it's nice they added that option. XP definitely doesn't have it.
Glad to see you got it going. I've never set up windows to be a router before, now I guess I have some idea how to do it if I ever need to. :P
So guys did you find out what to do to make W2008 to ping from that router /64 addres excep removing that local ipv6 endpoint addres from IP6Tunnel ??
On windows 7 you just need to enable RRAS and it will automaticly work <LOL>
Quote from: kzyhlm on January 25, 2011, 03:19:10 PM
So guys did you find out what to do to make W2008 to ping from that router /64 addres excep removing that local ipv6 endpoint addres from IP6Tunnel ??
On windows 7 you just need to enable RRAS and it will automaticly work <LOL>
@kzyhlm,
Yes, buried down there somewhere was the fact that binding your outbound connection to a specific address seems to work OK. (See the stuff about WGet.)
I also found that enabling RRAS was required on WS2003 and WS2008 in order to get IPv6 routing from machines on the LAN to the tunnel interface (without any hardware router).
However, that doesn't change the fact that outbound connections that are not specifically bound to a routed /64 address will appear to be coming from the tunnel endpoint address. This is also true on Win7 (I have it too).
I'm hoping it won't be a big deal. Most service daemons have an option to bind to specific addresses if needed, and as jimb noted, we usually don't care which address our client software uses (e.g., web browser, etc.). When you're hosting multiple domains that require different IP's (for SSL/TLS enabled services), it becomes an important issue. We're still in testing mode right now, but things seems to be working OK so far.
After some experimenting I believe I found a solution to the problem.
Instead of removing your endpoint IP from the tunnel, get it marked as deprecated by setting the preferred lifetime to 0 secs
netsh interface ipv6 set address IP6Tunnel <client endpoint IP> preferredlifetime=0s
The address will still be completely reachable, but any other address assigned elsewhere will be preferred over it.
Hi!
how am I configure IPV6.
Quote from: kleroen on February 07, 2011, 05:29:28 PM
After some experimenting I believe I found a solution to the problem. Instead of removing your endpoint IP from the tunnel, get it marked as deprecated by setting the preferred lifetime to 0 secs
netsh interface ipv6 set address IP6Tunnel <client endpoint IP> preferredlifetime=0s
The address will still be completely reachable, but any other address assigned elsewhere will be preferred over it.
kleroen, that is brilliant!
After re-reading the relevant RFC's:
http://www.rfc-editor.org/rfc/rfc3484.txt (http://www.rfc-editor.org/rfc/rfc3484.txt)
http://www.rfc-editor.org/rfc/rfc2462.txt (http://www.rfc-editor.org/rfc/rfc2462.txt)
http://www.rfc-editor.org/rfc/rfc3315.txt (http://www.rfc-editor.org/rfc/rfc3315.txt)
specifically searching for the keywords: deprecated, lifetime, preferred, valid; It now seems obvious--I am convinced that you have found the correct solution. In fact, I have also deprecated the link-local address assigned to the tunnel interface (just for good measure).
Everything is now working as I originally thought it should. Thank You!
Quote from: smrtguy on February 07, 2011, 11:48:53 PM
Hi!
how am I configure IPV6.
smrtguy,
First, enable the RRAS (Routing and Remote Access Service) and make sure it's started (running). You don't have to configure anything in RRAS, but make sure the service itself is set to Automatic startup mode.
Next, use the 'netsh' program to do the following.
Notes: in the commands below, replace the items in <angle_brackets> with the correct values--don't include the angle brackets in the commands. The following commands are compatible with Vista/Server 2008 and Win 7; the commands for XP/Server 2003 are a bit different (get help with 'netsh int /?' or 'netsh int ipv6 /?', etc.).
Your Host to HE IPv6-in-IPv4 Tunnel Interface Setup:
netsh int teredo set state disabled
netsh int ipv6 6to4 set state disabled
netsh int ipv6 isatap set state disabled
netsh int ipv6 add v6v4tunnel "IPv6 Tunnel" <your_tun_endpt_ipv4_addr> <he_tun_endpt_ipv4_addr>
netsh int ipv6 add address "IPv6 Tunnel" <your_tun_endpt_ipv6_addr> preferredlifetime=0s
netsh int ipv6 add route ::/0 "IPv6 Tunnel" <he_tun_endpt_ipv6_addr> publish=yes
netsh int ipv6 set interface "IPv6 Tunnel" forwarding=enabled nud=enabled routerdiscovery=enabled
Your Host IPv6 NIC Setup:
netsh int ipv6 add address "Local Area Connection" <your_/64_ipv6_addr>
netsh int ipv6 set interface "Local Area Connection" forwarding=enabled nud=enabled routerdiscovery=enabled
netsh int ipv6 add dnsserver "Local Area Connection" <dns_server1_ipv6_addr>
netsh int ipv6 add dnsserver "Local Area Connection" <dns_server2_ipv6_addr> 2
That's about it. You should then be able to ping the HE tunnel endpoint IPv6 address and any other remote IPv6 address (that allows pings). For example:
ping -6 <some_remote_IPv6_addr>
If that works, you're good to go on the IPv6 Internet.
Yeah, I can
Hi there,
I'm trying to get my IP6 Tunnel work over my network.... I'm almost done but I'm missing only one thing (go outside my network with IPv6).
Both pc's are Windows 7 systems.
First I've enabled RRAS on my "server".
I got my tunnel working on my "server" systems with the commands dawkco posted above. I could ping around the world of IPv6.
But when i try to surf to "http://ipv6.whatismyv6.com/" of "http://ipv6.google.com" I got a 404 error. But I could ping that hosts so the tunnel is working.
I tried to give my server a IPv6 IP with the following commands:
netsh int ipv6 add address "LAN verbinding" 2001:470:1f14:132f::5
netsh int ipv6 set interface "LAN verbinding" forwarding=enabled nud=enabled routerdiscovery=enabled
"LAN verbinding" is dutch for "Local Area Connection"
And see here I can surve around the world too! The site http://ipv6.whatismyv6.com/ tell me my IPv6 is 2001:470:1f14:132f::5 and thats correct!
So my job on the server is done I guess?
I tried my other Windows 7 system en put the commands in here:
netsh int ipv6 add address "Draadloze netwerkverbinding" 2001:470:1f14:132f::6
netsh int ipv6 set interface "Draadloze netwerkverbinding" forwarding=enabled nud=enabled routerdiscovery=enabled
"Draadloze netwerkverbinding" is dutch for "Wireless networkconnection"
When I try to ping to 2001:470:1f14:132f::5 i got the following results:
Reply from 2001:470:1f14:132f::55: tijd=564 ms
Reply from 2001:470:1f14:132f::5: tijd=1 ms
Reply from 2001:470:1f14:132f::5: tijd=1 ms
Reply from 2001:470:1f14:132f::5: tijd=4 ms
So my internal connection is working.
When I try to ping the host-end-point IP from my tunnel: 2001:470:1f14:132f::2
I got 4 times "Destination Unreachable"
So I can't come out my network with IPv6.
I'm hoping someone can help me out to fix IPv6 for my local network. What did I do wrong?
This are my ipv6 routes:
[edit]
C:\Users\Sandertjuhh>netsh int ipv6 show route
Public. Type Met Voorvoegsel Idx Naam gateway/interface
------- -------- --- ------------------------ --- ------------------------
Nee Handmatig 256 ::1/128 1 Loopback Pseudo-Interface
1
Nee Handmatig 256 2001:470:1f14:132f::/64 12 Draadloze netwerkverbinding
Nee Handmatig 256 2001:470:1f14:132f::6/128 12 Draadloze netwerkverbinding
Nee Handmatig 256 fe80::/64 14 Bluetooth-netwerkverbinding
Nee Handmatig 256 fe80::/64 12 Draadloze netwerkverbinding
Nee Handmatig 256 fe80::/64 11 LAN-verbinding
Nee Handmatig 256 fe80::25e3:b5f5:a977:6aad/128 14 Bluetooth-netwerkverbinding
Nee Handmatig 256 fe80::415b:1088:4741:91dc/128 11 LAN-verbinding
Nee Handmatig 256 fe80::f9bb:941e:531:e179/128 12 Draadloze netwerkverbinding
Nee Handmatig 256 ff00::/8 1 Loopback Pseudo-Interface
1
Nee Handmatig 256 ff00::/8 14 Bluetooth-netwerkverbinding
Nee Handmatig 256 ff00::/8 12 Draadloze netwerkverbinding
Nee Handmatig 256 ff00::/8 11 LAN-verbinding
[/edit]
Handmatig is dutch for Manual
[edit2]
On request my IPv6 Range is: 2001:470:1f14:132f/64
[/edit2]
unblock your IP address, I have no idea what addresses you're using and can't help
Done... My IPv6 Range is 2001:470:1f14:132f:/64
Can you ping the ::1 address of your tunnel? If yes, your tunnel is up. If no, tunnel is not up.
If yes, what does the routing table look like one one of the hosts that isn't working?
Sorry I forgot to tell :o my bad.
On my "server" system i could ping 2001:470:1f14:132f::1
On my second computer I can't
I've posted the routing table already in my first post in this topic
Ah. I had no idea what that routing table was from.
Your default route looks incorrect..how are you assigning addresses? The default gateway should point to the fe80 address of your IPv6 tunnel server.
I'am assigning addresses with the commands dawkco posted before.
For the system where I post the routing table from is it just like:
netsh int ipv6 add address "Draadloze netwerkverbinding" 2001:470:1f14:132f::6
netsh int ipv6 set interface "Draadloze netwerkverbinding" forwarding=enabled nud=enabled routerdiscovery=enabled
[update]
I've put my fe80 address as the default gateway for my "Draadloze netwerkverbinding" IPv6 Protocol
I don't know where this Link-Lokal address came from but anyhow
My new route table looks like this:
C:\Users\Sandertjuhh>netsh int ipv6 show route
Public. Type Met Voorvoegsel Idx Naam gateway/interface
------- -------- --- ------------------------ --- ------------------------
Nee Handmatig 256 ::/0 12 fe80::f967:6fda:ee5:eebc
Nee Handmatig 256 ::1/128 1 Loopback Pseudo-Interface
1
Nee Handmatig 256 2001:470:1f14:132f::/64 12 Draadloze netwerkverbinding
Nee Handmatig 256 2001:470:1f14:132f::6/128 12 Draadloze netwerkverbinding
Nee Handmatig 256 fe80::/64 14 Bluetooth-netwerkverbinding
Nee Handmatig 256 fe80::/64 12 Draadloze netwerkverbinding
Nee Handmatig 256 fe80::/64 11 LAN-verbinding
Nee Handmatig 256 fe80::25e3:b5f5:a977:6aad/128 14 Bluetooth-netwerkverbinding
Nee Handmatig 256 fe80::415b:1088:4741:91dc/128 11 LAN-verbinding
Nee Handmatig 256 fe80::f9bb:941e:531:e179/128 12 Draadloze netwerkverbinding
Nee Handmatig 256 ff00::/8 1 Loopback Pseudo-Interface
1
Nee Handmatig 256 ff00::/8 14 Bluetooth-netwerkverbinding
Nee Handmatig 256 ff00::/8 12 Draadloze netwerkverbinding
Nee Handmatig 256 ff00::/8 11 LAN-verbinding
[/update]
I'm confused...why are you enabling routing on a machine that's not a router? Furthermore, why are you assigning a static address if your intention is to use RA on your tunnel server to hand out addresses?
I'm not enabling routing on my second computer as far as I know.
I only had enabled RRAS on my first computer where the tunnel works already.
I'm give my router computer and my second computer a static IPv6 address because without IPv6 don't even work on my "server" system. (Yeah I could ping without a static IPv6 but not browse). And dawkco told in his post to do so.. So I was trying to work out his solution.
Maybe RA doesn't hand out addresses. I'm only enabled that server and not configured anything on it (as dawkco told in his post).
___
But for some strange reason its working now. I didn't change anything!
And for some reason it isn't really stable..
Sometimes it works... And sometimes it doesn't after a while its working again without doing anything! Does somebody has any tips for this problem?
Quote from: Sandertjuhh
somebody has any tips for this problem?
Sandertjuhh - sorry, I did not include instructions for the other computers on your LAN. There are two scenarios: (1) the computers on your LAN connect to your tunnel server via a network switch; (2) the computers on your LAN connect to your tunnel server via a router.
The network switch scenario (1) is easy; the router scenario (2) is more complicated (requires a subnetted routed/48 and a local tunnel) and is apparently (from my experience) limited to a connection from one computer (because of the single external address on the router). The following settings, along with those in my past post should help fill in the missing pieces.
Network Switch scenario;
Your (network switched) LAN computer IPv6 NIC Setup, including route to your tunnel server (Vista/WS2008/Win7):
netsh interface teredo set state disabled
netsh interface ipv6 6to4 set state disabled
netsh interface ipv6 isatap set state disabled
netsh interface ipv6 add address "Local Area Connection" <your_other_/64_ipv6_addr>
netsh interface ipv6 add route ::/0 "Local Area Connection" <your_tunnelsrv_/64_ipv6_addr> publish=yes
netsh interface ipv6 add route <your_/64_ipv6_prefix> "Local Area Connection"
netsh interface ipv6 set interface "Local Area Connection" forwarding=enabled nud=enabled routerdiscovery=enabled
netsh interface ipv6 add dnsserver "Local Area Connection" <dns_server1_ipv6_addr>
netsh interface ipv6 add dnsserver "Local Area Connection" <dns_server1_ipv6_addr> 2
Example excerpt from our setup:
netsh interface ipv6 add address "Local Area Connection" 2001:470:1f05:a85::7
netsh interface ipv6 add route ::/0 "Local Area Connection" 2001:470:1f05:a85::6 publish=yes
netsh interface ipv6 add route 2001:470:1f05:a85::/64 "Local Area Connection"
Here's the Local Router scenario;
Your tunnel server to Local Router IPv6-in-IPv4 Tunnel Setup:
netsh interface ipv6 add v6v4tunnel "Router IPv6 Tunnel" <your_tunsrv_endpt_ipv4_addr> <local_router_ext_ipv4_addr>
netsh interface ipv6 add address "Router IPv6 Tunnel" <your_tunsrv_endpt_/64#2(from/48)_ipv6_addr> preferredlifetime=0s
netsh interface ipv6 add route <your_/64#3(from/48)_ipv6_prefix> "Router IPv6 Tunnel" <your_machine_endpt_/64#2(from/48)_ipv6_addr> publish=yes
netsh interface ipv6 set interface "Router IPv6 Tunnel" forwarding=enabled nud=enabled routerdiscovery=enabled
Example excerpt from our setup:
netsh interface ipv6 add v6v4tunnel "Router IPv6 Tunnel" 65.168.232.6 65.168.232.5
netsh interface ipv6 add address "Router IPv6 Tunnel" 2001:470:8224:1::1 preferredlifetime=0s
netsh interface ipv6 add route 2001:470:8224:2::/64 "Router IPv6 Tunnel" 2001:470:8224:1::2 publish=yes
Your computer (on routed LAN) to your tunnel server IPv6-in-IPv4 Tunnel Setup (Vista/WS2008/Win7):
netsh interface teredo set state disabled
netsh interface ipv6 6to4 set state disabled
netsh interface ipv6 isatap set state disabled
netsh interface ipv6 add v6v4tunnel "Router IPv6 Tunnel" <your_machine_private_endpt_ipv4_addr> <your_tunsrv_endpt_ipv4_addr>
netsh interface ipv6 add address "Router IPv6 Tunnel" <your_machine_endpt_/64#2(from/48)_ipv6_addr> preferredlifetime=0s
netsh interface ipv6 add route ::/0 "Router IPv6 Tunnel" <your_tunsrv_endpt_/64#2(from/48)_ipv6_addr> publish=yes
netsh interface ipv6 set interface "Router IPv6 Tunnel" forwarding=enabled nud=enabled routerdiscovery=enabled
Example excerpt from our setup:
netsh interface ipv6 add v6v4tunnel "Router IPv6 Tunnel" 192.168.17.5 65.168.232.6
netsh interface ipv6 add address "Router IPv6 Tunnel" 2001:470:8224:1::2 preferredlifetime=0s
netsh interface ipv6 add route ::/0 "Router IPv6 Tunnel" 2001:470:8224:1::1 publish=yes
Your computer (on routed LAN) IPv6 NIC Setup:
netsh interface ipv6 add address "Local Area Connection" <your_machine_/64#3(from/48)_ipv6_addr>
netsh interface ipv6 set interface "Local Area Connection" forwarding=enabled nud=enabled routerdiscovery=enabled
netsh interface ipv6 add dnsserver "Local Area Connection" <dns_server1_ipv6_addr>
netsh interface ipv6 add dnsserver "Local Area Connection" <dns_server2_ipv6_addr> 2
Example excerpt from our setup:
netsh interface ipv6 add address "Local Area Connection" 2001:470:8224:2::5
Quote from: Sandertjuhh
And for some reason it isn't really stable..
Sometimes it works... And sometimes it doesn't...
Sandertjuhh, if you've been fooling around with different settings (adding, changing, removing, re-adding etc.), you may have to reset the IPv6 configuration and start over. It works best if you start from scratch and apply the correct settings in a step-by-step methodical manner. Then, don't touch it again. If you do a reset, be ready to redo the setup with your notes in hand because it literally wipes out everything from IPv6.
To reset the IPv6 configuration:
netsh int ipv6 reset
Note: If I remember correctly, it makes you reboot the computer after the reset.