Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am trying to set up 6in4 tunnel server on my VPS. Client and server can ping IPv6 address of each other, when I try to ping an outside server from the client, I get ICMP address unreachable error.

But I can ping IPv6 website from the server without problem, and after pinging from server, I am able to ping from client in about 30 seconds, after that I get ICMP address unreachable error again.

tcpdump shows that when pinging from the server, it will send a neighbor solicitation packet using its public IPv6 address, and correctly get neighbor advertisement back from the gateway. But when pinging from the client, the server will send neighbor solicitation packet using its link-local address, and not getting anything back. After a few tries the server will give up and return ICMP address unreachable to the client.

How can I fix this? I know that I can add a permanent neighbor entry to the gateway, but this is quite hacky so I want to avoid it if possible.

Here is some extra information:

  • Server OS: Ubuntu 13.10 Server

  • uname -a: Linux 3.11.0-19-generic #33-Ubuntu SMP Tue Mar 11 18:48:34 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

  • My ISP gave me only a /112 block, so I used npd6 to handle inbound neighbor solicitation packets

  • ip6tables has no entry in INPUT and OUTPUT table

tcpdump (when pinging from server):

18:14:33.988952 IP6 [server's public IPv6 address] > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has [gateway's IPv6 address], length 32
18:14:33.989410 IP6 [gateway's IPv6 address] > [server's public IPv6 address]: ICMP6, neighbor advertisement, tgt is [gateway's IPv6 address], length 32
18:14:33.989428 IP6 [server's public IPv6 address] > google-public-dns-a.google.com: ICMP6, echo request, seq 1, length 64
18:14:34.038299 IP6 google-public-dns-a.google.com > [server's public IPv6 address]: ICMP6, echo reply, seq 1, length 64

tcpdump (when pinging from client, note that fe80::5054:ff:fe3b:3836 is server's link-local address):

18:12:35.284184 IP [client's IPv4 address] > server: IP6 [sit tunnel address (client)] > google-public-dns-a.google.com: ICMP6, echo request, seq 1, length 64
18:12:35.284263 IP6 fe80::5054:ff:fe3b:3836 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has [gateway's IPv6 address], length 32
18:12:36.282458 IP6 fe80::5054:ff:fe3b:3836 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has [gateway's IPv6 address], length 32
18:12:37.282470 IP6 fe80::5054:ff:fe3b:3836 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has [gateway's IPv6 address], length 32
18:12:38.282503 IP server > [client's IPv4 address]: IP6 [sit tunnel address (server)] > [sit tunnel address (client)]: ICMP6, destination unreachable, unreachable address google-public-dns-a.google.com, length 112

After pinging from client, output of ip neigh on server looks like this (irrelevant entries removed):

[gateway's IPv6 address] dev eth0  router FAILED

ip addr and ip -6 route (addresses are anonymized):

.. snipped ..
2: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
    inet .. snipped .. scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:aa:b::cccc:1/48 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe3b:3836/64 scope link 
       valid_lft forever preferred_lft forever

9: sit: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1472 qdisc noqueue state UNKNOWN 
    link/sit .. snipped .. peer 1.2.3.4
    inet6 2001:db8:aa:b::cccc:8001/120 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::dafb:71de/128 scope link 
       valid_lft forever preferred_lft forever

::1.2.3.4 dev sit  metric 1024 
2001:db8:aa:b::cccc:8000/120 dev sit  proto kernel  metric 256
2001:db8:aa::/48 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via 2001:db8:aa::1 dev eth0  metric 1024 
share|improve this question

1 Answer 1

This setup is fundamentally broken. You will need lots of hacks like static routes, proxy-NDP etc to make it work. There are no pretty solutions here...

Now, how it should be done is:

  • The ISP gives you a /48 of IPv6 address space
  • Every LAN is a /64
  • Your server(s) are on a /64 directly connected to the ISP
  • Your ISP provides you a way to route prefixes to your server(s)
    • static routing is common at the ISPs that I know
    • DHCPv6-PD with long stable leases might solve it as well
share|improve this answer
    
He only has a VPS, this seems to be common with low-end VPS providers. –  Michael Hampton Apr 16 at 12:30
    
Yes, the VPS provider only offers /112.. Maybe I will have to resort to manually setting neighbor entry. –  SAPikachu Apr 16 at 13:40
    
Sorry to hear that :( –  Sander Steffann Apr 16 at 15:34
1  
Due to some ND implementations being vulnerable to DoS attacks it is sometimes advised to allocate a /64 for a link, but only configure part of it which could be a /112 or even a /126 or /127. However they still ought to route at least a /60 to each VPS. But not all providers do so. –  kasperd May 15 at 0:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.