OpenVPN gateway does not reply on IPv6 ping, but does forward package

Question

I am trying to debug my IPv6 network and ran into an issue that I can't understand.

I am using OpenVPN as my VPN server and here is a short diagram of the setup:

All packages are dropped, when I try to ping from VPN Client (2001:470:7875:1::2) to VPN Server (2001:470:7875:1::1), but here is the curious thing:

I can ping any other host over IPv6 (like Google) or any other VPN client connecting to the same VPN server over IPv6.

I can also ping my VPN server on its native IPv6 interface (ens3). It is only the VPN server interface (tun0) that does not respond when pinged directly.

Therefore I am wondering what is going on?

Since I have two IPv6 links to the IPv6 version of internet I have todo policy based routing. The rules are pretty simple.

• Only IPv6 packages that originates from VPN server itself are allowed to be sent over the native IPv6 link.
• All other IPv6 packages has to be handled by the Hurricane Electric IPv6 tunnel.

This leads my to the following routing table on the VPN server:

The command ip -6 rule show has the following setup:

0:      from all lookup local
32000:  from 2001:470:7875::/48 lookup openvpn
32766:  from all lookup main

Table local:

local ::1 dev lo proto kernel metric 0 pref medium
anycast 2001:470:1f14:2c7:: dev he-ipv6 proto kernel metric 0 pref medium
local 2001:470:1f14:2c7::2 dev he-ipv6 proto kernel metric 0 pref medium
anycast 2001:470:7875:1:: dev tun0 proto kernel metric 0 pref medium
local 2001:470:7875:1::1 dev tun0 proto kernel metric 0 pref medium
anycast 2a01:xxx:xxxx:: dev ens3 proto kernel metric 0 pref medium
local 2a01:xxx:xxxx:xxx::1 dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev tun0 proto kernel metric 0 pref medium
anycast fe80:: dev he-ipv6 proto kernel metric 0 pref medium
local fe80::95d2:9e6b dev he-ipv6 proto kernel metric 0 pref medium
local fe80::5054:ff:fe66:f97f dev ens3 proto kernel metric 0 pref medium
local fe80::af96:f1e3:dbf3:96a7 dev tun0 proto kernel metric 0 pref medium
ff00::/8 dev ens3 metric 256 pref medium
ff00::/8 dev tun0 metric 256 pref medium
ff00::/8 dev he-ipv6 metric 256 pref medium

Table main:

local ::1 dev lo proto kernel metric 256 pref medium
2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
2xxx:xxx:xxxx::/48 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev he-ipv6 proto kernel metric 256 pref medium
default via 2a01:xxx:xxxx::1 dev ens3 metric 1024 pref medium

Table openvpn:

unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
default via 2001:470:1f14:2c7::1 dev he-ipv6 metric 1024 pref medium

Is there anybody who can clue me in? :-)

---

A quick recap on the unreachable lines in routing table

2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium

The range of 2001:470:7875::/48 is from 2001:470:7875:0:0:0:0:0 to 2001:470:7875:ffff:ffff:ffff:ffff:ffff.

I have assigned the subnet 2001:470:7875:1::/64 to the VPN tunnel.

• 2001:470:7875:1::/64 is part of the 2001:470:7875::/48 subnet, which can leads to a conflict in the routing table.
• 2001:470:1f14:2c7::/64 is not a part of the 2001:470:7875::/48 subnet and therefore does not conflict with routing table.

No other IP range is in use, but will be at a undetermined later date.

Keeping in mind longest prefix wins gives us the following behaviour:

• Any IP packages for 2001:470:1f14:2c7::/64 subnet will be handled by he-ipv6 interface.
• Any IP packages for 2001:470:7875:1::/64 subnet will be handled by tun0 interface.
• All other IP packages for 2001:470:7875::/48 subnet will be replied back with unreachable.

Answer 1

So...

After more digging I found out my setup could be refined a bit, though I am not entirely convinced that I have covered all my bases.

Anyway ip -6 rule show could be tweaked a bit.

the line:

32000:  from 2001:470:7875::/48 lookup openvpn

Was generated by the following command:

ip -6 rule add priority 32000 from 2001:470:7875::/48 table openvpn

This could be simplified to:

ip -6 rule add priority 32000 iif tun0 to 2000::/3 table openvpn

What this means is basically all IPv6 based traffic have to lookup the table openvpn if and only if traffic originates from VPN link and destination address belongs to the 2003::/3, which is basically the whole official IPv6 Internet - excluding local addresses like fe80::/10 and fc::/7.

The end result is that IPv6 traffic from my VPN link is always forwarded over the Hurricane Electric link.

Things to remember. Whenever I add a new subnet from my pool of available adresses in the 2001:470:7875::/48 range I have to make two entries.

• One in the table main, which tells how to forward the package from VPN server the new subnet.
• On in the table openvpn, which tells how the VPN clients can get to the new subnet. This is typically when having site-to-site traffic from one client to another client over the VPN link.

In any case: Ping works now and I can still ping Google over IPv6.

The command ip -6 rule show now gives the following output:

0:      from all lookup local
32000:  from all to 2000::/3 iif tun0 lookup openvpn
32766:  from all lookup main

Everything else is as-is from the initial question.

Traceroute was a bit tricky, but it works as long as is done with ICMP Echo packages.

Running the command traceroute -6 -I google.com on my VPN client gave the following trace:

traceroute to google.com (2a00:1450:400e:80b::200e), 30 hops max, 80 byte packets
 1  2001:470:7875:1::1 (2001:470:7875:1::1)  16.868 ms  37.912 ms  37.847 ms
 2  tunnel547738.tunnel.tserv11.ams1.ipv6.he.net (2001:470:1f14:2c7::1)  37.777 ms  37.710 ms  37.647 ms
 3  10ge11-20.core1.ams1.he.net (2001:470:0:7d::1)  37.575 ms  37.509 ms  37.443 ms
 4  amsix-router.google.com (2001:7f8:1::a501:5169:1)  37.453 ms  52.425 ms  52.392 ms
 5  2001:4860:0:f8d::1 (2001:4860:0:f8d::1)  52.323 ms  52.259 ms  52.189 ms
 6  2001:4860:0:1::219f (2001:4860:0:1::219f)  36.456 ms  25.560 ms  18.169 ms
 7  ams17s01-in-x0e.1e100.net (2a00:1450:400e:80b::200e)  34.566 ms  34.502 ms  34.435 ms