Ping timeout

[inf402]

Hi there !

These are my first practice steps in ipv6 and I hope, you can help me.
I have created a tunnel as it was shown at the WebGUI.

I'm sitting behind a router with NAT, so I put my local IP in the configuration :

netsh interface teredo set state disabled
netsh interface ipv6 add v6v4tunnel IP6Tunnel 10.10.4.6 216.66.80.30
netsh interface ipv6 add address IP6Tunnel 2001:470:1f0a:1234::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:1f0a:1234::1

if I start a ping, I see, that the lookup / dns works, but I get no answer.

PS C:\Users\max> ping -6 ipv6.google.com

Ping wird ausgeführt für ipv6.l.google.com [2a00:1450:8006::68] mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 2a00:1450:8006::68:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),
PS C:\Users\max>


Where should I start to debug ?

regard Max

[jimb]

DNS works because it's using IPv4 to get the AAAA for google.

Check to make sure your firewalls (both network and host based) aren't blocking IP protocol 41 (6in4).  You may also want to put a protocol forward on your network firewall to forward IP protocol 41 to your windows box (not all devices support proto forwards though).

[uTasker]

Hi All

I too am taking first steps but am having the same, or a slightly problem.

1) I configured the IPV6Tunnel with the same commands. Also I have a router (NAT) so put the local IP address in the v6v4 tunnel configuration. [note that local address is a bit confusing - I first tried the address of the gateway and then the address of the local PC. With the gateway address no pings were sent - just adapter error messages appeared. With the PC's IP address IPV6 pings were sent].
2) When trying to ping the said address I get a AAAA DNS answer so the IPV6 address is known.
3) The IPV6 ping (Echo request) is sent out and also gets an answer from the remote address (with a round trip time of about 40ms) - visible with Wireshark. But no tunneling takes place - it is pure IPV6.

Perhaps this means that my cable modem supports IPV6 (otherwise I assume that the pure IPV6 ping would never get to the destination and back) but I wonder why it doesn't pack the IPV6 into IPV4 - and also why the ping answer (visible in Wireshark) is not recognised by the PC?

Here are my settings:


Ethernet-Adapter LAN-Verbindung:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit Ethernet NIC (NDIS 6.0)
   Physikalische Adresse . . . . . . : 00-1C-23-4D-59-E1
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::e1c1:abb6:ac36:43fc%9(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.0.187(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Samstag, 1. Mai 2010 19:52:44
   Lease läuft ab. . . . . . . . . . : Samstag, 8. Mai 2010 19:52:45
   Standardgateway . . . . . . . . . : 192.168.0.1
   DHCP-Server . . . . . . . . . . . : 192.168.0.1
   DNS-Server  . . . . . . . . . . . : 62.2.17.61
                                       62.2.24.158
   NetBIOS über TCP/IP . . . . . . . : Aktiviert


Tunneladapter IP6Tunnel:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Direct-Punkt-zu-Punkt-Adapater
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : 2001:470:25:105::2(Bevorzugt)
   Verbindungslokale IPv6-Adresse  . : fe80::4974:530:31c3:f60e%8(Bevorzugt)
   Standardgateway . . . . . . . . . : 2001:470:25:105::1
   DNS-Server  . . . . . . . . . . . : 62.2.17.61
                                       62.2.24.158
   NetBIOS über TCP/IP . . . . . . . : Deaktiviert


IPv6-Routentabelle
===========================================================================
Aktive Routen:
If Metrik Netzwerkziel             Gateway
  8    281 ::/0                     2001:470:25:105::1
  1    306 ::1/128                  Auf Verbindung
  8    281 2001:470:25:105::/64     Auf Verbindung
  8    281 2001:470:25:105::2/128   Auf Verbindung
  9    281 fe80::/64                Auf Verbindung
  8    281 fe80::/64                Auf Verbindung
  8    281 fe80::4974:530:31c3:f60e/128
                                    Auf Verbindung
  9    281 fe80::e1c1:abb6:ac36:43fc/128
                                    Auf Verbindung
  1    306 ff00::/8                 Auf Verbindung
  9    281 ff00::/8                 Auf Verbindung
  8    281 ff00::/8                 Auf Verbindung
===========================================================================
Ständige Routen:
If Metrik Netzwerkziel             Gateway
  0 4294967295 ::/0                     2001:470:25:105::1
===========================================================================


The PING was sent from 2001:470:25:105:1 to 2a00:1450:8004::67
and the reply arrived from 2a00:1450:8004::67 to 2001:470:25:105:1


Does anyone know what may be going on....??

Regards

Mark

[uTasker]

Hi

I have an update to the last post.

I tried pinging the same address from a device which operates in pure IPV6 mode. This was not getting any response so I checked more carefully the Ethernet frames with Wireshark and realised that the frames from the PC (with active tunnel) were in fact being sent with first an IPV4 layer with protocol 41 (Wireshark doesn't interpret this as 6to4 but instead just displays IPV6 (?))

Encapsulated in the IPV4 is IPV6 and ICMPV6. The IPV4 remote IP address is indeed the tunnel access point.

This detail is not seen when just looking 'normally' at the frames, but only becomes obvious when the frame protocol layers are expanded and studied...

The remote address gives a response which is in the same format which can be seen at the PC - that means that it is indeed getting through the router (both directions). (Its source IPV4 address is again the tunnel access point).

The intermediate conclusions that I make are these:
1) I do need to use tunneling.  Attempts with pure IPV6 fail - the cable connection can thus not handle pure IPV6.
2) Everything is fine until the response arrives back at the PC - then it never arrives at the application layer.

I disabled Windows Firewall to see whether this was blocking but this didn't help.

So I wonder why tunneling is working correctly in the tx direction, out into the Internet and back again, but nothing arrives at the PC application levels?

Any ideas?

Regards

Mark

[jimb]

OK.  Some real basic facts here:

• If your ISP supported IPv6 natively, you wouldn't need Hurricane Electric to provide IPv6 access.
• Hurricane Electric's Tunnel Broker service uses 6in4 IPv6-over-IPv4 tunneling to provide access to the IPv6 internet.  6in4 tunnels IPv6 packets inside of IPv4 packets with the protocol header field set to 41.

You may have mixed up the routed /64 address (which is supposed to go on your LAN interface) and the client and server IPv6 addresses.  Looking at your output, it looks like you may have used your routed /64 address for your tunnel IPv6 addresses, since the 3rd quad is an odd number, and should be an even number based on what I've seen of the way HE sets up it's IPv6 address plans for the tunnel broker POPs.  In other words, I believe your tunnel interface IPv6 address should be 2001:470:24:105::2, not 2001:470:25:105::2.  Check the tunnelbroker.net tunnel details page to make sure you haven't used the wrong addresses in the wrong places.

If you're not providing IPv6 to your LAN, and just want it on the one machine you don't need to use the routed /64.

If that doesn't work, you need to make sure that the 6in4 packets are both getting to the HE tunnel server, and that you are receiving these 6in4 packets back to the tunnel client system.  This can indeed by done by monitoring using software like wireshark.  If you see the 6in4 packets arriving from the tunnel server to your tunnel client box's IPv4 address, then there is something wrong going on on your PC, as you've noted.  This could be caused by any number of things.  Windows being broken somehow.  A firewall blocking the traffic, especially if you're running a 3rd party firewall typically included in an anti-virus package such as Norton.  Lots of things.

- Jim

[uTasker]

Hi Jim

The settings were correct - I had copied and pasted them and doubled checked.

I did finally identify the problem. It is the router - it doesn't support this, so it was sending the ping responses to a device set-up in the DMZ. Everything looks fine when viewing this with Wireshark since it shows the IPV6 stuff - only when looking at the Ethernet MAC address and IPV4 information I realised that it wasn't the MAC address/IP of the PC but of something else.

The D-LINK that I have can do standard stuff like virtual server, TCP and UDP filtering, plus it can allow/deny ICMP, but I don't think that it can identify "6to4", so it sends this to the device in the DMZ.

I put my PC in the DMZ for a quick test and then it worked - I could ping and also browser an IPV6 based web site.

Since I don't think that it is a good idea to leave the PC in the DMZ I disabled this again immediately after confirming it. I will have a go at finding a router that can handle this (unless someone can suggest a simple method to do it with what I already have).


By the way - the main aim is however to get the device in the DMZ to communicate (in fact multiple devices eventually) via IPV6 in the Internet. These are small sensor devices (processors cost about $5 including the Ethernet interface and all memory that they require) - they can "talk" in the local network via IPV6 but the next step is to be able to do in world-wide, requiring tunneling so that it can work practically during the transition phase to IPV6. This will be the next development step, to add the tunneling mechanism to these small devices too....

Regards

Mark

More info at
http://www.utasker.com / http://www.utasker.com/forum

[jimb]

It sounds like another system on your LAN was attempting to do 6in4 or 6to4 (both use IP proto 41).  Your NAT device probably had a connection table entry in it pointing 6in4/6to4 traffic to that device instead of your tunnel machine, since it sent the traffic first.

The best way to fix this is to do a protocol forward on your router to permanently point IP proto 41 to your router.  You could also try to locate any devices other than your router attempting to do 6to4/6in4 and turn whatever is trying to do it off so that it doesn't "hijack" the NAT.

Unfortunately, many devices don't let you do a forward for protocol 41 (only TCP ports and such).  I suggest either getting a router which does, or better, a router which supports 6in4 directly so you can terminate your IPv6 tunnel to the router instead of your inside PC.  The Linksys DIR615 can do this I believe.  You may also want to investigate alternate firmware for your router (DD-WRT, etc) and see if any does IPv6.

If you have an old PC or laptop laying around which has at least two ethernet interfaces, you can easily set this up as a router using something like pfsense or m0n0wall or linux iptables.  These would allow you to terminate the tunnel directly to them also, and probably work better than your consumer grade router.  Although, if your current router has DSL or cable directly connected to it, you'll have to put it into bridge only mode to use something else as a router.