USG40 connecting to Tunnelbroker.net

gguldens56

My workstation is a Windows 7 system, yours may behave differently.

My USG40 is running 4.33(AALA.0).

If you are familiar with Tunnelbroket.net you know that you generally get 2, \64 subnets that differ in the 3rd 16bit portion of the address. E.G. your connection \64 may have 0001 and your routed \64 may have 0002 as their 3rd 16bit segment.

Step 1 is to set up your tunnel interface (mine is tunnel0).

The mode is IPv6-in-IPv4.

the tunnel IPv6 address is listed on your tunnelbroker tunnel details as "Client IPv6 Address:". Put this into the "IPv6 Address/Prefix Length:" in tour tunnel setup.

Under Gateway Settings "Interface" choose "Interface" can from the drop down choose "wan1".

In the Remote Gateway Address:" place the address found on the tunnel details as "Client IPv4 Address:".

You are now done here, save the settings.

In "Security Policy" and under "Policy Control" I added some rules:

WAN interface to TUNNEL interface IPv4 Source is my WAN address. IPv4 Destination is the same address you put into the "Remote Gateway Address" above.

IMPORTANT!!! the "Service must be set to "IP6to4".

Now, here is where I had multiple things going on with my Windows 7 system that may have affected my work. Tried to ping the the Client IPv6 address on the tunnel and it worked, but pinging the other end did not. Eventually I ran "ipconfig /all" and saw a bunch of temporary IPv6 addresses, not bad in and of itself. What I found that WAS bad was that I had both the 0001 and 0002 3rd 16 bit sections of the IPv6 address which is NOT supposed to change since these are /64 (4, 16 bit sections) masks.

My solution was to turn off ipv6 autoconfig--since I assign static addresses--I also turned off the creation of those temporary addresses which appeared to be the problem. I still cound not pinf the far end of the tunnel.

Back on the USG40, I had setup some policy routes to define the routing I wanted. I also clicked to check the box "Use IPv6 Policy Route to Override Direct Route". DO NOT DO THIS, turned out this prevented my IPv6 to the world from working.

Since I have now spent more than 20 hours over 6 days working to get this functional, I KNOW there are things that I have overlooked here. Hopefully, what I am forgetting to mention is the easier stuff to diagnose.

I use wireshark and found the packet capture feature invaluable in diagnosing this issue because it pointer to me the "temporary" IPv6 addresses that my Windows 7 system was using and that was the turning point in my work to get IPv6 working.

Wanted to share this with others because diagnosing the improper IPv6 temporary addresses was ridiculously difficult when I was not expecting Windows to use improper IPv6 addresses.