Feature request: PIA Port Forwarding Wireguard Custom Config

[xtinct101]

What's the feature 🧐

Hello,

Firstly, thanks for your continued work on Gluetun. I use PIA and switched to a custom wireguard config from openvpn. Everything works great except that when I try to use the "VPN_PORT_FORWARDING=on" with custom provider I get an error stating that it can only be used with PIA service provider. I'd like to have the PIA port fowarding when using wireguard but I've searched the wiki and issues section but could find a solution for this. Any help would be appreciated.

Extra information and references

No response

[xtinct101]

Yeah no worries regarding off-topic was just trying to get @jpcapone up and running without port forwarding.

FYI both are using the same wg0 file to keep it consistent.

1. When I run that command I get this.

   traceroute to privateinternetaccess.com (172.64.151.73), 1 hops max, 46 byte packets
   1  10.8.128.1 (10.8.128.1)  20.003 ms  21.773 ms  22.157 ms

   2. It doesn't seem to log it but what is perhaps is useful, when I looked at the wg0 from thrnz/docker-wireguard-pia the api ip is 10.9.128.1 which is different then what gluetun traces above. Here is the full log from docker-wireguard if there might be anything useful.

   piavpn | 2024-07-11T10:01:47.560373248Z Using PIA DNS servers: 10.0.0.243,10.0.0.242 piavpn | 2024-07-11T10:01:47.561243535Z Port forwarding is available at this location piavpn | 2024-07-11T10:01:47.561260461Z Successfully generated /etc/wireguard/wg0.conf piavpn | 2024-07-11T10:01:47.563301712Z Thu Jul 11 10:01:47 UTC 2024: Bringing up WireGuard interface wg0 piavpn | 2024-07-11T10:01:47.569304634Z [#] ip link add wg0 type wireguard piavpn | 2024-07-11T10:01:47.570147192Z [#] wg setconf wg0 /dev/fd/63 piavpn | 2024-07-11T10:01:47.570730543Z [#] ip -4 address add 10.9.175.227 dev wg0 piavpn | 2024-07-11T10:01:47.572763140Z [#] ip link set mtu 1420 up dev wg0 piavpn | 2024-07-11T10:01:47.573644819Z [#] resolvconf -a wg0 -m 0 -x piavpn | 2024-07-11T10:01:47.575603154Z could not detect a useable init system piavpn | 2024-07-11T10:01:47.584086821Z [#] wg set wg0 fwmark 51820 piavpn | 2024-07-11T10:01:47.584375038Z [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820 piavpn | 2024-07-11T10:01:47.584740790Z [#] ip -4 rule add not fwmark 51820 table 51820 piavpn | 2024-07-11T10:01:47.585153558Z [#] ip -4 rule add table main suppress_prefixlength 0 piavpn | 2024-07-11T10:01:47.586676679Z [#] iptables-restore -n piavpn | 2024-07-11T10:01:47.587637142Z piavpn | 2024-07-11T10:01:47.587878209Z interface: wg0 piavpn | 2024-07-11T10:01:47.587901118Z public key: xxxx piavpn | 2024-07-11T10:01:47.587902469Z private key: (hidden) piavpn | 2024-07-11T10:01:47.587903680Z listening port: 47734 piavpn | 2024-07-11T10:01:47.587904861Z fwmark: 0xca6c piavpn | 2024-07-11T10:01:47.587906077Z piavpn | 2024-07-11T10:01:47.587907110Z peer: xxxx piavpn | 2024-07-11T10:01:47.587908230Z endpoint: 91.90.126.60:1337 piavpn | 2024-07-11T10:01:47.587909278Z allowed ips: 0.0.0.0/0 piavpn | 2024-07-11T10:01:47.587910306Z transfer: 0 B received, 148 B sent piavpn | 2024-07-11T10:01:47.587911432Z persistent keepalive: every 25 seconds piavpn | 2024-07-11T10:01:47.587933702Z piavpn | 2024-07-11T10:01:47.588244456Z Thu Jul 11 10:01:47 UTC 2024: WireGuard successfully started piavpn | 2024-07-11T10:01:47.685488578Z Thu Jul 11 10:01:47 UTC 2024: Allowing network access to 192.168.90.19/24 on eth0 piavpn | 2024-07-11T10:01:47.694955669Z Thu Jul 11 10:01:47 UTC 2024: Firewall enabled: Blocking non-WireGuard traffic piavpn | 2024-07-11T10:01:47.703866050Z Thu Jul 11 10:01:47 UTC 2024: Allowing network access to 192.168.50.0/24 on eth0 piavpn | 2024-07-11T10:01:47.710342613Z Thu Jul 11 10:01:47 UTC 2024: Adding route to 192.168.50.0/24 piavpn | 2024-07-11T10:01:47.714226853Z Thu Jul 11 10:01:47 UTC 2024: Allowing network access to 192.168.90.0/24 on eth0 piavpn | 2024-07-11T10:01:47.720479613Z Thu Jul 11 10:01:47 UTC 2024: Adding route to 192.168.90.0/24 piavpn | 2024-07-11T10:01:47.722536902Z RTNETLINK answers: File exists piavpn | 2024-07-11T10:01:47.730071795Z Thu Jul 11 10:01:47 UTC 2024: Starting port forward script piavpn | 2024-07-11T10:01:47.736102890Z Thu Jul 11 10:01:47 UTC 2024: Verifying API requests. CN: panama406 piavpn | 2024-07-11T10:01:47.738721823Z Thu Jul 11 10:01:47 UTC 2024: Getting PF token piavpn | 2024-07-11T10:01:47.740129642Z Thu Jul 11 10:01:47 UTC 2024: Reusing previous PF token piavpn | 2024-07-11T10:01:52.935910254Z Thu Jul 11 10:01:52 UTC 2024: Obtained PF token. Expires at 2024-08-31T04:28:30.946050398Z piavpn | 2024-07-11T10:01:52.936192158Z Thu Jul 11 10:01:52 UTC 2024: Server accepted PF bind piavpn | 2024-07-11T10:01:52.936515877Z Thu Jul 11 10:01:52 UTC 2024: Forwarding on port 24737 piavpn | 2024-07-11T10:01:52.936793219Z Thu Jul 11 10:01:52 UTC 2024: Rebind interval: 900 seconds piavpn | 2024-07-11T10:01:52.937022726Z Thu Jul 11 10:01:52 UTC 2024: Port dumped to /pia-shared/port.txt piavpn | 2024-07-11T10:01:52.937352090Z Thu Jul 11 10:01:52 UTC 2024: This script should remain running to keep the forwarded port alive piavpn | 2024-07-11T10:01:52.937613422Z Thu Jul 11 10:01:52 UTC 2024: Press Ctrl+C to exit piavpn | 2024-07-11T10:01:52.938034803Z Thu Jul 11 10:01:52 UTC 2024: Running /scripts/pf_success.sh piavpn | 2024-07-11T10:01:52.940007073Z Thu Jul 11 10:01:52 UTC 2024: Allowing incoming traffic on port 24737

[qdm12]

2. when I looked at the wg0 from thrnz/docker-wireguard-pia the api ip is 10.9.128.1 which is different then what gluetun traces above.

Oh wait, are all PIA Wireguard configurations coming with a #pf api ip: 1.2.3.4??? Because I see this line now https://github.com/thrnz/docker-wireguard-pia/blob/5c6fd5dc6dcd204c6a6a7c56e5637928446ede0b/run#L280C19-L280C26 and it looks like it? If so, I could parse it out. I am guessing the code they have here doesn't actually work, same as Gluetun. So possibly we cannot auto-magically determine the API IP address 🤔 Alternatively, would you be ok having a new option PORT_FORWARDING_API_IP which you can set to 10.9.128.1 for example?

[dreary-ennui]

2. when I looked at the wg0 from thrnz/docker-wireguard-pia the api ip is 10.9.128.1 which is different then what gluetun traces above.

Oh wait, are all PIA Wireguard configurations coming with a #pf api ip: 1.2.3.4??? Because I see this line now https://github.com/thrnz/docker-wireguard-pia/blob/5c6fd5dc6dcd204c6a6a7c56e5637928446ede0b/run#L280C19-L280C26 and it looks like it? If so, I could parse it out. I am guessing the code they have here doesn't actually work, same as Gluetun. So possibly we cannot auto-magically determine the API IP address 🤔 Alternatively, would you be ok having a new option PORT_FORWARDING_API_IP which you can set to 10.9.128.1 for example?

In my own usage of thrnz's docker-wireguard-pia, I do have a #pf api ip: x.x.x.x line, but it's not 10.9.128.1. Perhaps it changes based on server selection or some other factor? If so, I'd not want to have to hard code a value in an environment variable, but would rather in some automated fashion determine it.

[xtinct101]

2. when I looked at the wg0 from thrnz/docker-wireguard-pia the api ip is 10.9.128.1 which is different then what gluetun traces above.

Oh wait, are all PIA Wireguard configurations coming with a #pf api ip: 1.2.3.4??? Because I see this line now https://github.com/thrnz/docker-wireguard-pia/blob/5c6fd5dc6dcd204c6a6a7c56e5637928446ede0b/run#L280C19-L280C26 and it looks like it? If so, I could parse it out. I am guessing the code they have here doesn't actually work, same as Gluetun. So possibly we cannot auto-magically determine the API IP address 🤔 Alternatively, would you be ok having a new option PORT_FORWARDING_API_IP which you can set to 10.9.128.1 for example?

It seems that at least from the wg0 config files there seems to be a #pf api ip. We can definitely at least try adding the variable to tests if at least that finally fixes the issue.

[qdm12]

Is there a consistent difference between the pf api ip described in the Wireguard configuration file and the gateway IP you find using docker exec gluetun traceroute -4 -m 1 -i tun0 privateinternetaccess.com?

How about when running docker exec gluetun ip route show table all, do you get anywhere the same API IP as the one in the wireguard config file? Or something looking similar? For now Gluetun uses routes to find the gateway, maybe it's the wrong logic and it should look elsewhere. That way it would be automated, and not dependent on the # pf api ip comment, which could change in the future possibly.

[xtinct101]

thornz wg0 = #pf api ip: 10.3.128.1

executing docker exec gluetun traceroute -4 -m 1 -i tun0 privateinternetaccess.com returns: 10.3.128.1

executing docker exec gluetun ip route show table all returns:

192.168.90.0/24 via 192.168.90.1 dev eth0 table 199 
default via 192.168.90.1 dev eth0 table 200 
default via 192.168.90.1 dev eth0 
192.168.90.0/24 dev eth0 proto kernel scope link src 192.168.90.12 
local 10.3.249.20 dev tun0 table local proto kernel scope host src 10.3.249.20 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 192.168.90.12 dev eth0 table local proto kernel scope host src 192.168.90.12 
broadcast 192.168.90.255 dev eth0 table local proto kernel scope link src 192.168.90.12

I had a thought and ran the same commands using pia-thornz service. This is an identicale wg0 file used to connect here are the results. executing docker exec gluetun traceroute -4 -m 1 -i tun0 privateinternetaccess.com returns: 10.4.128.1

executing docker exec piathornz ip route show table all returns:

default dev wg0 table 51820 scope link 
default via 192.168.90.1 dev eth0 
192.168.50.0/24 via 192.168.90.1 dev eth0 
192.168.90.0/24 dev eth0 proto kernel scope link src 192.168.90.7 
local 10.4.225.84 dev wg0 table local proto kernel scope host src 10.4.225.84 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 192.168.90.7 dev eth0 table local proto kernel scope host src 192.168.90.7 
broadcast 192.168.90.255 dev eth0 table local proto kernel scope link src 192.168.90.7

[macdis]

Not sure this is what you're looking for regarding the pf api ip, but the pia-foss scripts get the wg gateway through a curl call (see steps 5-6 below). The process is something like this (for more info look at the pia-foss repo).

1. Get your PIA token:curl -s --location --request POST 'https://www.privateinternetaccess.com/api/client/v2/token' --form username=pXXXXXXXX --form password=XXXXXXXX
2. Get server data: curl -s https://serverlist.piaservers.net/vpninfo/servers/v6 | head -n1
3. Parse that and pick a wg server with port forwarding enabled, using whatever logic you want. I start with something like this and then pick one from the list: jq -r '.regions[] | select(.port_forward==true) | select(.name | match("montreal";"i")) | .servers.wg' < <(curl -s 'https://serverlist.piaservers.net/vpninfo/servers/v6' | head -n1) As for how to pick a server, you can iterate through the list and see which server is 'faster' by comparing results from something like (I think this is how pia-foss does it): LC_NUMERIC=en_US.utf8 curl -o /dev/null -s --connect-timeout 0.05 --write-out '%{time_connect}' https://140.xxx.xxx.xxx:443
4. Generate your own wg keys. I use wg genkey | tee /dev/tty | wg pubkey
5. Add the generated public key to your selected server: curl -fs -G --connect-to cityxxx::xxx.xxx.xxx.xxx: --cacert /config/ca.rsa.4096.crt --data-urlencode pt=***PIA_TOKEN_FROM_STEP_1*** --data-urlencode pubkey=***PUBLIC_KEY*** https://cityxxx:1337/addKey Note: the crt file is available from the pia-foss repo, but you could also use curl -k I guess.
6. The resulting JSON from step 5 contains the wg gateway (.server_vip), e.g.,

   {
   "status": "OK",
   "server_key": "xxx",
   "server_port": 1337,
   "server_ip": "xxx.xxx.xxx.xxx",
   "server_vip": "10.xxx.128.1",
   "peer_ip": "10.xxx.xxx.xxx",
   "peer_pubkey": "XXX",
   "dns_servers": [
       "10.xxx.xxx.xxx",
       "10.xxx.xxx.xxx"
   ]
   }

7. Get the port forwarding payload: curl -sk -m 5 --connect-to cityxxx::xxx.xxx.xxx.xxx: -G --data-urlencode token=***PIA_TOKEN*** https://cityxxx:19999/getSignature
8. Decode the payload to get the port number for your application, using something like: echo "$PAYLOAD" | base64 -d | jq -r '.port'
9. Bind that port number to your selected server's wg gateway: curl -skG -m 5 --connect-to cityxxx::10.xxx.128.1: --data-urlencode payload=***PAYLOAD*** --data-urlencode signature=***SIGNATURE*** https://cityxxx:19999/bindPort

That should result in:

{
    "status": "OK",
    "message": "port scheduled for add"
}

This process obviously gives you everything you need to construct a valid wg0.conf file.

For more info, see the pia-foss repo. All of this comes from there.

[qdm12]

@xtinct101 a few questions:

1. The pia-thornz returns the wrong API IP address 10.4.128.1 using traceroute, correct (at least compared to the wireguard config file)? Or is this one IP address 10.4.128.1 working as well?
2. I'm thinking, is the API IP address consistently [2 parts from assigned IP] + 128.1? For example from local 10.3.249.20 dev tun0 table local proto kernel scope host src 10.3.249.20, you take 10.3 and add 128.1 and you have your API IP address 🤔 Could you check with 1 or 2 other servers if this seems consistent? A bit hacky, but if it does the job 🤷 Obviously, this depends on question 1. as well! From @macdis comment 10.xxx.128.1 this seems to be consistent; I'll jump in code something

@macdis the problem is right now Gluetun cannot do networking before the tunnel is up, and registering a wireguard key after wireguard is setup sounds quite strange. Is there any way to fetch that server_vip without registering a wireguard key? I opened https://github.com/pia-foss/manual-connections/issues/190 regarding this.

[dreary-ennui]

2. I'm thinking, is the API IP address consistently [2 parts from assigned IP] + `128.1`? [...] Could you check with 1 or 2 other servers if this seems consistent? 

I know I'm not the person you're asking, but this does seem to be correct with several servers I've tried and looked at the wg0.conf after a connection is established.

[qdm12]

Can you try with image tag :pr-2420? I opened #2420 which computes the API IP address that way. If it works, can you also try using OpenVPN (using VPN_SERVICE_PROVIDER=private internet access) to check if the gateway computation only works for Wireguard or not?

[xtinct101]

Yep, that seemed to do it!!!

gluetun  | 2024-08-16T13:58:20.972394445Z 2024-08-16T13:58:20Z INFO [port forwarding] starting
gluetun  | 2024-08-16T13:58:21.349513541Z 2024-08-16T13:58:21Z INFO [port forwarding] Port forwarded data expires in 62 days
gluetun  | 2024-08-16T13:58:21.363755540Z 2024-08-16T13:58:21Z INFO [port forwarding] port forwarded is 45263
gluetun  | 2024-08-16T13:58:21.363804820Z 2024-08-16T13:58:21Z INFO [firewall] setting allowed input port 45263 through interface tun0...
gluetun  | 2024-08-16T13:58:21.363813214Z 2024-08-16T13:58:21Z DEBUG [firewall] iptables --append INPUT -i tun0 -p tcp -m tcp --dport 45263 -j ACCEPT
gluetun  | 2024-08-16T13:58:21.366622356Z 2024-08-16T13:58:21Z DEBUG [firewall] ip6tables --append INPUT -i tun0 -p tcp -m tcp --dport 45263 -j ACCEPT
gluetun  | 2024-08-16T13:58:21.369118405Z 2024-08-16T13:58:21Z DEBUG [firewall] iptables --append INPUT -i tun0 -p udp -m udp --dport 45263 -j ACCEPT
gluetun  | 2024-08-16T13:58:21.371871656Z 2024-08-16T13:58:21Z DEBUG [firewall] ip6tables --append INPUT -i tun0 -p udp -m udp --dport 45263 -j ACCEPT
gluetun  | 2024-08-16T13:58:21.374546590Z 2024-08-16T13:58:21Z INFO [port forwarding] writing port file /gluetun/port.txt

[xtinct101]

while it now seems likes it working'ish, the vpn is restarting every x-sec. - please ignore, it seems it was a server causing the crash. changing server seems to fix it.

So now that it seems that PF is working there are a few other minor issues to consider. The wg0.conf file seems to be constantly outdated as either PIA changes or what I'm not sure but piathornz seems to generate the wg0 file on the fly. Secondly, it seems that the region is required to enable PF, which we already use, BUT it seems to be very specific the server you connect too and if it doesn't match the connection isn't made.

When generating a wg0 from pia_foss the result is this: $PIA_TOKEN=xxxx \ WG_SERVER_IP=91.90.126.94 WG_HOSTNAME=panama408 \ So you need to set SERVER_NAMES=panama408 so somehow we need all that to be handled by gluetun, unless it already does and I'm not aware.

[qdm12]

@xtinct101 Does port forwarding work with OpenVPN, using the native PIA openvpn+Port forwarding integration?

All this 'native support' for PIA Wireguard+Port forwarding will come later, once Gluetun can do (very restriced) networking when the VPN tunnel is not up, to generate that Wireguard configuration file as you mentioned.

I need to update the Wiki though, so what you need (let me know if I forgot something):

• Generate a Wireguard configuration file for a server which supports VPN port forwarding (any link to a list?)
• VPN_PORT_FORWARDING=on
• VPN_PORT_FORWARDING_PROVIDER=private internet access
• SERVER_NAMES must be set to the server name for TLS validation when communicating with their API, for example panama408

EDIT: Also VPN_PORT_FORWARDING_USERNAME and VPN_PORT_FORWARDING_PASSWORD

[JoooostB]

@xtinct101 Please note that your password got sent to everyone who subscribed to this issue and is still visible in history, you should really change it ASAP!

@qdm12 I tested Wireguard here as well, which works perfectly if SERVER_NAMES only contains one value. When another name is added, separated by a comma, it won't go through and fails on certificate validation.

[xtinct101]

@JoooostB yes I know I hit send before erasing it. I've already changed it. Thanks regardless!

[xtinct101]

@qdm12 just verified both wireguard and openvpn work with port forwarding.

also require

VPN_PORT_FORWARDING_USERNAME= VPN_PORT_FORWARDING_PASSWORD= This is the only list I'm aware of. https://[serverlist.piaservers.net/vpninfo/servers/v6](https://serverlist.piaservers.net/vpninfo/servers/v6)

[github-actions[bot]]

Closed issues are NOT monitored, so commenting here is likely to be not seen. If you think this is still unresolved and have more information to bring, please create another issue.

This is an automated comment setup because @qdm12 is the sole maintainer of this project which became too popular to monitor issues closed.

[qdm12]

The PR is merged (latest image), and the wiki's PIA page is updated 👍 Thank you all for your help! 💯

[OfficePop]

I just caught up on all this-is there a way to obtain the server name needed with pia-wf-config? That's what i've been using to generate a WG config with gluetun.