I found this paper about configuring IPv6. https://community.openvpn.net/openvpn/wiki/IPv6
I read it, I think I understood it, and I planned to implement it that way. Then I noticed a problem that is not at all related to openVPN, but appeared to be a show-stopper: there is no NAT in IPv6! (I'll explain in a minute, just read on)
Then I evaluated the paper, and found that it, sorry, doesn't make any sense. Why would you need an extra "routed IPv6 network block" (i.e a GU prefix) only for the peer addresses? Why would you bother and split your prefix otherwise? Why bother with that math and all?
IPv6 has provision for linklocals, and these are designed for exactly this purpose! In IPv6 you can route against linklocals - in fact this is the preferred way of routing.
I decided to give it a try and see if it would work. And, to my big surprize and regalement, it immediately did, without any complaints.
So, instead of all the splitting and math, just throw this in every config
Code: Select all
ifconfig-ipv6 fe80::1/124 fe80::2
Code: Select all
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1403
inet6 fe80::1%tun1 prefixlen 124 scopeid 0x5
Now we come to the NAT requirement. Normally, in old-school IPv4, you have three different networks for a tunnel:
- the real addresses that are globally routeable
+ the private addresses that make up the virtual private network
+ and the linklocal addresses which are only needed to route something into the tunnel
Code: Select all
Site 1 Site 2
global 1.2.3.4 5.6.7.8
private 192.168.3.4 192.168.7.8
linklocal 10.1.0.1 10.1.0.2
But now the ugly thing happens: Imagine you sit on Site 1 and open an ssh to Site2 aka 192.168.7.8.
Then this will NOT be a connection between 192.168.3.4 and 192.168.7.8. Instead, the socket will be bound to 10.1.0.1 - because that is the network of the nexthop! (Unless you tell ssh exactly which address it should locally bind.)
Now if this are not only two machines, but dozens, then there will be no means to find the way back to 10.1.0.1 - and you will end up adding these addresses to every configuration: the routing tables, the nameserver, the firewalls, the access control lists, the hosts.allow, the whatever whatever whatever...
So I decided to instead just run a NAT on every tunnel endpoint, that does nothing else than, for local traffic, replace every occurance of 10.1.0.X with the respective private address of the local machine. This is very much in scope of what NAT is designed for, so it works - with the usual caveats of NAT operations. Problem solved, once and for all.
But in IPv6 there is no NAT. However, following the method from the beforementioned paper - while it is usually not a problem to obtain enough subnets/prefixes, this problem will be exactly the same.
But, luckily, the IPv6 linklocals solve this as well, without any effort, because they will just not be used for anything else than routing to the other side, automatically.
So, warm thanks to whoever implemented this support into openVPN!
Strangely, I didn't find a documentation that this works, so I thought I give it a short writeup here.