I have a Debian system configured as a gateway and a second Debian system behind it serving as a client. I installed a new video card on the client, and after the reboot lost IPV6 connectivity (IPV4 still works). The client has an IPV6 address (assigned by RADVD) but can't connect out via IPV6. I can connect to the internet from the gateway machine, but when I try to ping out from the client I get this:
jhaiduce@tbm:~$ ping6 ipv6.google.com
PING ipv6.google.com(den03s06-in-x12.1e100.net) 56 data bytes
^C
--- ipv6.google.com ping statistics ---
76 packets transmitted, 0 received, 100% packet loss, time 75600ms
Here's the routing table on the client:
2001:470:0:63::2 via fe80::250:daff:fe73:d306 dev eth0 proto static metric 32650
2001:470:d:51c::/64 dev eth0 proto kernel metric 256 expires 86295sec
2001:4860:b007::79 via fe80::250:daff:fe73:d306 dev eth0 proto static metric 32650
2607:f8b0:400f:800::1004 via fe80::250:daff:fe73:d306 dev eth0 proto static metric 32650
2607:f8b0:400f:800::1012 via fe80::250:daff:fe73:d306 dev eth0 proto static metric 32650
2607:f8b0:400f:801::1012 via fe80::250:daff:fe73:d306 dev eth0 proto static metric 32650
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::250:daff:fe73:d306 dev eth0 proto static metric 1
default via fe80::250:daff:fe73:d306 dev eth0 proto kernel metric 1024
Is that normal for the routing to go to the gateway's link-local address?
Here's the IPV6 routing table on the gateway:
2001:470:c:51c::1 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
2001:470:c:51c::1 dev he-ipv6 metric 1024 mtu 1480 advmss 1420 hoplimit 0
2001:470:c:51c::/64 via :: dev he-ipv6 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
fe80::/64 via :: dev he-ipv6 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
default via 2001:470:c:51c::1 dev he-ipv6 metric 1024 mtu 1480 advmss 1420 hoplimit 0
/etc/network/interfaces on the gateway:
auto lo he-ipv6 eth1
iface lo inet loopback
iface eth1 inet6 static
address 2001:470:d:51c::1
netmask 64
iface eth1 inet static
address 192.168.1.1
netmask 255.255.255.0
iface he-ipv6 inet6 v4tunnel
address 2001:470:c:51c::2
netmask 64
endpoint 66.220.18.42
ttl 255
gateway 2001:470:c:51c::1
dns-nameservers 2001:470:20::2 74.82.42.42
# The primary network interface
allow-hotplug eth0
#NetworkManager#iface eth0 inet dhcp
And my radvd.conf:
interface eth1
{
AdvSendAdvert on;
prefix 2001:470:d:51c::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
RDNSS 2001:470:20::2 { # I have 2 DNS servers
# I have no options to add here
};
route ::/0 {
};
};
I may have missed it, but I'm not sure where 2001:470:0:63::2 is coming from? Your RADVD config doesn't mention 2001:470:0:63::/64 (so I don't know how your client is getting that address) and I don't see a routing entry for it anywhere on your gateway machine.
I have no idea where 2001:470:0:63::2 comes from. The routing table on the client was generated automatically after getting the address from radvd. One would think that it would use an address that appears somewhere in the gateway's configuration, but I don't see that anywhere.
John
On further investigation it appears that 2001:470:0:63::2 belongs to tunnelbroker.net.
Ok, so I tried adding a new gateway rule to my routing table with
sudo route -6 add ::/ gw 2001:470:d:51c::1
That didn't seem to work. Is there any manual out there that explains what a correct routing table for this situation should look like? Or a tool to find out whether the packets are making it to the gateway?
John
Well, if it were me, I'd figure out where that bogus address is coming from...is it out of your /48 that HE allocated to you?
The address resolves to tunnelbroker.net (and it's the only address belonging to tunnelbroker.net). I don't know how it ended up in the client's routing table as it doesn't appear anywhere in the gateway's configuration. Is there some tool I might use to figure that out?
It appears that my client is adding stuff to its routing table every time I attempt to connect out. That's how the tunnelbroker.net address got there... it was simply one of the hosts I tried to connect to.
Here's what my routing table looks like when the client's network interface first comes up:
2001:470:d:51c::/64 dev eth0 proto kernel metric 256 expires 86402sec
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::250:daff:fe73:d306 dev eth0 proto static metric 1
default via fe80::250:daff:fe73:d306 dev eth0 proto kernel metric 1024
This still begs the question...why is everything going to link-local, and how can I determine whether the traffic makes it to the gateway?
John
Yes, when a client PC is autoconfiguring IPv6 with RADVD, then the client's default GW is the link-local address of the upstream router's LAN facing interface that you configured RADVD for. If it is autoconfiguring but cannot get out beyond the LAN, then make certain you have an IPv6 address from the /64 you configured with RADVD on the LAN facing interface.
iface eth1 inet6 static
address 2001:470:d:51c::1
netmask 64
Make certain that on reboot, that IP is actually on the interface.
Only reason I can think of that you ended up with an HE website IP in your routing table, is because you tried connecting to the website.
On further investigation I realized that the gateway was trying to route traffic out the the HE server, which naturally sent it back to the gateway since the destination address was on my network. When I looked in my /etc/network/interfaces file I found that the IPV6 address of the gateway's "inside" interface was set to the address of the HE server. Correcting that address fixed the problem. The real puzzle is how it ever worked before with that setting...
And cholzhauer, thanks for your help!
John