IPv6 peer-to-peer link

This forum is for admins who are looking to build or expand their OpenVPN setup.

Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech

Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
Post Reply
PMc
OpenVpn Newbie
Posts: 11
Joined: Sat Jun 18, 2022 10:09 pm

IPv6 peer-to-peer link

Post by PMc » Sat Jun 18, 2022 11:14 pm

Hi all,

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
It can be the same address in every configuration, even multiple on the same machine - because it's a linklocal and the kernel will make it scoped: on the interface you get this

Code: Select all

tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1403
        inet6 fe80::1%tun1 prefixlen 124 scopeid 0x5
Obviousely on the peer the two addresses must be swapped - and then you route your payload simply against these adresses (with the scoping), i.e. the nexthop here is fe80::2%tun1.

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
Example:

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
The linklocals get configured onto the tun device, they are only needed for openvpn, and they are only needed so you can say on Site 1: route everything destined for 192.168.7.8 to the nexthop 10.1.0.2 Because these are the only addresses that span the same network on both sides, so otherwise there would be no means to route anything into the tunnel.

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.

TinCanTech
OpenVPN Protagonist
Posts: 11137
Joined: Fri Jun 03, 2016 1:17 pm

Re: IPv6 peer-to-peer link

Post by TinCanTech » Sun Jun 19, 2022 12:26 am

Test what happens if you try to connect to a device on either side of the VPN, other than the server and client machines ?

PMc
OpenVpn Newbie
Posts: 11
Joined: Sat Jun 18, 2022 10:09 pm

Re: IPv6 peer-to-peer link

Post by PMc » Sun Jun 19, 2022 11:00 am

Just switched Central Backup to IP6, it uses all the maintenance tunnels.

Post Reply