# LAN IPv6 only routes out after boxes ping the router?

## bssteph

I've come across a weird problem in getting IPv6 setup in my home. First, IPv4 NAT works perfectly, as does my Hurricane Electric IPv6 tunnel on the router box.

I followed the IPv6 router guide at http://www.gentoo.org/doc/en/ipv6.xml (skipping the DNS portion), using radvd for stateless configuration. This is where I started going off the guide to get things to work.

My tunnel address is 2001:470:aaaa:bbbb:dead:ce11:5010:ba55/64. It never seemed like my internal interface, eth1, obtained an IPv6 address, so I assigned the following to it in config_eth1: 2001:470:aaaa:bbbb::10/64. With that in place, and radvd doing its thing, the boxes on the LAN can ping6 each other, and the internal boxes can reach IPv6 hosts on the Internet. Everything seems hunky dorey.

But, when I reboot an internal machine, it comes up with an IPv6 address, but doesn't seem to know how to route IPv6 traffic through the router, until I ping the router's internal IPv6 address, and then it works. Any guesses as to what I did or what I should fix? I'll of course post route output and such, if people need it.

----------

## salahx

It could the act of pinging cause the destination to spit back an ICMP Redirect packet. Check the routing tables on the internal machine both before and after the ping.

----------

## bssteph

Here's a "log" of the problem, with route -6 output:

```
lightning ~ # /etc/init.d/net.wlan0 restart

 * Stopping sshd ...                                                                                                             [ ok ]

 * Unmounting NFS filesystems ...                                                                                                [ ok ]

 * Unmounting network filesystems ...                                                                                            [ ok ]

 * Bringing down interface wlan0

 *   Stopping dhcpcd on wlan0 ...                                                                                                [ ok ]

 *   Stopping wpa_cli on wlan0 ...                                                                                               [ ok ]

 *   Stopping wpa_supplicant on wlan0 ...                                                                                        [ ok ]

 * Bringing up interface wlan0

 *   Starting wpa_supplicant on wlan0 ...                                                                                        [ ok ]

 *   Starting wpa_cli on wlan0 ...                                                                                               [ ok ]

 *   Backgrounding ... ...

 * WARNING: net.wlan0 has started, but is inactive

 * WARNING: netmount is scheduled to started when net.wlan0 has started

 * WARNING: nfsmount is scheduled to started when net.wlan0 has started

 * WARNING: sshd is scheduled to started when net.wlan0 has started

lightning ~ # ifconfig wlan0

wlan0     Link encap:Ethernet  HWaddr 1c:4b:d6:fc:15:98

          inet addr:10.0.0.156  Bcast:10.0.0.255  Mask:255.255.255.0

          inet6 addr: 2001:470:1f11:81e:1e4b:d6ff:fefc:1598/64 Scope:Global

          inet6 addr: fe80::1e4b:d6ff:fefc:1598/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:24008 errors:0 dropped:0 overruns:0 frame:0

          TX packets:21417 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:13725585 (13.0 MiB)  TX bytes:3153872 (3.0 MiB)

lightning ~ # ping6 -n -c 3 ayu.incorporeal.org

PING ayu.incorporeal.org(2001:470:1f07:fa2:d153:a53d:f4c3:b33f) 56 data bytes

--- ayu.incorporeal.org ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 1999ms

lightning ~ # route -6

Kernel IPv6 routing table

Destination                    Next Hop                   Flag Met Ref Use If

2001:470:1f11:81e::/64         ::                         UAe  256 0     0 wlan0

fe80::/64                      ::                         U    256 0     0 wlan0

::/0                           fe80::224:1dff:fe80:245e   UGDAe 1024 0     5 wlan0

::/0                           ::                         U    2003 0     0 wlan0

::/0                           ::                         !n   -1  1   208 lo

::1/128                        ::                         Un   0   1    19 lo

2001:470:1f11:81e:1e4b:d6ff:fefc:1598/128 ::                         Un   0   1     0 lo

fe80::1e4b:d6ff:fefc:1598/128  ::                         Un   0   1     2 lo

ff00::/8                       ::                         U    256 0     0 wlan0

::/0                           ::                         !n   -1  1   208 lo

lightning ~ # ping6 -c 3 2001:470:1f11:81e:dead:face:0:10

PING 2001:470:1f11:81e:dead:face:0:10(2001:470:1f11:81e:dead:face:0:10) 56 data bytes

From 2001:470:1f11:81e:1e4b:d6ff:fefc:1598 icmp_seq=1 Destination unreachable: Address unreachable

From 2001:470:1f11:81e:1e4b:d6ff:fefc:1598 icmp_seq=2 Destination unreachable: Address unreachable

From 2001:470:1f11:81e:1e4b:d6ff:fefc:1598 icmp_seq=3 Destination unreachable: Address unreachable

--- 2001:470:1f11:81e:dead:face:0:10 ping statistics ---

3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms

lightning ~ # ping6 -c 3 2001:470:1f11:81e::10

PING 2001:470:1f11:81e::10(2001:470:1f11:81e::10) 56 data bytes

64 bytes from 2001:470:1f11:81e::10: icmp_seq=1 ttl=64 time=3.66 ms

64 bytes from 2001:470:1f11:81e::10: icmp_seq=2 ttl=64 time=1.71 ms

64 bytes from 2001:470:1f11:81e::10: icmp_seq=3 ttl=64 time=1.51 ms

--- 2001:470:1f11:81e::10 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2003ms

rtt min/avg/max/mdev = 1.514/2.296/3.662/0.969 ms

lightning ~ # ping6 -n -c 3 ayu.incorporeal.org

PING ayu.incorporeal.org(2001:470:1f07:fa2:d153:a53d:f4c3:b33f) 56 data bytes

64 bytes from 2001:470:1f07:fa2:d153:a53d:f4c3:b33f: icmp_seq=1 ttl=59 time=47.7 ms

64 bytes from 2001:470:1f07:fa2:d153:a53d:f4c3:b33f: icmp_seq=2 ttl=59 time=47.7 ms

64 bytes from 2001:470:1f07:fa2:d153:a53d:f4c3:b33f: icmp_seq=3 ttl=59 time=46.7 ms

--- ayu.incorporeal.org ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2003ms

rtt min/avg/max/mdev = 46.724/47.389/47.737/0.533 ms

lightning ~ # route -6

Kernel IPv6 routing table

Destination                    Next Hop                   Flag Met Ref Use If

2001:470:1f11:81e::/64         ::                         UAe  256 0     0 wlan0

fe80::/64                      ::                         U    256 0     0 wlan0

::/0                           fe80::224:1dff:fe80:245e   UGDAe 1024 0     9 wlan0

::/0                           ::                         U    2003 0     0 wlan0

::/0                           ::                         !n   -1  1   220 lo

::1/128                        ::                         Un   0   1    19 lo

2001:470:1f11:81e:1e4b:d6ff:fefc:1598/128 ::                         Un   0   1    17 lo

fe80::1e4b:d6ff:fefc:1598/128  ::                         Un   0   1     3 lo

ff00::/8                       ::                         U    256 0     0 wlan0

::/0                           ::                         !n   -1  1   220 lo

lightning ~ #

```

The tables don't seem to have changed, but they definitely don't seem right to me, either. I'm guessing the duplicate ::/0 routes are screwing things up somehow. This is my "learn about IPv6" project, so whether any of this seems abnormal is unknown to me. While I'm at it, here's the routing table on the router box:

```
cid ~ # route -6

Kernel IPv6 routing table

Destination                    Next Hop                   Flag Met Ref Use If

::1/128                        ::                         Un   0   1   288 lo

2001:470:1f10:81e::/128        ::                         Un   0   1     0 lo

2001:470:1f10:81e::2/128       ::                         Un   0   1     0 lo

2001:470:1f10:81e::/64         ::                         Un   256 0     0 he6

2001:470:1f11:81e::/128        ::                         Un   0   1     0 lo

2001:470:1f11:81e::/128        ::                         Un   0   1     0 lo

2001:470:1f11:81e::10/128      ::                         Un   0   1   105 lo

2001:470:1f11:81e:dead:ce11:5010:ba55/128 ::                         Un   0   1  7135 lo

2001:470:1f11:81e::/64         ::                         Un   256 0  6928 he6

2001:470:1f11:81e::/64         ::                         U    256 0     0 eth1

fe80::/128                     ::                         Un   0   1     0 lo

fe80::/128                     ::                         Un   0   1     0 lo

fe80::602a:2ba7/128            ::                         Un   0   1   405 lo

fe80::224:1dff:fe80:245e/128   ::                         Un   0   1   971 lo

fe80::6ef0:49ff:fe0a:c1e/128   ::                         Un   0   1     0 lo

fe80::/64                      ::                         U    256 0     0 eth0

fe80::/64                      ::                         Un   256 0     0 he6

fe80::/64                      ::                         U    256 0     0 eth1

ff00::/8                       ::                         U    256 0     0 eth0

ff00::/8                       ::                         U    256 0     0 he6

ff00::/8                       ::                         U    256 0     0 eth1

::/0                           ::                         U    1   0     0 he6

::/0                           ::                         !n   -1  1     1 lo
```

And along the lines of route "confusion", here's something else I thought was odd:

```
lightning ~ # ip -6 ro get 2001:470:1f07:fa2:d153:a53d:f4c3:b33f

2001:470:1f07:fa2:d153:a53d:f4c3:b33f via fe80::224:1dff:fe80:245e dev wlan0  proto kernel  src 2001:470:1f11:81e:1e4b:d6ff:fefc:1598  metric 1024  expires 802sec mtu 1280 advmss 1220 hoplimit 64
```

Again, leaning on what I know about IPv4, shouldn't that be via the router box's internal IPv6 IP?

----------

## bssteph

Hmm. Additional symptom, I thought this was more stable yesterday, but right now, I have to ping6 the router's internal IPv6 every now and then, or I lose the ability to reach the IPv6 Internet --- SSH sessions stop responding, I can't connect to IPv6 websites, etc.

----------

## pa4wdh

I've had more or less similar problems, and in my case is was my firewall configuration (ip6tables) which screwed things up.

Here's my ip6tables output for the "eth1-in" tables, the interface that faces my internal network:

```

Chain eth1-in (4 references)

    pkts      bytes target     prot opt in     out     source               destination         

   98133  6673576 ACCEPT     icmpv6    *      *       fe80::/10            fe80::/10           

     636    37920 ACCEPT     icmpv6    *      *       fe80::/10            ff02::/16           

   35022  2521584 ACCEPT     icmpv6    *      *       fe80::/10            2001:888:120a::/96  

   59807  3827736 ACCEPT     icmpv6    *      *       2001:888:120a::/96   fe80::/10           

       9      648 ACCEPT     icmpv6    *      *       2001:888:120a::/96   ff02::/16           

    1422   152208 ACCEPT     icmpv6    *      *       2001:888:120a::/96   2001:888:120a::/96  

  729755 77182633 ACCEPT     all      *      *       2001:888:120a::/48   ::/0                

     288    23040 DROP       all      *      *       ::/0                 ::/0 

```

2001:888:120a::/96 is the subnet of global addresses i use on my internal interface, 2001:888:120a::/48 is my complete globalscope range.

One of the main differences between IPv4 and IPv6 is that ARP has been replaced by some ICMP messages. Those get send out with the link-local address, if you block those you'll effectively screw up any kind of communication (until they learn each others address by means of the ping to the global scope address of your router). Now in iptables (for IPv4) you didn't have to allow ARP, but in IPv6 you'll have to allow some ICMP messages.

----------

## bssteph

Ah, the ICMP distinction could be it. I'll have to play around with Shorewall later.

----------

## Ant P.

if you do `ip addr` it should tell you how long the radvd leases are valid for. If those numbers aren't getting refilled every few seconds then it's almost certainly an ICMPv6 problem.

----------

## bssteph

If it's an ICMPv6 problem, I can't find it. I should be allowing all internally (ipv6-icmp in the Shorewall vernacular), but I didn't see the radvd lease renew "every few seconds". But, on the other hand, I watched wireshark on both internal interfaces send/receive the ICMPv6 pings and router advertisements, and there was nothing to indicate Shorewall was blocking any traffic. I even did a 'shorewall6 clear' somewhere in there. So, I'm stumped again.

----------

## Ant P.

Make sure /proc/sys/net/ipv6/conf/*/accept_ra are enabled too.

----------

## 222697

Same here, after doing a deep upgrade, maybe one or two weeks ago. Before the upgrade it went all well. Now I have to ping the default ipv6 gateway address, only then it works.

```
# find /proc/sys/net/ipv6/conf -name "*accept_ra" -exec cat {} \;

1

1

1

1

1

1

1

1

1

```

```

# ip6tables-save

:INPUT DROP [0:0]

:FORWARD DROP [0:0]

:OUTPUT ACCEPT [1648:472264]

:sshguard - [0:0]

-A INPUT -m rt --rt-type 0 -j REJECT --reject-with icmp6-port-unreachable 

-A INPUT -i lo -j ACCEPT 

-A INPUT -i eth0 -j ACCEPT 

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 

-A INPUT -p ipv6-icmp -j ACCEPT 

[...]

-A FORWARD -p ipv6-icmp -j ACCEPT

[...]

```

----------

## colp

```

cid ~ # route -6

2001:470:1f10:81e::/64         ::                         Un   256 0     0 he6

2001:470:1f11:81e::/64         ::                         Un   256 0  6928 he6

2001:470:1f11:81e::/64         ::                         U    256 0     0 eth1

```

You appear to have a double entry for your internal network addresses.

----------

## 222697

Also doing ping6 www.tunnelbroker.net every 10 minutes does not help for me anymore. After 24h provider disconnection I do not have ipv6 connection anymore. I cannot ping6 the ::2/64 endpoint of the tunnel. For me it seems to have something to do with the internal interface/routing/tunnel handling of the gentoo os. the ppp-ip-up script for updating the ipv4 tunnel endpoint for the dynamic ipv4 address runs as usual. Help appreciated.

----------

## colp

I suspect the same address block has been used to set up the tunnel as well as internal machines.

You should have been allocated two blocks, one for the tunnel, another for your internal machines.

Here's how I set up my router, take special note to the c (tunnel endpoints) &  d (internal routed prefixes) in the addresses.

```
/etc/conf.d/net

config_eth0=( "192.168.2.1/24" "2001:470:d:xxxx::1/64" )

iptunnel_ipv6="mode sit remote 66.220.18.42 local xxx.xxx.xxx.xxx ttl 255 dev eth1"

mtu_ipv6=1280

config_ipv6="2001:470:c:xxxx::2/64"

routes_ipv6="default via 2001:470:c:xxxx::1"
```

```
/etc/radvd.conf

interface eth0

{

        AdvSendAdvert on;

        AdvLinkMTU 1280;

        MaxRtrAdvInterval 300;

        prefix 2001:470:d:xxxx::/64

        {

                AdvOnLink on;

                AdvAutonomous on;

        };

};
```

----------

## 222697

Thanks colp,

I have the same configuration as You, but since last upgrade it runs unstable now. Sometime connection is there, sometimes not. After 24h ipv4 ppp-reconnection it gets reanimated _sometimes_, now i just rebootet the machine and there is no ipv6 connectivity.

----------

## colp

Sorry I'm using 6in4 not pptp.

According to HE's website pptp is "Temporarily suspended pending debugging and improvements."

----------

## colp

I just reread your reply.

Do you have a ppp link to your ISP?

Can you now do a "/etc/init.d/net.ipv6 restart" to bring up the tunnel?

Maybe you need the ppp link established first before the ipv6 tunnel.

Perhaps you need someting like "depend_ipv6() {  need net.ppp0 }" in /etc/conf.d/net.

Other than that I'm out of ideas.

----------

## 222697

Thank You colp for the idea.

 *colp wrote:*   

> Perhaps you need someting like "depend_ipv6() {  need net.ppp0 }" in /etc/conf.d/net

 

Yes, I have ppp0 on eth1.7 (Telecom VDSL VLAN Tagging)

I did add it and rebooted, but it did not help.

I had also 

RC_need_he6="net.eth0";

before

(eth0 is my LAN interface)

Here is my /etc/conf.d/net

(addresses are not real)

```

routes_lo=( "2001:470:1f1b:2958::1/64" )

config_eth0=( "192.168.1.1/24" "2001:470:1f1b:2958::1/64" )

config_eth1=( null ) 

config_ppp0=( "ppp" )

link_ppp0="eth1.7" 

plugins_ppp0=( "pppoe" )

username_ppp0='myaccount'

password_ppp0='mypassword'

pppd_ppp0=(

    "noauth"

    "defaultroute"

    "holdoff 3"

    "child-timeout 60"

    "lcp-echo-interval 15"

    "lcp-echo-failure 3"

    noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp

)

depend_ppp0() {

    need net.eth1

}

vlans_eth1="7"

config_eth1_7=( null )

##########################

# he tunnel broker

##########################

modules_he6="iproute2";

RC_NEED_he6="net.eth0";

depend_he6() {

    need net.ppp0

}

iptunnel_he6="mode sit remote 216.66.x.x local 192.168.1.1 ttl 255 dev eth1";

mtu_he6=1280;

config_he6=( "2001:470:1f1a:2958::2/64" );

routes_he6=( "default via 2001:470:1f1a:2958::1 dev he6" );

#routes_he6=( "::/0" );

```

----------

## colp

```

iptunnel_he6="mode sit remote 216.66.x.x local 192.168.1.1 ttl 255 dev eth1";

```

You need 

```

 iptunnel_he6="mode sit remote <HE server address> local <routers wan address> ttl 255 dev eth1";

```

And it must match what is configured at HE.

----------

## colp

oops forgot probably "dev ppp0"

----------

## 222697

Yes, thanks, a

```
ip tunnel change he6 local <router wan ip> dev ppp0
```

did it.

Id did the trick with the LAN IP address as local sit tunnel endpoint to avoid the need of updating the tunnel. In the past the trick worked.

----------

