Routing problem on Debian after reboot

[jhaiduce]

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:

Code Select Expand


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:

Code Select Expand


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:

Code Select Expand


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:

Code Select Expand


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:

Code Select Expand


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 {
  };
};


[cholzhauer]

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.

[jhaiduce]

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

[jhaiduce]

On further investigation it appears that 2001:470:0:63::2 belongs to tunnelbroker.net.

[jhaiduce]

Ok, so I tried adding a new gateway rule to my routing table with

Code Select Expand


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

[cholzhauer]

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?

[jhaiduce]

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?

[jhaiduce]

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:

Code Select Expand


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

[broquea]

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.

Code Select Expand

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.

[jhaiduce]

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