Basic wireguard IPv6 (NAT) support #1455
Conversation
|
Tried it out, log said: I can't get it to connect. Also, shouldn't there be an IPv6 subnet in the Anyway, I'm not even sure how to connect to my Pi at all. Should I use my router's public IPv6 or my Pi's? The |
Thanks for that info! |
|
@DerDanilo not sure if you are local testing before hand, but just want to make sure you please do try some local testing before pushing to the MR, Travis CI has usage limits and even tho they are quite kind in raising them if needed i'd rather avoid it. Once all tests are passing and you feel code is ready to go let me know. |
|
@4s3ti I just launched a clean test machine today to do more testing even though I thought I tested everything already. Found the bug with the missing IPv6dev reference, which is fixed now. The annoying thing with local tests is that the install script will always install the master upstream repo (into pivpnFilesDir="/usr/local/src/pivpn"), which can be changed by hand of course, but the branch then is wrong, since I am not pushing against the fork master obviously. Maybe this can be improved for future testing, allowing providing such option on the CLI via options or maybe just env vars. 'custom_git_repo_url' and 'custom_git_branch' (to checkout after clone). Looking forward to have this fixed. Any help is appreciated. Other question: Can we add an option to disable any script interaction with the firewall at all? I understand that this should be handled by the script for folks that don't work on it otherwise. But it is a valid option to have the script not fiddle with any firewall if the user wishes so. Could be an option in the unattended file and should possible be an additional question in the whiptail dialog. |
|
I am really struggling to find time, barely can find time to anything else other than keep an eye and manage the project. :( @DerDanilo there are ways to test the pipelines locally .. but to be honest .. the easy way is really to just push and look at the build :p if credits go over .. no worries i'll just request more What i usually do is to spin up a cloud instance and try to replicate the build environment and see what happens. I usually use hetzner as my cloud provider for this kind of things, and i've noticed it gets quite close to the build environment, however, but i believe any clean debian system might work.
I am okay with that, considering that we also provide a warning mentioning that we won't provide any (of the few we do) support past that point @orazioedoardo any opinion about this? |
|
@4s3ti I'm ok too with an unattended option to not touch the firewall. @DerDanilo shouldn't you check whether the Pi's network actually supports IPv6?
@Anuskuss You should put the public IPv6 address of the Pi in the Endpoint field of the .conf, and tell the router to allow port 51820 to pass through its firewall (this is not port forwarding, there is no nat involved). |
I actually struggle finding time to. It was a lucky evening where I pushed the IPv6 changes. Does the project contain instructions on how to launch the build env? Could you please push some that devs can use? There is also the issue with iptables being replace by nftables. We could also add support for that. I didn't have to work with that and I think that the whole firewall options should be another PR anyways. (don't touch my FW, update FW rules when running script again and nftables support)
Why? Most people don't fiddle with IPv6 on their system, hence link local addresses are enabled by default. If people do they should know what they are doing. I think that IPv6 should be enabled by default, people refusing not using IPv6 are part of the problem why it's not as far as it could be today. There are few internet connections without IPv6 (outgoing at least), hence statistically this should work most of the time. We could maybe put in an option that allows to disable IPv6 at all, ignoring all IPv6 configuration. But do we really want to do that? < Quote Comments from above >
For the sake of dynamic IPv6 addresses (yes some providers even rotate IPv6 subnets) and that most pis have the 'privacy/private' IPv6 option enabled I skipped that. It is also not required if one wishes to connect to a DNS name which is the best option here. Those can contain dynamic IPs without any config change requirements. With dual stack a DNS name is anyways the best option, if one wishes to use that. So people either put their IP there or put a DNS name. We are opening the required port with the script already. I think that it should be clear that any firewall in front of the server needs editing to make this work. Or did I misunderstand what you are referring to? From travis log: This looks like there is a double reference. Could also just be a display issue. Why don't we run tests with Debian itself? I think that he two latest Ubuntu and Debian releases should be tested. |
I'm planning to do this.
I mean actual IPv6 internet connectivity, a global unicast address and possibly a reachability test.
That comment was a suggestion for the user above, clearly you can't change the router firewall from the Pi, unless UPnP is enabled (I think automatic port forwarding was requested in the past).
Though currently the whiptail prompt has options for the IPv4 address or a domain name. In case IPv6 is supported, there are some options:
Ok, speaking of this, I think the script should ask to set a static IPv6 address too. |
Would you mind including an option to not touch any firewall rules at all in the same PR?
Maybe we can just do a
UPnP is not reliable enough I think. But yes, it could also be an option to add support for that. Please don't make this the default. I suggest you also include this feature in your firewall PR (nftables).
Why put a static IP into the config? All configs have to be updated if any IP was changed. From some reddit post:
AFAIK pivpn doesn't yet support to properly update existing profiles. I am also missing an option to override the "Allowed IPs" var per user. Yes users may simply add the nets their routing through the VPN but we have some cases where changing the list on a per user basis is very useful and avoids editing the config afterwards.
Are you referring to the part where the script will change the servers IP address? In general I think that this should be removed because the user should at least understand how to configure an IP address when going for a VPN. |
Ok.
Should be enough according to my limited knowledge of IPv6.
Which problems could arise by checking for connectivity?
Definitely not default. UPnP is often seen as a security risk so I'm not sure if we want to support such feature, although it would simplify the work for the user.
Yes, but see below too.
Yes, this is quite implicitly requested.
Which one? IPv4, IPv6, or ask the user?
I'm referring to the part of the script that sets the static LAN IP. In the same way, I think it should set a static IPv6 but warn that some ISPs change the prefix from time to time (even if is not recommended by RIPE: https://www.ripe.net/publications/docs/ripe-690). If we are removing tasks that the script has a chance to perform, then the script itself is less useful to the user. |
External firewall rules, simply not required because the admin doesn't want any checks. DNS names being blocked. etc.
Let the user choose, so ask. Suggest IPv4 if in doubt because of the mentioned mobile restrictions. There are also many ISPs not supporting IPv6. (Mine doesn't and there is no way to get IPv6 because it's handled by the city itself. There is no other ISP with decent internet speed here, so I'm stuck and bring IPv6 via WG to my devices. - IPv6 in WG IPv4 tunnel)
If you want to spend time for that okay fine with me. Just please don't let this PR stale forever because nobody finds time to do all of the suggested. We should sort the suggested and split parts into different PRs. This way we've IPv6 support which will be improved with other PRs. Thanks! |
@4s3ti can you add an IPv6 address to
ACK
Separate pull requests. I will test this as soon as i have time IRL, and find out why the checks fail. |
I would advise against using such subdomain for that. Rather create a specific domain for that purpose.
I am happy to further help improve pivpn but I rather go for smaller packages adding improvements than one or two huge PRs. @4s3ti Can we maybe discuss out of public Github regarding the dev env and testing? Maybe a discord group or something that also allows voice. Maybe you can create one and provide the info in the repo README ("for devs only, no support!" with manual server approval from your side). |
Not sure ... need to investigate that.
We have matrix where we can chat .. also can make a dev only room on matrix .. would that suffice? |
Where can I sign up?
Hetzner cloud for a few bugs is available with both. |
I know .. but I have everything running on Google Kubernetes service, so configuring IPv6 might require some tricks .. need to investigate that As for matrix .. the easiest place is here: https://element.io/ the only reason why i am not opening up a discord is because it becomes way to much stuff to manage. the room is on the README ... and during the weekend can spin up a devs room or something. will think the best approach, in the meantime you can always PM me there |
The rationale behind |
|
lets discuss further in matrix. To much discussion here. |
We might switch to that URL in the future. For the time being I implemented just testing at google.com as this is most probably also allowed and google.com supports IPv6 of course. |
|
After discussing with @4s3ti in matrix we decided to disable IPv6 tests in travis since travis doesn't really support IPv6 properly. It's only available in the LXC container which are only running on ARM which brings other problems to the table. I implemented the following:
We need someone to test this now without and with unattended file. Disabling IPv6 via unattended file works already otherwise travis tests would fail. Update: I sqashed most commits into a few since it was kinda messy. |
DerDanilo
force-pushed
the
wg_ipv6_client_config
branch
from
7e110b1
to
4dfcfd0
Compare
|
LGTM. |
Following my comment (#1394 (comment)) I tried to integrate IPv6 for pivpn.
This PR adds basic IPv6 support for Wireguard using IPv6 NAT. IPv6 NAT is more or less ugly but works fine, since requests are desired be coming from the public IPv6 of the VPN server and not the client IPv6 (in most cases).
:and::which might cause some trouble.WG IPv6 basically works on multiple installations I am maintaining. Now some people need to test and help finalize it to make this work with pivpn.
Edit: I fixed lint errors but don't know what is wrong with the setup tests since the setup seems to finish without errors but wireguard doesn't seem to be able to start. Can someone please check on that?
Thanks!