Suport for IPv6

[sorin-silaghi]

Any chance we could get support for IPv6 in the config process? My ISP only provides IPv6 and I haven't been able to get the VPN to work yet.

[redfast00]

We don't have that yet, but that's a really good question. For now: do the install, and then afterwards edit the config files as described in https://community.openvpn.net/openvpn/wiki/IPv6 @0-kaladin: this is something we will need to do

[redfast00]

Change proto udp into proto udp6

[coolapso]

@nellsavedra if you think this is mandatory, just make a pull request yourself!

sorry if I am being quite rude, but there's no such thing as mandatory and priority around here.
this is mainly maintained with @0-kaladin and @redfast00 free time, and more recently by me, and I am also with a big lack of free time since I just changed job and country.

so if you think this is URGENT, well do it and make a pull request, otherwise, you will have to wait until we have time for that!

I am sorry.

[eiGelbGeek]

You only have to change one line in server.conf!
tcp to tcp6 or from upd to udp6!
In your client configurations, you just have to replace your IPv4 with your IPv6!
Also change udp -> udp6 / tcp -> tcp6

If i find some time i create a pull request ... one little pull request is done ... that fixed the stats ...
A IPv6 is simply longer than a IPv4 :-)

[coolapso]

Considering: #619
@orazioedoardo @devZer0

Shall we disable IPv6 until we support setup for it?
actually, I don't think it will solve the issue as the connection probably falls back to IPv6 on the client side of things ...
As i don't have IPv6 can't really test this ... any comments?

[mwoolweaver]

i actually just disabled ipv6 on my windows machine and everything works as it should. I know this isn't the preferred option but it works for me.

My ISP is Comcast and the router hands out ipv6 by default but it will do ipv4 as a fallback.

[coolapso]

That's the only doubt I have .. if disabling IPv6 on the server side will be enough to fix the issue ... but I expect that the client will eventually fall back to IPv6 if its enable on clientside thus bypassing the VPN and leaking the IPv6

[mwoolweaver]

I honestly think it client depended as my Asus router && Android phone do not have this issue and neither leak ipv6 DNS to my knowledge.

I have tested with all sorts dns leak testing sites. And seen 0 positive results in that area.

[mwoolweaver]

It's possible to enable ipv6 networking over VPN, correct? If that's the case then it wouldn't fallback as long as blocking outside dns still happened? Im not completely sure the commands to setup and test a dual stack config are or I would test them

[MichaIng]

Not 100% sure how OpenVPN handles it, but in WireGuard, if one does not enable IPv6 forwarding on the server, there are two possible issues if the client supports IPv6:

• You force ::1 IPv6 route through the VPN on the client, then IPv6 connections simply hang.
• You do not force IPv6 through VPN, then those will bypass the VPN, so inexperienced users will never know if they have a private connection up or not, being an in-acceptable case.
• So either all clients need to disable IPv6 (and this is not always possible, e.g. in case or Android and other restrictive OS), or IPv6 forwarding/handling needs to be enabled on the server to have an acceptable situation.

As said not sure how this is/can be handled with OpenVPN. If there is a way to force IPv6 to IPv4 fallback silently without any hang, then this is probably the easiest solution for now.

Of course all this applies for DNS requests as well.

[ovz93br43v7]

You only have to change one line in server.conf!
tcp to tcp6 or from upd to udp6!
In your client configurations, you just have to replace your IPv4 with your IPv6!
Also change udp -> udp6 / tcp -> tcp6

If i find some time i create a pull request ... one little pull request is done ... that fixed the stats ...
A IPv6 is simply longer than a IPv4 :-)

Is this explanation valid for openvpn or wireguard? If it is for openvpn, can you describe what I have to do in wireguard to enable the IPv6 support? Reason: I read that some hotels provide only IPv6 WLAN, then I assume the current configuration will not work?

[MichaIng]

tcp to tcp6 or from upd to udp6!

This is for OpenVPN, although don't ask me about the details 😉.

For WireGuard:

• Assure that the server can connect to IPv6 hosts, e.g.: ping -6 dns9.quad9.net
• Server-side, enable forwarding for IPv6 separately and assure that the server accepts IPv6 router advertisements even that it acts as router for the VPN itself (accept_ra=2):

  PostUp = sysctl net.ipv6.conf.eth0.accept_ra=2
  PostUp = sysctl net.ipv6.conf.%i.forwarding=1 net.ipv6.conf.eth0.forwarding=1
  PostUp = ip6tables -A FORWARD -i %i -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  PostDown = ip6tables -D FORWARD -i %i -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
  

  • Forwarding rules be applied via nftables (or bpfilter?) as well, depending on machine and kernel capabilities + available userspace firewall frontends.
  • Replace eth0 with the actual network interface for outgoing requests on the server.
• Client-side force IPv6 requests to be done through the VPN as well separately:

  AllowedIPs = 0.0.0.0/0, ::/0
  

[ovz93br43v7]

Thanks for your fast answer!
Just to be sure to understand everything:

* Assure that the server can connect to IPv6 hosts, e.g.: `ping -6 dns9.quad9.net`

Ok I have tired this on my raspberry pi, result:
PING dns9.quad9.net(2620:fe::9) 56 data bytes 64 bytes from 2620:fe::9: icmp_seq=1 ttl=58 time=14.2 ms
I would assume this is ok because "2620:fe::9" looks like a IPv6 address.

This 4 lines has to be added to iptables (this is installed on raspbian) and modified according to my eth0 interface?:

* **Server-side**, enable forwarding for IPv6 separately and assure that the server accepts IPv6 router advertisements even that it acts as router for the VPN itself (`accept_ra=2`):

.....

As far as I understand this was already added by pivpn during setup, I can see this in my client configuration details:

* **Client-side** force IPv6 requests to be done through the VPN as well separately:
  ```
  AllowedIPs = 0.0.0.0/0, ::/0
  ```

[MichaIng]

This 4 lines has to be added to iptables (this is installed on raspbian) and modified according to my eth0 interface?

The 4 lines have to be added to your WireGuard server config /etc/wireguard/wg0.conf to the [Interface] block. So on startup via wg-quick service, iptables is called automatically to establish the forwarding rules.

As far as I understand this was already added by pivpn during setup, I can see this in my client configuration details:

Ah yes, I should have checked what PiVPN actually adds 😄.

[ovz93br43v7]

@MichaIng Thanks again for your fast answer, fantastic support!
I have added the four lines to the wg0.conf file and tested with ipv6-test.com whether IPv6 support is detected using wireguard VPN on my smartphone. But it still shows IPv6 not supported.

  * Replace `eth0` with the actual network interface for outgoing requests on the server.

My RPi is connected with a ethernet cable and is using just ethernet connection, so I left eth0 in the four lines. Or is the "interface for outgoing requsts on the server" the wiregurard (wg0) interface?!?

[ovz93br43v7]

@btb23 thanks for sharing your solution. I have now found the time to try that on my pi. In my first trails I had no success.
Issues on my side after trying to transfer your solution into my configuration:

1. Not really a problem but confusing: ip a shows on eth0 two IPv6 addresses.
2. wg show shows me also the configured IPv6 address but all IPv6 tests are not successful. (cellular connection with IPv4 and WiFi with IPv4/6)

Questions regarding your solution:

1. Is this address fd42:42:42::1/64 just random or according to the ULA defined in your router? I have tried both router ULA +1,2,3,4 for the clients and with a random ULA.
2. Why one time /64 and for the peers /128? (I tried both: /64 for all, /128 only for clients)
3. Have you activated port forwarding for IPv4 and IPv6 in your router?
4. Have also changed something at your clients? I assume that the configuration in the android / iOS app has to be updated or not?

[BakedCrossiant]

is there any plans to add listening on IPv6 as a non-default?

[Dunrar]

I'm a (potential) user of PIVPN with Wireguard from germany. So far, I had no luck getting it to work, though.

My ISP uses DS-Lite, so I can't connect via IPv4 without jumping through some hoops. This seems to be standard practice now, at least in germany. Realistically, this leaves only IPv6 for many if not most.

Luckily, my mobile network provider already provides IPv6. This is not as common yet, but probably will be in the near future. Even so, using the aforementioned changes to the config files and the system, I was not able to get any form of connection to the VPN.

I'll probably follow a tutorial to install Wireguard by hand now, instead of trying to change the pre-configured config files. This will most likely be educational, but I love PIVPNs goal of making the setup and management of VPNs more feasible for many.

Seeing as I would consider mine a fairly standard scenario, I would like to cast my vote in favor of some form of official/optional IPv6 support. Thank you!

[orazioedoardo]

@Dunrar I would do that but I'm unable to test as I do not have access to (multiple) IPv6 networks, don't know about @4s3ti. If someone is willing to make changes and test, why not? We could add support.

[coolapso]

unfortunately I have no reliable way to test IPv6 =/

[MichaIng]

I would be able to run test. I could also open a related PR, but it could take a while until I find time, so would be great if someone else could do that,

A working config for WireGuard has been posted above: #259 (comment)

[Anuskuss]

I can't get this to work, but I'm fortunate enough to have true DualStack, so I atleast have IPv4 going for me. I don't even really understand why I can't use IPv6 through my IPv4 tunnel though. Do I really need two separate connections, one to my public IPv4 and one to my public IPv6 address, just to have support for both types? That's sounds kinda wasteful IMO but I guess that's just how it works. Hopefully PiVPN will sooner than later make this whole process as painless as possible since the world is heading to IPv6.

[MichaIng]

I don't even really understand why I can't use IPv6 through my IPv4 tunnel though. Do I really need two separate connections, one to my public IPv4 and one to my public IPv6 address, just to have support for both types?

The connection to the VPN server is not relevant for the connections passed through the VPN server. So you can without problems connect via IPv4 to the VPN server and then have an IPv6 connection to a remote host tunnelled through it.

If a client is in an environment with IPv6 support and has it not actively disabled, it likely has a GUA IPv6 address as well and will in most cases by default try to connect via IPv6 to hosts if an AAAA record is provided. In this case, you don't want to bypass your VPN ("IPv6 leak"), but want to have that IPv6 request tunnelled as well, and successful instead of hanging. The client VPN config needs to force all IPv6 requests through the tunnel (which is already the case with the default PiVPN client config, if I'm not mistaken) and the VPN server needs to support IPv6, have IPv6 forwarding and NATing enabled, which is covered by the sysctl and iptables6 commands provided above.

[Anuskuss]

@MichaIng Okay good, I didn't really invest too much time because I couldn't even establish a connection to my public IPv6 address (port was open and firewall deactivated for the host) but if this can already work. I'll give it a try tomorrow.
Although I'd like to know this one as well:

Is this address fd42:42:42::1/64 just random or according to the ULA defined in your router? I have tried both router ULA +1,2,3,4 for the clients and with a random ULA.

[MichaIng]

That is the VPN internal IPv6 address, so any address (range) within the fd00::/8 block will work. Of course clients then need to be defined within the same subnet.

I read again through the old posts above, and indeed there seem to be cases where the dedicated/additional IPv6 addresses on the WireGuard network seem to be required. At least worth to test when it's not working without, adding that to server and client configs shouldn't be so hard. I'll also play around with it when I find time.

[Anuskuss]

That is the VPN internal IPv6 address, so any address (range) within the fd00::/8 block will work.

I know that these are ULAs, but I didn't know that any device can just claim one (I though that only the DHCPv6 can). Anyway, I copied btb23's config exactly, but that didn't work for me (I couldn't even ping fd42:42:42::1). It's probably the iptables that are not configured correctly in my setup, but I honestly don't care. I chose PiVPN because I didn't want to deal with this, so let's hope the devs provide a automagical solution 😛

[MichaIng]

I didn't know that any device can just claim one (I though that only the DHCPv6 can).

Well, every device can apply itself any IP (or you can apply any IP to any device). If a DHCPv6 server is present, than the device can ask which ULA it shall apply and respect it, or keep looking for RAs to do SLAAC do something totally different. Not that it would make sense, but it's the devices which apply the IPs themselves and nothing external can strictly force them to do anything 😉.

In case of the VPN, there is no DHCP-ish server, but the client indeed must create the network interface, apply the IP and the routes everything themselves, which is practically done by the wg-quick command/service, respectively the WireGuard client, based on the config you gave them. Then it can try to establish the connection with the server and if IP and key matches to what the server has stored about that client, it is granted.

I cope you kept your private and public key info when applying btb23's configs 😉. To debug, check the WireGuard server logs and whether IP and routes have been applied as expected:

ip a s wg0
ip r l dev wg0
ip -6 r l dev wg0

[Anuskuss]

@MichaIng Appreciate the support, but I don't think just helping me to pull this off is gonna amount to much. Instead you should make it work on your setup first, create a PR and hope to get enough input from the PiVPN community (including me) to get something going that works for everyone :)

[MichaIng]

Well it might help to answer the last open questions before creating the PR. But yes, often having a PR is a more productive basis for testing and discussion. I'll see if I find time, as currently I'm very busy with own projects.

[DerDanilo]

For the project "wg-easy" IPv6 is supported (https://github.com/WeeJeWel/wg-easy/pull/191) and we should be able also bring this to pivpn.
There is a lot of information on IPv6 for pivpn. So what is the current state here? I am happy to contribute but would like to know if the time I might invest will be worth it. If done right, will the PR for IPv6 be merged?

[DerDanilo]

Here we go: #1455

[coolapso]

@DerDanilo I don't see any reason to not merge it ... the main blocker with this so far is because no one really has a way to test and implement it, I am more than glad to review the PR and merge it provided there is no comments, if there is I am sure we can work them out! :)

I Might be able to help testing it, but i am not sure yet.