Could not grab the file via IPv6 HTTP

[intrinsit]

Has anyone else tried to pass the "Enthusiast" IPv6 certification that is a Cable Vision customer? They block HTTP (80), HTTPS (443), and some other ports like SMTP (25).  I have a Windows 2008 Server setup IPv6 Tunnel established with HE via my RFC1918 IPv4 address and then the IPv4 Address on the HE side. I can browse IPv6 websites, I can ping IPv6 addresses seems to be everything is working.

When I attempt to get HE to hit my URL to validate it, I get the "Could not grab the file via IPv6 HTTP" error. It dawned on me that Cable Vision (Optimum Online) does not allow TCP/80 as I said above. No issue, I will change my port on web server and try again, this time specify http://denali.us.to:4867 Unfortunately you are unable to specify a different port in the "Tell us what your IPv6 website is; FQDN please" field.

Anyone have a work around for this?

Any suggestions are greatly appreciated.

[cholzhauer]

I think you're barking up the wrong tree here...cable vision wouldn't see the request on port 80 because all of the ipv6 traffic is being tunneled, so they have no idea what sort of traffic is comming in. 

Id  look at a firewall issue on your side

[kasperd]

Probably those filters mean nothing to you. Most providers with such filters don't inspect what's inside tunnels (and they really have no business inspecting anyway, since those IPs are not theirs in the first place). I tried to traceroute your IP address 2001:470:1f07:4e8::10 with a few different packets, and I got no reply with any of the packets I tried.

My first three guesses at what may be going on are:
1. Your tunnel is going through a NAT and you would need to ping the tunnel server frequently to keep the NAT entry active and ready for incoming packets.
2. You are running an IPv6 firewall on your own tunnel endpoint, and that is blocking the packets.
3. You got your own IPv6 address wrong when setting up the AAAA record.

I also tried a traceroute to 2001:470:1f06:4e8::1, which I assume is the server side of your tunnel, and that worked all the way.
I also tried a traceroute to 2001:470:1f06:4e8::2, which I assume is the client side of your tunnel, and that failed the same as tracing the IPv6 address from your AAAA record.

If you have checked that none of the above three are the reason, then let us know, and we'll investigate a bit further. You can check what your IPv6 address is on my test page http://netiter.dk/test-ipv6 or just go to google and search for "what is my ip".

I am considering putting up a webserver that automatically will perform a traceroute back to the client it was accessed from using SYN ACK packets with varying hop limit. That would allow a webservice to perform such a traceroute in a way that bypass practically every blocking mechanism. If you think that would be useful in debugging your issue, please let me know. But it would be at least a week or two before I find time to actually implement it.

[intrinsit]

Good point with the ISP not inspecting the tunnel traffic I never thought of that, obviously. Ill take a look at my side and see what I can figure out.

Thanks for the replys. Much appreciated.

[intrinsit]

kasperd- your suspicion of the 3 possible reasons would be correct, it is the 1st. i have created my tunnel from a NAT'ed IP behind my firewall. The IP is 192.168.1.4 so where HE has the example for the various OS I had picked the Windows 7/2008 option and where it had my public IP in the tunnel creation I used the RFC1918 IP behind the firewall. Like I said i can ping across that tunnel to ipv6.he.net, ipv6.google.com and they all work. As well as browsing any IPv6 sites. I do not believe it is on my side with my Firewall blocking some of the traffic for some reason. I did open up an ANY/ANY rule to and from the IPv4 endpoint where the tunnel was created since that is where all tunnel traffic would source from, am I correct in this assumption? I have also disabled the Firewall on my 2008 box. 

[kasperd]

i have created my tunnel from a NAT'ed IP behind my firewall. The IP is 192.168.1.4 so where HE has the example for the various OS I had picked the Windows 7/2008 option and where it had my public IP in the tunnel creation I used the RFC1918 IP behind the firewall.

How well that is going to work out depend a lot on the specifics of the NAT.

• On some NAT devices it is just not going to work.
• On some NAT devices it mostly work without any configuration of the NAT as long as you use only a single tunnel
• On some NAT devices you have to active a feature, which is usually called DMZ in order for it to work.

If you did not configure anything on the NAT, it has to remember which IP behind the NAT was the tunnel endpoint. That entry will time out. And if you try to run multiple tunnels, you can get weird conflicts. If you are using the DMZ feature, then you explicitly indicate which address behind the NAT to use, and you avoid timeouts and conflicts. But then you will of course only be able to have one single tunnel endpoint behind the NAT.

Like I said i can ping across that tunnel to ipv6.he.net, ipv6.google.com and they all work. As well as browsing any IPv6 sites. I do not believe it is on my side with my Firewall blocking some of the traffic for some reason.

Did you also check that the websites report the same IP address as the one you put in your AAAA record?

If you access the certification site over IPv6, then that should put an entry in your NAT, which should exist for long enough for the file to be fetched by the test server. I don't know why that doesn't work for you. It is possible that there is another problem as well, but due to the NAT timeout I just can't even see the second problem.

I did open up an ANY/ANY rule to and from the IPv4 endpoint where the tunnel was created since that is where all tunnel traffic would source from, am I correct in this assumption?

I don't know what such a rule on a NAT device would mean.

[intrinsit]

See if you can now ping 2001:470:1f06:4e8::2 i was able to from an website which allows pinging of the IPv6 address. If so then i am one step closer.

[kasperd]

See if you can now ping 2001:470:1f06:4e8::2

Yes, I can. Here is the traceroute output as it currently looks from my end

Code Select Expand

traceroute to 2001:470:1f06:4e8::2 (2001:470:1f06:4e8::2), 30 hops max, 80 byte packets
1  2001:470:1f0b:1e45:1f9c:c1d2:c8b6:9008  0.171 ms  0.176 ms  0.215 ms
2  2001:470:20::2  106.810 ms  109.772 ms  111.062 ms
3  2001:470:1f06:4e8::2  131.371 ms  116.320 ms  116.713 ms


Since my previous posts I hacked together a very simple reflector service, that will reflect all TCP and UDP packets back at the source, you can access it at reflector.easyv6.net. It does not reflect ICMP packets, so if you are going to traceroute it, your results will be incomplete. But you can try to access it using http and see if the requests get back to your own webserver.

[kasperd]

See if you can now ping 2001:470:1f06:4e8::2

Yes, I can.

But I still cannot reach 2001:470:1f07:4e8::10. Here is the traceroute output

Code Select Expand

traceroute to 2001:470:1f07:4e8::10 (2001:470:1f07:4e8::10), 30 hops max, 80 byte packets
1  2001:470:1f0b:1e45:1f9c:c1d2:c8b6:9008  0.285 ms  0.124 ms  0.157 ms
2  2001:470:1f0a:1e45::1  44.725 ms  50.528 ms  55.889 ms
3  2001:470:0:69::1  66.640 ms  45.915 ms  45.955 ms
4  2001:470:0:1d2::1  50.168 ms  50.493 ms  58.871 ms
5  2001:470:0:128::1  122.587 ms  126.601 ms  126.650 ms
6  2001:470:20::2  119.126 ms  122.102 ms  126.318 ms
7  *  *  *
8  *  *  *
9  *  *  *
10  *  *  *
I would have expected 2001:470:1f06:4e8::2 to be hop number 7 in that trace output.

The IPv4 encapsulation of the packets as they travel from the tunnel server to your tunnel endpoint would look the same in both cases, and the IPv4 encapsulation of the packets going back from your tunnel endpoint to the tunnel server would also look the same in both cases. This means whatever is causing the difference between a traceroute to 2001:470:1f06:4e8::2 and one to 2001:470:1f07:4e8::10 must be looking at the IPv6 headers.

In other words the problem that prevents me from tracing 2001:470:1f07:4e8::10 must either happen at one of the tunnel endpoints while the IPv6 packets are not encapsulated, or some device between the two endpoints is actually inspecting the inside of the tunneled packets and treating them differently depending on their IPv6 address.

In order of likelyhood, these are my guesses at what is causing the difference, which I observed:

• Your tunnel endpoint has a firewall blocking some of the packets
• Your tunnel endpoint has a routing misconfiguration causing it to not handle the routed prefix correctly
• Your NAT knows something about protocol 41 and is trying to be smart (and is failing at that)
• Your tunnel is misconfigured on the tunnel server

[intrinsit]

kasperd-

THANK YOU! I redid the entire tunnel using the ::2 address which works. The reason the URL was not working was because I changed it to ::10 and then back to ::2 and made so many changes. I made a completely new URL (afraid.org) and I got pass this error, it pulled the file from my webserver in no time!!! Thank  you for the help. ::10 is no longer in use as it was another interface on that ::2 box.

I now need to get a free mail server to put on here and get past this next stage.

[kasperd]

It appears your NAT has a five minute timeout. If there is no traffic on your tunnel for five minutes, the NAT forgets about the tunnel. And then it is not possible to get any IPv6 packet from the Internet into your network. To get the tunnel working again, you have to send an IPv6 packet from your network to the Internet.

Running a ping command on your LAN could keep the connection alive. This command would work on Linux, the exact arguments may need to be slightly different on other OS:

Code Select Expand

ping6 -ni 149 2001:470:20::2