tunnel 6in4 for router, partial success

Question

My ISP doesn't provide IPv6 addresses to clients (only one IPv4). I have a dedicated server with static IPv4 address and /64 block IPv6, so I decide to be my own tunnel broker (6in4). Yes, I can use tunnerbroker.net but I want to learn how to do it by myself.

Goal: provide 6in4 tunnel from server with native IPv4+IPv6(eth0) connection to clients behind home router with IPv4 only.

What I did:

Server side:

ip tunnel add sit5 mode sit ttl 255 remote [home_router_ipv4] local [server_ipv4]
ip link set dev sit5 up
ip -6 addr add [ipv6]::1/64 dev sit5
ip -6 route add [ipv6]::/64 via [ipv6]::2 dev sit5 metric 1
ip -6 neigh add proxy [ipv6]::2 dev eth0

sysctl:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.proxy_ndp=1
net.ipv4.conf.all.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0
net.ipv4.conf.all.send_redirects=0

Client side:

The router running DD-WRT with native support for 6in4 tunnels with radvd for adresses propagation to clients (tested with success for tunnelbroker.net).

radvd config:

interface br0
{
 IgnoreIfMissing on;
 AdvSendAdvert on;
 MinRtrAdvInterval 3;
 MaxRtrAdvInterval 10;
 AdvHomeAgentFlag off;
 AdvManagedFlag off;
 AdvOtherConfigFlag on;
 AdvLinkMTU 1480;
 prefix [ipv6]::/64
 {
  AdvOnLink on;
  AdvAutonomous on;
 };
 RDNSS [ipv6]::1 2620:0:ccd::2 {};
};

Problem: Router is correctly connected via tunnel to IPv6 network (it can browse ipv6 network), but clients doesn't (they receive correct ipv6 address, but can't ping anything including router and server).

When I am doing a traceroute6 from server to client I have routing loop:

# traceroute6 [ipv6]:4d34:1981:aba6:620c
traceroute to [ipv6]:4d34:1981:aba6:620c ([ipv6]:4d34:1981:aba6:620c) from [ipv6]::1, 30 hops max, 24 byte packets
 1  [ipv6]::2 ([ipv6]::2)  43.446 ms  44.439 ms  39.687 ms
 2  [ipv6]::1 ([ipv6]::1)  41.955 ms  41.391 ms  43.225 ms
 3  [ipv6]::2 ([ipv6]::2)  80.456 ms  80.515 ms  81.893 ms
 4  [ipv6]::1 ([ipv6]::1)  81.966 ms  83.338 ms  92.166 ms
    ...

Answer 1

The first problem is that you used the same subnet in two places – your LAN and the p2p tunnel. While this could perhaps work after some route wrangling, it's really not a good idea.

(Notice how Tunnelbroker allocates you two subnets as well: one /64 purely for the point-to-point link, plus a 'routed' subnet for LAN.)

So if you only have one /64, use it for LAN only. The p2p tunnel will work just fine with link-local addressing (or in fact no addressing at all, due to it being a p2p link).

So instead of these commands...

ip -6 addr add [ipv6]::1/64 dev sit5
ip -6 route add [ipv6]::/64 via [ipv6]::2 dev sit5 metric 1

use something like this:

ip -6 addr add fe80::1/64 dev sit5
ip -6 route add [ipv6]::/64 via fe80::2 dev sit5

or even a completely unnumbered link:

# <no 'addr add' necessary>
ip -6 route add [ipv6]::/64 dev sit5

Of course, configure the home router accordingly – in this example it'd have address fe80::2/64 and use fe80::1 as the gateway.

Note: The above isn't necessarily a complete solution. I have this suspicion that you might be using the same /64 on three links at once (LAN, p2p, and the server's own eth0), which is probably going to need even more bandaids than usual.

---

The second problem is that, as I understood it, your server provider configures the /64 as an on-link subnet, rather than routing it towards the server.

That's a rather annoying (if unfortunately common) problem – on-link means that your server will have to proxy Neighbour Discovery for every single address that your LAN devices use;

So your router itself has Internet access because you used this command:

ip -6 neigh add proxy [ipv6]::2 dev eth0

But you'd have to repeat it for every device, not to mention temporarily generated 'privacy' addresses your PCs might use.

It would be best if your server provider could reconfigure the /64 to be routed towards your server (ask them via email or ticket perhaps) – that'd make ND proxying completely unnecessary.

If that's not possible, you might have to run ndppd for ND-proxying the entire /64.

---

In the end, it might be easier to just rely on Tunnelbroker or NetAssist.