• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Need help with creating a working IPv6 tunnel

Started by idjuric10, December 21, 2012, 11:33:52 AM

Previous topic - Next topic

kasperd

Quote from: idjuric10 on December 24, 2012, 07:18:12 AMI enabled DMZ and wanted to start up Wire Shark but now I get this message
No idea how that happened. Looks like it is Windows specific. I don't think that could happen with the Linux version of Wireshark. And I don't think this in any way is related to the DMZ feature on the router.

Quote from: idjuric10 on December 24, 2012, 07:18:12 AMRe-installed WinPcap, should be OK now.
I hope you won't need to do that often. Sounds annoying.

Quote from: idjuric10 on December 24, 2012, 07:18:12 AMI attached the file below.
Packets from Windows machine to tunnel server are still looking good. But you are still getting nothing back. There are no replies or error messages. You are also not getting any ICMPv6 messages from the traceroute commands I am running towards 2001:470:1f0a:90e::2.

So it really looks like packets are not making it through your router to your Windows machine. We don't know if the packets from your Windows machine are making it through the router to the tunnel server. They may be making it through just fine, and the problem might only be the responses not getting back.

So we need to take another look to see if any filtering is happening. Does the filtering page on the router currently list any filters? I think you shouldn't have any filters, and I think the firewall should be set to disabled. I don't know if SPI should be set to enabled or disabled.

I set up a couple of address you can try to ping such that we can find out, if packets from your computer are making it out through your router.
2001:470:1f0b:1da2:a848:bd8e:c71b:28fe
2002:5634:7905:727a:dbf9:80df:51fc:a85f
I'll be able to see if your echo requests reaches either of those two addresses. You can also try to use my IPv4 address 86.52.121.5 instead of specifying the IP address of the tunnel server. That means the netsh command would readnetsh interface ipv6 add v6v4tunnel IP6Tunnel 192.168.1.2 86.52.121.5That's obviously just for testing. I am not running a tunnel server, but you can send packets directly that way in order to reach the two IPv6 addresses I mentioned.

idjuric10

No filters, firewall is disabled, SPI is disabled.



It's the same even after deleting the tunnel with:

Quotenetsh interface ipv6 delete interface IP6Tunnel
netsh interface ipv6 reset

and using:

Quotenetsh interface ipv6 add v6v4tunnel IP6Tunnel 192.168.1.2 86.52.121.5

kasperd

Quote from: idjuric10 on December 24, 2012, 11:17:21 PMIt's the same even after deleting the tunnel with:

Quotenetsh interface ipv6 delete interface IP6Tunnel
netsh interface ipv6 reset

and using:

Quotenetsh interface ipv6 add v6v4tunnel IP6Tunnel 192.168.1.2 86.52.121.5
But this time I can see, that the ICMP echo requests that you send actually made it through to me:Received echo request from 2001:470:1f0a:90e::2 via 178.223.56.238 to 2001:470:1f0b:1da2:a848:bd8e:c71b:28fe ttl=112 len=32
Received echo request from 2001:470:1f0a:90e::2 via 178.223.56.238 to 2001:470:1f0b:1da2:a848:bd8e:c71b:28fe ttl=112 len=32
Received echo request from 2001:470:1f0a:90e::2 via 178.223.56.238 to 2001:470:1f0b:1da2:a848:bd8e:c71b:28fe ttl=112 len=32
Received echo request from 2001:470:1f0a:90e::2 via 178.223.56.238 to 2001:470:1f0b:1da2:a848:bd8e:c71b:28fe ttl=112 len=32
But this also reveals, that your IPv4 address changed again.

Can you try to repeat the experiment but this time try pinging all of these IPv6 addresses:
2001:470:1f0b:1da2:161c:67c3:678a:2837
2001:470:1f0b:1da2:a848:bd8e:c71b:28fe
2002:5634:7905:525a:73af:e547:8d21:8bab
2002:5634:7905:727a:dbf9:80df:51fc:a85f
And let me know which of the four you get a reply from. And while testing, you should still be using 86.52.121.5 rather than the real tunnel server.

idjuric10

Yep, looking at my above post the IP address in the bottom right corner is 178.223.56.238 but I don't think anyone in the house restarted the router so I don't know why it changed.

Tried pinging all four addresses, didn't get a reply from any of them...




kasperd

Quote from: idjuric10 on December 25, 2012, 02:20:58 AMTried pinging all four addresses, didn't get a reply from any of them...
In all four cases the echo request reached me. And I am almost certain the echo reply made it all the way back to your router in at least two of the cases. So I think your router is blocking all protocol 41 packets arriving from the Internet, even when they are replies to packets you have send.

I think you should repeat the above experiment with different combinations of SPI and DMZ enabled and disabled to see if any combination works. From the above list 2001:470:1f0b:1da2:161c:67c3:678a:2837 is the one which has the best chance of getting a reply through.

But I am starting to think it just isn't possible to get it to work with your router firmware. Maybe you can find a firmware update for your router, which can help.

idjuric10

Tried pinging 2001:470:1f0b:1da2:161c:67c3:678a:2837 with all four combinations but none worked.

kasperd

Quote from: idjuric10 on December 25, 2012, 05:51:57 AMTried pinging 2001:470:1f0b:1da2:161c:67c3:678a:2837 with all four combinations but none worked.
Then I think we have exhausted the options with the current firmware on your router. I cannot think of any more you can do other than looking for an updated firmware for the router.

idjuric10

I've already updated the firmware, last year or two years ago, I'm not sure. So I'm afraid it's now safe to say I'm screwed.

kasperd

Quote from: idjuric10 on December 26, 2012, 03:00:33 AMI've already updated the firmware, last year or two years ago, I'm not sure.
A lot of new bugs can be found in a year. You should check if there is a newer firmware.

Quote from: idjuric10 on December 26, 2012, 03:00:33 AMSo I'm afraid it's now safe to say I'm screwed.
There are many other options. If you cannot find an official firmware upgrade for the router, you may be able to find an unofficial firmware with more features. If you can find a good third-party firmware for the router, you may even be able to run the tunnel endpoint directly on the router and get a much better setup that way.

Alternatively you can go with a tunnel broker using other protocols. SixXS supports a much wider range of protocols, some of which should work through your router. Just be aware that SixXS have a quite unpredictable bureaucracy around registration. Some people can get an account, other people cannot.

If all else fails, you can buy yourself a router with proper IPv6 support.

idjuric10

It doesn't seem that the crappy router I'm using is supported enough (or at all) to get constant firmware updates, official or not.

I have until the end of the year to get this to work and set up a web and mail server with an IPv6 address after that. I'm thinking about trying to do it at a friend's house but unfortunately he also has a Huawei router, different model though but who knows if it'll work after all the trouble I've had with setting up mine...

AndrejaKo

Would the PPTP VPN option help here at all? Maybe the router will pass it through its firewall?

kasperd

Quote from: AndrejaKo on December 26, 2012, 04:16:28 AMWould the PPTP VPN option help here at all?
I don't think HE supports that anymore. But do take a look at the offerings from SixXS. They support protocols that should work through most routers and firewalls.

AndrejaKo

Well the point which idjuric10 didn't mention is that we got an assignment from our University to pass he.net IPv6 certification and among other things were told to set up our IPv6 tunnel using he.net.


I don't see why certification wouldn't work using SixXs or gogo6, if our TA doesn't make any problems with that.

kasperd

Quote from: AndrejaKo on December 26, 2012, 04:51:45 AMI don't see why certification wouldn't work using SixXs or gogo6, if our TA doesn't make any problems with that.
If I was the TA and a student gave me a good technical explanation of why the task couldn't be completed using the HE tunnel broker, and simultaneously explained how he found another tunnel broker in order to complete the certification, then I would accept that explanation.

As far as I remember there is some step along the way, which requires functional reverse DNS records. So if I recall that part correctly, then you need to use a tunnel broker, which supports reverse DNS records. Apart from that, I don't think there is any limitations on which IPv6 connectivity, you can use to pass the certification test. You are not even required to use the same IPv6 connectivity for the entire test, as long as you have a domain and can update the DNS records in that domain, you can point them at different IPv6 addresses throughout the test.

You could even use Teredo for the first parts of the test and then switch to a tunnel broker once you reach the point in the test, where you need reverse DNS records.

nickbeee

#44
Quote from: kasperd on December 26, 2012, 05:49:41 AM
As far as I remember there is some step along the way, which requires functional reverse DNS records. So if I recall that part correctly, then you need to use a tunnel broker, which supports reverse DNS records.

If you have registered  with SixXs and set up a tunnel then you can set up reverse DNS pointing at one of the HE free DNS servers. This worked for me.
Nick B.

Tunnelling with [Open|Net|Free]BSD and IOS.
IPv6 courtesy of   HE and   Sixxs.