Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Wireguard support for PIA #612

Open
4 tasks
qdm12 opened this issue Sep 10, 2021 · 15 comments · May be fixed by #1836
Open
4 tasks

Feature request: Wireguard support for PIA #612

qdm12 opened this issue Sep 10, 2021 · 15 comments · May be fixed by #1836
Assignees
Labels
Category: Wireguard 🔐 Status: 🔴 Blocked Blocked by another issue or pull request

Comments

@qdm12
Copy link
Owner

qdm12 commented Sep 10, 2021

What's the feature? 🧐

  • Support Wireguard for PIA

Optional extra information 🚀

TODOs

  • Allow to communicate (LEAK) to PIA servers before connecting
  • make PIA API package from port forwarding code since Wireguard also requires the token etc.
  • Obtain dynamically Wireguard public key (and other data) and plug that in connection builder
  • Add PIA to VPNSP for Wireguard
@qdm12
Copy link
Owner Author

qdm12 commented Sep 28, 2021

Actually this is problematic since it requires to send a request to PIA outside the VPN to obtain/register a Wireguard key. Having the whole container focused on not leaking anything before the tunnel is up, this is... bothering.

I guess I can do some firewall gymnastics to allow connections to PIA before Wireguard is up, but it does not feel like the ideal solution 😢

@raph521
Copy link

raph521 commented Sep 28, 2021

It's probably overly complicated, but could Gluetun connect to PIA over OpenVPN initially, obtain the Wireguard key, then disconnect via OpenVPN and re-connect using Wireguard?

@qdm12
Copy link
Owner Author

qdm12 commented Sep 28, 2021

I thought about that, but that looks like weeks to implement 😢 There is also Surfshark (and possibly NordVPN, Cyberghost) which also work the same as PIA where you need to make an API call initially. Why would anyone design such horror 😄 Anyway, I think setting up a dumb OpenVPN at start to do API calls is the solution here. It might not be that hard either, but it feels... over-complicated 🥼

@kusold
Copy link

kusold commented Sep 28, 2021

Another potential solution is to do the API calls through a sock5 proxy. Curl and Go both support this out of the box.

It does require separate credentials for PIA though.

https://www.privateinternetaccess.com/helpdesk/kb/articles/do-you-offer-a-socks5-proxy

@lmakarov
Copy link

I thought about that, but that looks like weeks to implement 😢 There is also Surfshark (and possibly NordVPN, Cyberghost) which also work the same as PIA where you need to make an API call initially. Why would anyone design such horror 😄

They designed it this way to support their own desktop/mobile applications. That also means that the official VPN client apps leak this info (making requests to a VPN provider's API endpoint).

.. setting up a dumb OpenVPN at start to do API calls is the solution here. It might not be that hard either, but it feels... over-complicated

Whether you access an API endpoint of a VPN provider or connecting to one of their VPN servers, it is very clear (for your ISP/NSA/etc.) what you are trying to do - establish a VPN connection with a particular VPN provider. As long as the API connection is encrypted (which it is), you are not exposing any additional information. Your intents are still pretty obvious.

The major downside to this process is that it's much easier to block as single API endpoint compared to blocking ranges of IPs of VPN servers.

@qdm12
Copy link
Owner Author

qdm12 commented Sep 28, 2021

Whether you access an API endpoint of a VPN provider or connecting to one of their VPN servers

True, true.

The major downside to this process is that it's much easier to block as single API endpoint compared to blocking ranges of IPs of VPN servers.

Yep. Regarding IP level sniffing, it doesn't change much, but blocking-wise, it's much easier to block a single IP address than N ones that might change over time.

nslookup privateinternetaccess.com
Address:  23.10.89.37

They only have a single public IP address sadly.

Well I guess PIA users should expect protection similar to PIA's official app anyway. If they're not happy, other providers are more privacy robust like Ivpn, Mullvad or Windscribe (at least for Wireguard).

I'll take the do-the-api-call-outside-the-vpn route (which is already complex given the existing setup), otherwise it's really mind hard to implement. Maybe log a warning to the user about it.

@Fr4nk256
Copy link

Any progress on this? Would be a nice function

@robotictacos
Copy link

robotictacos commented Feb 8, 2022

I see the optional info, but it's not clear to me how (or even if possible) to use that to manually create the token and give that to gluetun to use PIA's Wireguard. I have no problem updating and running the mentioned scripts to grab a token, (I certainly understand that it is difficult to automatically implement) but I'd like to be able to manually do that if I can.

@jvgomg
Copy link

jvgomg commented Jan 16, 2023

I think the "do-the-api-call-outside-the-vpn" approach sounds like the most sensible option. Warnings about the behaviour in the console and in the wiki would be sufficient.

I've seen the wiki documentation on adding new service providers however it seems like there are some other complexities for this feature. Does anybody know if there have been any other similar providers added, that require an initial fetch for a token, since this issue was first created? As a reference point.

@fastily
Copy link

fastily commented Apr 23, 2023

I found this PIA + Wireguard project: https://github.com/thrnz/docker-wireguard-pia

Could be helpful as a reference for implementing this feature in gluetun

@tonynca
Copy link

tonynca commented Jun 27, 2023

I have 3 more years with PIA. Please release this feature! I don't mind ISP knowing that I'm connecting to PIA.

Mullvad just pulled port forwarding from their service which is a huge issue if you want to torrent stuff using VPN.

@peterpiglet
Copy link

In the vast and intricate tapestry of digital landscapes, a shadowy need has emerged, longing for your wise touch. A request, nay, a fervent plea, escapes my lips like an incantation carried by the winds of destiny. I beseech thee, conjure forth the wondrous enchantment known as WireGuard within the heart of your creation.

@FireMasterK FireMasterK linked a pull request Sep 1, 2023 that will close this issue
@FireMasterK
Copy link

Hi, I've implemented this feature in #1836, but I don't have a PIA account to test it. Help for testing would be greatly appreciated! 🙏

You can build the image by cloning my branch, and then run:

docker build . -t gluetun

Now, the image would be build with the name gluetun.

@qdm12
Copy link
Owner Author

qdm12 commented Aug 1, 2024

See https://github.com/qdm12/gluetun-wiki/blob/8715a24b27b439e8880d5aba301ac2a02cacca57/setup/providers/private-internet-access.md#L49 You can extract a wireguard config file to plug it into gluetun, some people are already using this 😉

Does anybody know if there have been any other similar providers added, that require an initial fetch for a token, since this issue was first created

No, PIA is probably first on the list once this is implemented. Blocked partly by #137

I don't mind ISP knowing that I'm connecting to PIA.

Yes, but some might, and adding an option sounds cumbersome. Better do it right since the start. Andy yes sorry this is taking quite some time, because partly it's not so much a priority, they are workarounds (see above).

Hi, I've implemented this feature in #1836

Greatly appreciated 💯 although this has the same problem that traffic would leak at the beginning. I'll try to rebase your branch once it's possible to do very-restricted-network-requests before the vpn is up.

@fastily
Copy link

fastily commented Aug 1, 2024

problem that traffic would leak at the beginning

Seems like quite a few commentators are ok with this. Would it be possible to add this as an option (assuming #612 (comment) is still relevant) but with a huge warning banner either in the docs or the logs that traffic may leak and that privacy is not guaranteed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Wireguard 🔐 Status: 🔴 Blocked Blocked by another issue or pull request
Projects
None yet
Development

Successfully merging a pull request may close this issue.