Setting OpenVPN dual stack (IPv4 +IPv6)

[adroman]

do you see any traffic on tun0 on the server? If you see the ICMP ECHO requests, but you see no reply, then most likely the server is not forwarding the traffic.

No ICMP traffic while pinging google address

[adroman]

do you see any traffic on tun0 on the server? If you see the ICMP ECHO requests, but you see no reply, then most likely the server is not forwarding the traffic.

No ICMP traffic while pinging Google address

[ordex]

You should filter for "icmp6", not "icmp".

[adroman]

You should filter for "icmp6", not "icmp".

Thank you!
Only requests, no replies.

[ordex]

if you run tcpdump on eth0 you will most likely not see any request going out. Can you confirm?
If that's the case, then it's your firewall blocking the traffic.

[adroman]

if you run tcpdump on eth0 you will most likely not see any request going out. Can you confirm?
If that's the case, then it's your firewall blocking the traffic.

With a great pleasure!
Only Neighbor Solicitation (NS)


I keep getting them even if I don't ping anything

[ordex]

wait, if you look through the lines, there is a ICMP6 request every now and then! So they *are* being forwarded.

But the neighbour solicitation tells you what is happening: your ISP router expects the address 2a05:8280:f:43aa:aaaa::1000 to be onlink, but it is not (because it is behind the VPN).
This means the ISP is *not* routing the /64 to your server, but they have simply assigned it to the link with your router. So your router can add as many addresses to eth0, but they cannot be simply routed over other links (like the VPN).

There are two options:
1) ask your ISP to *route* an additional /64 (sometimes they assign them via DHCPv6-PD);
2) activate NDP proxy on the server so that your server will reply to those NS messages in order to make the ISP happy.

While 1) would be the best option, your provider my simply not do it (that'd be bad though).
For option 2) you should enable proxy_ndp on tun0:

sysctl net.ipv6.conf.tun0.proxy_ndp=1

And then it should just work[tm]
If it does not yet work, then I think you need to add a proxy manually:

ip -6 neigh add proxy 2a05:8280:f:43aa:aaaa::1000 dev tun0

[adroman]

There are two options:
1) ask your ISP to *route* an additional /64 (sometimes they assign them via DHCPv6-PD);
2) activate NDP proxy on the server so that your server will reply to those NS messages in order to make the ISP happy.
While 1) would be the best option, your provider my simply not do it (that'd be bad though).
For option 2) you should enable proxy_ndp on tun0:
sysctl net.ipv6.conf.tun0.proxy_ndp=1

And then it should just work[tm]
If it does not yet work, then I think you need to add a proxy manually:
ip -6 neigh add proxy 2a05:8280:f:43aa:aaaa::1000 dev tun0

Option #1 doesn't work, so I tried 2nd option
But unfortunately nothing changed

[ordex]

hmm haven't played with the NDP proxy in a while..maybe you have to enable it on the external interface, so on eth0 instead of tun0?

[adroman]

hmm haven't played with the NDP proxy in a while..maybe you have to enable it on the external interface, so on eth0 instead of tun0?

Thank you so much Sir! The command that works for me is ip -6 neigh add proxy 2a05:8280:f:43aa:aaaa::1000 dev eth0 - but after I reboot my VPS I have to reenter it each time.
Is it possible to somehow configure it automatically for every IPv6 OpenVPN client or maybe for whole subnet?

[adroman]

This is what my ISP said about my network block

[ordex]

cool! glad it works!
This is the limitation of NDP proxy on Linux: it works by single IPs (as far as I recall).
Alternatively, I think you could use a --client-connect script in OpenVPN which may run the ip neigh command automatically. The downside is that you need to clean this up (--client-disconnect ?) but I Am not sure you can reliably do that.

On the other hand, if you don't have many clients, you could still run these series of commands at boot, like in an rc.local.

Regarding what your ISP is saying, I don't know what they really mean with "routable".

[adroman]

cool! glad it works!

Thank you so much!!! I'm really happy despite there's some difficulties with NDP, it's a huge achievement for me and I'm really grateful for you competence, patience and kindness : )

And I also found a nuance, when a second client connects, the same IPv6 address 2a05:8280:f:43aa:aaaa::1000 disappears from the first client and is assigned to the second one. Is it because I have to write specific addresses in ccd?

[ordex]

are you using the same certificate? IF so, that is expected behaviour, because only one client is allowed to connect with a gien cert/common-name.
If you want to still permit that, you have to use --duplicate-cn on the server, but it is NOT recommended.

[adroman]

are you using the same certificate? IF so, that is expected behaviour, because only one client is allowed to connect with a gien cert/common-name.
If you want to still permit that, you have to use --duplicate-cn on the server, but it is NOT recommended.

Thank you very much Sir!
I can’t put into words how valuable was your help and how I’m grateful for it!
The problem was that (as I understood) the OpenVPN requires to provide specific IPv6 settings for each client in ccd if there’re setting for IPv4 already present.
I just added specific IPv6 settings for each ccd file and the problem has gone.
Also (thanks to your suggestion to use scripts for NDP) I was able to setup automatic NDP configuration with Dynamic NDP proxy with OpenVPN hooks.
I added hook in the OpenVPN server conf:
learn-address /etc/openvpn/learn-address
With the following learn-address script:

View Original learn-address script

#!/bin/sh
action="$1"
addr="$2"
case "$action" in
add | update)
ip neigh replace proxy "$addr" dev tun0
;;
delete)
ip neigh del proxy "$addr" dev tun0
;;
esac

And now it works as it should : )
Without You I had zero chances to setup that dual-stack!

[ordex]

cool! I am glad I could help!