Routing problems with IPv6 over OpenVPN

Question

I'm trying to set up an OpenVPN server to enable clients to use its IPv6 subnet. The server is running Debian Wheezy, and the client is OS X 10.9.5. Here's the server config:

port 1194
proto udp
dev tun
tun-ipv6
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh1024.pem
server 10.100.100.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
tls-auth ta.key 0
cipher DES-EDE3-CBC
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
server-ipv6 MY:PUBLIC:IPV6:SUBNET::/64
push "route-ipv6 0::/0"

And here's the client config:

client
dev tun
tun-ipv6
proto udp
remote server.address 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
comp-lzo
verb 3
tls-auth ta.key 1
cipher DES-EDE3-CBC

IPv4 connectivity works flawlessly but there are some strange issues with IPv6. The client does obtain an IPv6 address when it connects, but the only thing that responds to pings (or accepts any IPv6 packets for that matter) is the server itself. It looks like the packets that are supposed to go to the global internet are not routed through the appropriate interface on the server which is eth0 in my case. The IPv6 address is assigned to eth0 statically from the subnet provided by my hosting provider and everything works from the server; for example, I can ping ipv6.google.com from it. The net.ipv6.conf.default.forwarding and net.ipv6.conf.all.forwarding sysctl options are also enabled.

Answer 1

So, I figured out that the upstream router won't just simply unconditionally forward packets for my whole allocated subnet to my server. For it to know to forward them, you have to tell it explicitly via the NDP protocol. This has to be done when a client connects and is assigned an IPv6 address. So, long story short, here's how I fixed it. Add this to the OpenVPN config on the server:

script-security 3
client-connect /etc/openvpn/client-connect.sh

Create a script named /etc/openvpn/client-connect.sh with the following contents:

#!/bin/sh
ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0

Restart OpenVPN. Connect to the server and enjoy your very own piece of the future of the internet.

Answer 2

I have been struggling with the same issue and coincidentally on Debian Wheezy as well.

There are two options you might have missed at this moment (on the VPN server):

1. No ip6tables forwarding rules
2. No default IPv6 route

1. ip6tables

As with IPv4, you need explicit firewall forwarding rules, this worked for me:

# ip6tables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
# ip6tables -A FORWARD -i tun0 -o eth0 -j ACCEPT

(adjust the interfaces accordingly, you might want to add -s VPN-IPv6-RANGE/SUBNET to the second rule for more explicit forwarding).

2. default route

This was the problem on my side; took me about two days before someone made me rethink my setup and I found out I missed an essential side effect of forwarding = 1 in sysctl.

When you set net.ipv6.conf.all.forwarding = 1, address autoconfiguration from Router Advertisements are ignored. In other words, when your default route is set through autoconfiguration, this route is dropped fairly fast and you lose IPv6 connectivity to your server. When your default route now is something like default via fe80::..., this is probably the case.

The solution for this is to add an explicit default route through /etc/network/interfaces, such as:

iface eth0 inet6 static
    address 2001:db8::2
    netmask 64
    gateway 2001:db8::1

You can check whether your VPN setup works (temporarily) by looking at the IPv6 routing table on your server: ip -6 route show default and, when its empty, add the default route with ip -6 route add default via 2001:db8::1 (adjust to your local range accordingly). Then check whether your VPN client can ping some external IPv6 address.

OpenVPN config

A small configuration difference on my side is:

• push "route-ipv6 2000::/3" (2000:: up to 3fff:ffff...)

instead of

• push "route-ipv6 0::/0"

but those routes are equivalent at the moment.