feat(pia): native WireGuard support with port forwarding - #3393
feat(pia): native WireGuard support with port forwarding#3393neilcorp2kx wants to merge 3 commits into
Conversation
Add a mechanism to open narrowly-scoped, temporary outbound firewall allowances (destination IP + protocol + port + firewall mark, on the physical interface) that are needed before the VPN tunnel is up, then reliably torn down afterwards. - temporary.go: central registry of temporary allowances with retain-on-failure cleanup, idempotent deletion under a bounded non-cancelable context, and a sweep on firewall shutdown and before re-adding on reconnect. Attempted interfaces are tracked before the iptables append so a rule applied during a cancellation race is never left untracked. - iptables: emit and parse the '-m mark --mark <value>' match so the temporary ACCEPT rules are scoped to the bootstrap socket mark and can be deleted symmetrically. Reject malformed mark match forms instead of silently accepting a zero mark or panicking on a bad value. Covered by unit tests for rollback, deletion-failure retry, idempotence, mark scoping, reconnect de-duplication and mark parsing edge cases.
Private Internet Access previously only supported OpenVPN in gluetun because PIA registers a fresh WireGuard key per connection via its own API, which does not fit a static WireGuard config. This adds a provider-driven dynamic WireGuard path for PIA. At connection time, for VPN_SERVICE_PROVIDER=private internet access + VPN_TYPE=wireguard, gluetun now: - fetches PIA's live server list and selects a WireGuard server for the chosen region/name/hostname (honouring port-forwarding-only), - obtains an auth token, generates an ephemeral Curve25519 key pair, and registers the public key with the selected server (addKey) over TLS pinned to the server CN using the bundled PIA CA, - builds the WireGuard connection from the response (endpoint, peer key, interface address, DNS), re-registering on every reconnect, - performs the pre-tunnel token/server-list/addKey calls through scoped, temporary, mark-tagged firewall allowances so the killswitch is never opened to arbitrary destinations, resolving via a bootstrap dialer pinned to the physical default route. Port forwarding now works natively over WireGuard for PIA (gateway taken from the addKey server_vip). The earlier custom-provider workaround env VPN_PORT_FORWARDING_SERVER_NAME remains supported. Invalid, unspecified or non-IPv4 server_ip/server_vip/peer_ip values are rejected with errors rather than panicking, and the persisted port-forward token file is written and kept 0600. Config is just credentials + region, e.g.: VPN_SERVICE_PROVIDER=private internet access VPN_TYPE=wireguard SERVER_REGIONS=CA Vancouver VPN_PORT_FORWARDING=on VPN_PORT_FORWARDING_PROVIDER=private internet access Closes passteque#3070.
The VPN startup healthcheck performed a single 6s TCP+TLS check. When a tunnel's DNS server takes a few seconds to become ready after connect (e.g. providers that do pre-tunnel work), that single attempt could fail and trigger an endless VPN restart loop. Retry the short (6s) parallel TCP+TLS attempts within a 60s total budget with a 2s backoff, returning on the first success and preserving the existing aggregated error on budget exhaustion. Periodic checks are unchanged. This removes the need for any manual startup-grace tuning and is a general robustness improvement for all providers.
|
I've been testing this for a day and it works but the connection died after around 24h and didn't come back automatically, started getting spammed in the logs with: Also after reconnecting manually (docker compose down + up) it seems like the saved forwarded port is not properly refreshed, I got connected to a different server in the same region but it tried to reuse the old port (which is obviously not valid for the new IP). I had to manually delete the I'm not too familiar with gluetun config so this last part might just be something you can fix with some config options, but I didn't find anything at a glance. My config: Thank you for the PR! Will report back if it happens again and I have any extra info. |
|
More logs, this time it took 6 days for the same thing to happen: |
|
I spent some time testing this branch against a real PIA account (CA Toronto, 1. A killed tunnel never recovers
Reproduced with I think this is what @unrealtournament is reporting above. The trigger is whatever kills the Control, to make sure I wasn't blaming the wrong thing: same tree, reverting only the 2.
|
| branch | result |
|---|---|
93cc5a4 |
err=<nil>, serverName="vancouver439" |
| this branch | err=server name not set, serverName="" |
4. Saved port-forward data has no server identity
This is the other half of @unrealtournament's report (reconnecting to a different server reuses a
port that isn't valid, needing a manual piaportforward.json delete). Reproduced live. After a
reconnect:
INFO [port forwarding] Found saved forwarded port data for port 45511
INFO [port forwarding] port forwarded is 45511 <- different server than issued it
The saved file holds only ["expires_at","port","signature","token"], nothing identifying the
server or gateway. The reuse gate checks expiry only, and PIA's tokens last ~2 months, so it
practically never refreshes. A non-errPortBusy bind failure doesn't invalidate the file either, so
the loop replays the same stale payload every 5s indefinitely.
Adding ServerName/Gateway to the saved struct and rejecting a mismatch would cover it. Worth
noting this branch makes it much more likely, since selectWireguardServer re-picks from PIA's live
list on every connect, so "same region, different server" becomes normal rather than rare.
5. Smaller things
findAPIIPapplies the OpenVPN gateway octet-rewrite (x.y.128.1,x.y.0.1) to the WireGuard
server_vip. For PIA WireGuard the PF gateway is the VIP (their ownport_forwarding.shuses
PF_GATEWAY=$WG_SERVER_VIP), so the VIP itself is never probed. The fixtures in this PR use
server_vip: 10.13.161.1, which I think its own code wouldn't reach.internal/provider/privateinternetaccess/updater/wireguard_test.go:152doesn't parse
(missing ',' before newline in argument list), so that package fails[setup failed], which
also meansTest_selectWireguardServerisn't running.internal/vpn/wireguard_test.gousesnew("...")/new(uint32(...)), which needs go1.26 while
go.moddeclares 1.25, sogo vet ./...exits 1.gofmt -lflags a few of the changed files.
Thanks for putting this together. Happy to re-test any revision.
|
Hey there! I reviewed the current head of this PR and prepared a follow-up branch against The follow-up keeps this PR as the implementation base, but changes the bootstrap and reconnect path to use the
The saved port-forward payload does not need a server identity. PIA documents payload/signature reuse across servers. The authenticated reconnect test confirmed this behavior: the first Vancouver endpoint issued port Live verification covered the original recovery failure directly:
Lint, generated-mock checks, cross-compilation, focused race tests, restrictednet integration tests, and the final image build pass. The full test-container run has the same netlink/PMTUD failures on current master and the follow-up branch on this SELinux host; audit logs show denied module auto-load requests for I also ran the traditional PIA OpenVPN path with the same image. OpenVPN initialized normally, public egress worked, port forwarding produced an externally reachable TCP port, and the firewall contained only the expected OpenVPN endpoint and tunnel rules. AI was used for analysis and code generation. I reviewed the resulting changes and verification output. Please @neilcorp2kx take a look at the improvments made, likewise @qdm12 hopefully we can get this in before 3.42 🤞 |
5 participants
Summary
This adds native WireGuard support for Private Internet Access (PIA), including port forwarding, plus a small healthcheck robustness improvement that the native path depends on.
Today PIA is OpenVPN-only in gluetun, and PIA + WireGuard + port forwarding is a long-standing gap (#3070, #2147): the custom-provider workaround panics with
server name cannot be empty, and PIA cannot be selected as a WireGuard provider at all. The underlying reason is that PIA does not hand out static WireGuard configs — it registers a fresh WireGuard key per connection through its own API, which does not fit gluetun's normally-static WireGuard model.This PR implements that dynamic registration inside the PIA provider so the whole flow is just credentials + region:
No externally-generated WireGuard config, no static keys, no helper scripts. Server selection and key rotation happen automatically on every (re)connect.
Closes #3070.
What's in it
Three focused commits:
feat(firewall)— scoped temporary bootstrap connection allowances. A registry of narrowly-scoped (destination IP + protocol + port + firewall mark, physical interface) temporary outbound allowances needed before the tunnel is up, with retain-on-failure cleanup, idempotent deletion under a bounded non-cancelable context, and a sweep on shutdown / before reconnect. iptables gains-m mark --markemit+parse so the rules are mark-scoped and delete symmetrically.feat(pia)— native PIA WireGuard + port forwarding. At connect time the provider fetches PIA's live server list, selects a WireGuard server for the requested region/name/hostname, obtains a token, generates an ephemeral Curve25519 key pair, registers the public key (addKey) over TLS pinned to the server CN via the bundled PIA CA, and builds the WireGuard connection from the response (re-registering each reconnect). Port forwarding works natively (gateway from theaddKeyserver_vip).feat(healthcheck)— retry the startup TCP+TLS check within a 60s budget (2s backoff) instead of a single 6s attempt, so a tunnel whose DNS takes a few seconds to become ready doesn't trigger a restart loop. General improvement, not PIA-specific.Design / safety notes
addKeycalls are the only new outbound traffic before the tunnel exists. They go through the temporary, mark-tagged, exact-destination allowances above, resolved by a bootstrap dialer pinned to the physical default route, and are torn down before the tunnel comes up. Discovery/registration failure fails closed (the tunnel does not start). There is no fail-open to arbitrary destinations.0600.server_ip/server_vip/peer_ip) is rejected with errors rather than panicking.Testing
addKeyrequest/response mapping), healthcheck retry, and settings validation.Known / deferred (pre-existing, not introduced here)
OpenVPN.User/Passwordfor credentials, which are serialized by the authenticated/v1/vpn/settingscontrol endpoint like all other settings — a pre-existing exposure, called out here because the native path now depends on those fields. A redacted control DTO would be a separate change.addKeyclient trusts the bundled PIA CA additively on top of the system pool rather than pinning PIA-only. TLS name verification is enabled and there is noInsecureSkipVerify.A note on how this was developed
This was built and hardened with heavy, deliberate use of AI tooling — a combination of OpenAI Codex and Anthropic Claude — for implementation, iterative debugging against a live PIA endpoint, and multiple adversarial code-review passes focused on killswitch/leak safety, with all findings driven to resolution and re-verified. Flagging this transparently; every change has been reviewed and validated by a human, and I'm happy to walk through any part of the design or rationale.
Opening as a draft intentionally — soaking on a live setup for a bit before marking it ready. Feedback on the approach (especially the bootstrap-firewall handling and whether a redacted control DTO should be bundled) very welcome.