Print

[kasperd]

there is no hint that the router itself handles IPv6.  Although that doesn't mean conclusively that it won't pass protocol 41 (6in4), there does seem to be a corrolation between not doing so when IPv6 support is missing.

I have seen many routers with no IPv6 support, and a builtin DNS server which fails in spectacular ways, if it receives AAAA queries, but still capable of forwarding protocol 41 without a problem.

Some need a DMZ option to forward protocol 41 packets to a specific LAN IP. Others can handle protocol 41 in the default configuration by using connection tracking (which just assumes all packets with a particular protocol number + remote IP combination is a single connection).

[kasperd]

It's still available even if I disable the firewall option... So I'll set SPI back to Disable, which was the default option.

If setting firewall to disabled, doesn't solve the problem, then we are going to need traffic dumps to make any further progress. Can you install Wireshark on that machine?

[idjuric10]

It's still available even if I disable the firewall option... So I'll set SPI back to Disable, which was the default option.

If setting firewall to disabled, doesn't solve the problem, then we are going to need traffic dumps to make any further progress. Can you install Wireshark on that machine?

Sure. Care to elaborate on what I need to do once it's installed since I don't have a lot of experience with using it?

[kasperd]

Care to elaborate on what I need to do once it's installed since I don't have a lot of experience with using it?

You need to do a packet capture on the physical network interface that connects the computer to the router. In the Linux version I can start a capture by just starting Wireshark and then clicking on the name of the network interface. Probably it is about the same in Windows. But the naming of network interfaces is totally different, so I cannot tell you what name to look for in the list of network interfaces.

Then while the capture is running, try to do an IPv6 ping of any IPv6 address outside your own LAN.

Once you are done with that, you need to click the stop icon (it is the fourth icon on the list in the Wireshark version I have here). Then go to the "File" menu and choose "Save As".

If your computer is doing something else on the network connection, while you are running the capture, you may also need to use the filtering features in Wireshark. I recommend you avoid doing a lot of unrelated stuff on the network connection, while running Wireshark, such that you won't need the filtering.

I am leaving a traceroute to 2001:470:1f0a:90e::2 running until you have done the packet captures, that way we can also see if any packets from me make it through your router.

Additionally, I'd like to have you check again that the router is showing the expected IPv4 address on the WAN interface. I guess you find that under "Status" or under "Basic", "WAN Setting".

[idjuric10]

OK, here's the file, hopefully I did everything correctly:

http://www46.zippyshare.com/v/80457274/file.html

Additionally, I'd like to have you check again that the router is showing the expected IPv4 address on the WAN interface. I guess you find that under "Status" or under "Basic", "WAN Setting".

[kasperd]

OK, here's the file, hopefully I did everything correctly

When looking in the file, I do see the IPv6 echo requests going from your computer to the router. I do not see anything coming back, no errors, no responses. I'll think about the next step in debugging and reply later (maybe today, maybe another day).

Notice that you can attach files directly in this forum. There is no need to use third party sites for such attachments. And that particular site you uploaded the file to looked a bit fishy. It was difficult to find the correct download link due to the download links to various exe files all over the page.

Additionally, I'd like to have you check again that the router is showing the expected IPv4 address on the WAN interface. I guess you find that under "Status" or under "Basic", "WAN Setting".

Four virtual interfaces with two IPs. I am wondering what criteria the router use to choose between them. Also the IP seen there is different from the one you mentioned earlier.

Does that mean your public IP is dynamic and it changed since your first post? Or is your router actually using the RFC 1918 address and going through another layer of NAT with the previously mentioned IP address being the public IP address of the other NAT?

If the problem was just that the IP had changed and you didn't get it updated on the tunnel server, then the packet trace you uploaded should have shown ICMP errors from the tunnel server, but there were no such errors in the trace.

If you look on each of your posts in this thread, then in the lower right corner you can see, which IP you posted from. Can you tell us, what is showing up there?

[idjuric10]

Sorry about that, I'll use the attach option on the forum next time.

Entering ipconfig now gives me the same ip address as before:





178.223.27.71 is showing in the bottom right corner.

[kasperd]

Entering ipconfig now gives me the same ip address as before

That's the LAN address. That one is not very likely to change.

178.223.27.71 is showing in the bottom right corner.

Also on the first post, where you mentioned the IP address 79.101.74.9?

Which IP address is specified on the tunnel configuration page on tunnelbroker.net?

[idjuric10]

77.46.208.16 is in the bottom right corner of my first post and all the others on the first page except the last one which has 178.223.27.71.

The address I quoted in the first post is the one I copied from the Tunnel Details page:



I was told that I was supposed to replace that with my LAN IP address, 192.168.1.2, which I did.

[kasperd]

77.46.208.16 is in the bottom right corner of my first post and all the others on the first page except the last one which has 178.223.27.71.

So it sounds like you have a dynamic IPv4 address on the WAN side of your router. And it changed at least twice during the time you tried to set up the tunnel. Did you power off or restart the router during this period?

I was told that I was supposed to replace that with my LAN IP address, 192.168.1.2, which I did.

That's correct. When running the tunnel endpoint behind a NAT, the tunnel endpoint only needs to know the IP on the LAN, not the WAN address of the router.

The tunnel server OTOH does need to know the WAN address of your router. That means each time it changes, you need to go to tunnelbroker.net and update the tunnel configuration with the new WAN address of your router. There are ways to automate that, but I think you should wait with the configuration of that until you manage to get at least a single IPv6 ping response through the tunnel.

Until then use the tunnelbroker.net web interface to manually update the WAN address of your router, and try to keep your router online continuously, such that it doesn't change IP address so frequently.

[idjuric10]

Someone else in the house probably restarted the router. I was wondering if I needed to do that anyway after making an adjustment in the settings in order for it to work but I guess I shouldn't do that as my IP address will change.



This is where I'm supposed to change it, right? Then why am I getting this message when the firewall is currently set to disabled in the router settings?

[kasperd]

This is where I'm supposed to change it, right?

Yes.

Then why am I getting this message when the firewall is currently set to disabled in the router settings?

I don't get any response when I try to ping 178.223.27.71, so the report from tunnelbroker.net is correct. I don't know why your router doesn't respond to echo requests, when you have disabled the firewall.

I can only suggest you try all four possible combinations of the firewall and SPI settings to see if any of them permits pinging your router.

It is possible the DMZ feature is implemented in such a way that when you enable DMZ the echo requests are also forwarded from the router to the Windows box, and you have a firewall on the Windows box blocking echo requests. If this is the case, then running Wireshark while trying to update the IP address should reveal the echo requests coming through to the Windows box and not being replied to.

Though if that is really the case, then the router should still have been visible as a hop on a traceroute to your IP. So I should have seen 178.223.27.71 as a hop on the route, but not the last one. And then packets getting dropped past that.

So it would require the DMZ feature to not only forward ICMP requests to the Windows box, but also do it without proper decreasing the TTL value. It is a possible explanation, router firmwares are rarely known for their excellent quality.

[idjuric10]

Tried all four combinations of the firewall and SPI settings, got the error message every time. Set the DMZ option back to disabled and:



So what now?

[kasperd]

Tried all four combinations of the firewall and SPI settings, got the error message every time. Set the DMZ option back to disabled and:

That leaves two possible explanations. Either they thought it was a good idea to have the DMZ feature forward echo requests to the LAN IP without even decreasing TTL, and something is filtering the echo requests on the LAN side. Or the DMZ feature in this router is just very broken.

There are still some possibilities left. It may be that after your WAN IPv4 address changes, you need to perform the following steps:

• Disable DMZ on the router
• Update IPv4 address through the tunnelbroker.net website
• Enable DMZ on the router again

That's more step than one would like to have to do each time the IPv4 address changes, but before we try to get that process simplified, let's figure out if those steps will actually get the tunnel working.

You have done the first two steps, so the next step would be to enable DMZ again. The IPv4 update page only requires you to respond to ICMP echo request for long enough to update the IP. Once it has been updated, it will stay with that setting, even if it stops responding to ICMP echo requests again.

So enable DMZ. And repeat the experiment from http://www.tunnelbroker.net/forums/index.php?topic=2747.msg16106#msg16106

[idjuric10]

I enabled DMZ and wanted to start up Wire Shark but now I get this message:



Re-installed WinPcap, should be OK now. I attached the file below.