I'm setting up a tunnel (Debian 6.0) as described in http://www.chronos-tachyon.net/reference/debian-ipv6-and-hurricane-electric
I have done this part:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.213
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.168.1.1
auto hurricane0
iface hurricane0 inet6 v4tunnel
address 2001:470:1f14:xxx::2
netmask 64
endpoint 216.66.84.46
local 77.251.22.yyy
gateway 2001:470:1f14:xxx::1
ttl 255
According to the web page description I should be able to test.
QuoteNow save the file and run "sudo ifup hurricane0". This will bring up your end of the tunnel. Try running "wget -O/dev/null http://ipv6.google.com/"
to verify connectivity
When I give that command, I get
root@asteriskondebian:~# wget -O/dev/null http://ipv6.google.com
--2013-06-16 20:22:47-- http://ipv6.google.com/
Herleiden van ipv6.google.com... 2a00:1450:400c:c03::63
Verbinding maken met ipv6.google.com|2a00:1450:400c:c03::63|:80... mislukt: Geen route naar host. (english = failed:No route to host)
root@asteriskondebian:~# /A ping6 gives me:
root@asteriskondebian:~# ping6 google.com
PING google.com(we-in-x65.1e100.net) 56 data bytes
From henkoegema-1-pt.tunnel.tserv11.ams1.ipv6.he.net icmp_seq=1 Destination unreachable: Address unreachable
From henkoegema-1-pt.tunnel.tserv11.ams1.ipv6.he.net icmp_seq=2 Destination unreachable: Address unreachable
From henkoegema-1-pt.tunnel.tserv11.ams1.ipv6.he.net icmp_seq=3 Destination unreachable: Address unreachableIs there anything wrong in my /etc/network/interfaces file ? ::) or am I missing something else ?
The local address you specified on the tunnel does not match the address assigned to eth0.
Changing the local address of the tunnel could work, assuming there is a NAT between the tunnel endpoint and the tunnel server, and that NAT can handle protocol 41.
Another option is to put the tunnel endpoint on the device doing NAT. This is a better option, since then the tunnel doesn't have to go through a NAT. But not all devices have support for operating as a tunnel endpoint, so you could be using a device without support for this.
Quote from: kasperd on June 16, 2013, 02:47:13 PM
The local address you specified on the tunnel does not match the address assigned to eth0.
Thanks very much for your answer. I'm one step closer now.
I've changed 77........ to 192.168.1.213 (was thinking I had to use my dynamic ISP address; but that was wrong: I should have read better ;) )
But I'm still not there:
root@asteriskondebian:~# wget -O/dev/null http://ipv6.google.com
--2013-06-16 22:50:26-- http://ipv6.google.com/
Herleiden van ipv6.google.com... 2a00:1450:400c:c03::63
Verbinding maken met ipv6.google.com|2a00:1450:400c:c03::63|:80... mislukt: Verbinding is verlopen. (english = failure: Connection timed out)
Nieuwe poging. (english = New trial)
--2013-06-16 22:50:48-- (poging 2) http://ipv6.google.com/
Verbinding maken met ipv6.google.com|2a00:1450:400c:c03::63|:80... mislukt: Verbinding is verlopen.
Nieuwe poging.
--2013-06-16 22:51:11-- (poging 3) http://ipv6.google.com/
Verbinding maken met ipv6.google.com|2a00:1450:400c:c03::63|:80... ^C
root@asteriskondebian:~# In the router from the ISP provider, I've forwarded port 41 to server 192.168.1.213.
protocol 41 not port, it is neither tcp or udp, but a protocol
Quote from: kasperd on June 16, 2013, 02:47:13 PM
The local address you specified on the tunnel does not match the address assigned to eth0.
Changing the local address of the tunnel could work, assuming there is a NAT between the tunnel endpoint and the tunnel server, and that NAT can handle protocol 41.
Even after two days of struggling, I haven't managed yet. :( (but I'm not willing to give up)
I've changed the local address of the tunnel to my server IP address.
I suppose that my NAT (Cisco EPC3925 EuroDocsis 3.0 2-PORT Voice Gateway) can handle protocol 41, since it works with a Raspberry Pi and SixXS.
Quote from: kasperd on June 16, 2013, 02:47:13 PM
Another option is to put the tunnel endpoint on the device doing NAT. This is a better option, since then the tunnel doesn't have to go through a NAT. But not all devices have support for operating as a tunnel endpoint, so you could be using a device without support for this.
What (the tunnel endpoint) should I put on the device doing NAT and where? Something with forwarding or ......???
Quote from: henkoegema on June 18, 2013, 08:00:57 AMI suppose that my NAT (Cisco EPC3925 EuroDocsis 3.0 2-PORT Voice Gateway) can handle protocol 41
I don't know that specific device.
Quote from: henkoegema on June 18, 2013, 08:00:57 AMsince it works with a Raspberry Pi
That is a piece of hardware. What protocols it communicates with depends on the software installed on it, and how that was configured.
Quote from: henkoegema on June 18, 2013, 08:00:57 AMand SixXS.
SixXS supports a variety of protocols. Some of those are much more likely to work through a NAT device than 6in4 is.
Quote from: henkoegema on June 18, 2013, 08:00:57 AMWhat (the tunnel endpoint) should I put on the device doing NAT and where? Something with forwarding or ......???
No it has nothing to do with forwarding. The point is to eliminate the need for forwarding. How to set it up is different depending on the router and in particular the firmware it is running. Look in the configuration of the router for IPv6 connectivity, tunnelling, or 6in4. If you don't know where to look for it in the configuration, you could post a screenshot of the router configuration, and we might be able to point you in the right direction.
There's now more space for attachments.