pia-foss / desktop Goto Github PK

Describe the bug
I successfully build the client for arm64 device. And I am able to install the build with no error as shown below:

However, when I tried to launch the client, nothing happened. Then, I checked the system monitor but pia-client is not running as it should.

I can still use the piactl commands though.

To Reproduce
Steps to reproduce the behavior:

1. Download the installer for arm64 device here. It is my build following the method in this repo.
2. Navigate to the download location and install the client in the terminal with sh pia-linux-arm64-2.9-00032.debug.run.
3. Open the client.
4. The GUI will not launch and there's no pia-client process running.

Expected behavior
The client's GUI should launch and the pia-client process should be running.

Observed on:

• OS: Ubuntu Desktop 64-bit for Raspberry Pi 4
• Version: 21.04
• Device: Raspberry Pi 4 model B, 8GB RAM

Describe the bug
When starting pia-client in XWindows on a HiDPI display, the PIA Window respects QT scaling environment variables, but the tray icon's menu does not.

To Reproduce
Steps to reproduce the behavior:

1. Start pia-client on a HiDPI machine.

• Note the QT scaling variables listed in stdout.
• Note that the primary window is properly scaled.

2. Right-click on the tray icon
3. Observe the teeny tiny, non-scaled menu.

Expected behavior
The tray menu should observe the same scaling rules as the app window.

Observed on:

• OS: Manjaro Linux
• Version: current
• Environment: i3wm on XWindows.

Output of pia-client:

pia-client                                                                   
[+0.001][json.settings][json.cpp:344][debug] Successfully read clientsettings.json
[+0.001][default][linux_env.cpp:21][info] XDG_CURRENT_DESKTOP= "i3"
[+0.001][default][linux_env.cpp:69][info] Detected desktop "Unknown" and RTL: false
[+0.012][default][builtin/util.cpp:228][info] Initializing crash handler
[+0.012][logger][builtin/logging.cpp:226][info] Initializing LoggerPrivate
[+0.012][logger][builtin/logging.cpp:272][info] No debug.txt found; using default filter rules
[+0.024][default][client.cpp:399][info] Changed to locale "en-US"
[+0.217][default][client.cpp:794][info] Client connected, loading UI
[+0.289][qml][qrc:/components/dashboard/connect/ModuleSorter.qml:196][info] Added missing module snooze
[+0.321][qml][qrc:/components/dashboard/ChangelogWindow.qml:27][info] Changelog height: 41
[+0.378][qml][qrc:/components/settings/pages/NetworkPage.qml:234][info] errors: []
[+0.845][qml][qrc:/components/dashboard/ChangelogWindow.qml:27][info] Changelog height: 3284
[+0.862][NativeTrayQt][nativetrayqt.cpp:432][info] guess tray icon QRect(4991,60 1x1) with screen QRect(0,0 4992x3120) and work area QRect(0,60 4992x3060)
[+0.872][linuxscaler][linux_scaler.cpp:34][info] Scale from "QT_SCALE_FACTOR"="3" -> 3
[+0.881][linuxscaler][linux_scaler.cpp:197][info] DPI setting '"Xft.dpi:\t288"' from xrdb results in scale -> 3
[+0.881][linuxscaler][linux_scaler.cpp:224][info] Scale factors:
[+0.881][linuxscaler][linux_scaler.cpp:225][info]  - PIA: 0
[+0.881][linuxscaler][linux_scaler.cpp:226][info]  - gsettings: 0
[+0.881][linuxscaler][linux_scaler.cpp:227][info]  - Qt: 3
[+0.881][linuxscaler][linux_scaler.cpp:228][info]  - Qt(screen): 0
[+0.881][linuxscaler][linux_scaler.cpp:229][info]  - Xft.dpi: 3
[+0.883][windowscaler][windowscaler.cpp:49][info] scale changed: 1 -> 3
[+0.894][windowscaler][windowscaler.cpp:49][info] scale changed: 1 -> 3
[+0.911][windowscaler][windowscaler.cpp:49][info] scale changed: 1 -> 3
[+0.937][windowscaler][windowscaler.cpp:49][info] scale changed: 1 -> 3
[+0.945][windowscaler][windowscaler.cpp:49][info] scale changed: 1 -> 3
[+1.017][default][window.cpp:346][info] window "Connect" focus false -> true

on a freshly installed system the split-tunnel configuration does not work as expected, whereas on a similar system it has been working great for a while.
both systems are Ubuntu 20.04 with AARCH64, are up-to-date and have identical packages installed.
all the following has been carefully verified and persists even after reinstalling the PIA application, rebooting, and so on.

both systems:

# OS info

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.4 LTS"

# PIA info

$ piactl --version
3.3.0+06906

# SplitTunnel config

$ piactl -u dump daemon-settings \
| jq '.|{ splitTunnelEnabled, defaultRoute, routedPacketsOnVPN, splitTunnelDNS}'
{
  "splitTunnelEnabled": true,
  "defaultRoute": true,
  "routedPacketsOnVPN": true,
  "splitTunnelDNS": true
}

# SplitTunnel IP

$ piactl -u dump daemon-settings | jq .bypassSubnets
[
  {
    "mode": "exclude",
    "subnet": "12.34.56.78/32"
  }
]

now, I have connected the PIA application and have saved each system's iptables rules to file.
the diff of these two files, let's call them ok.txt and ko.txt is as follows:

$ diff ok.txt ko.txt
105,106d104
< -A piavpn.r.100.transIp -o enp0s3 -j MASQUERADE
< -A piavpn.r.100.transIp -o tun0 -j MASQUERADE
109,110d106
< -A piavpn.r.80.splitDNS -p udp -m cgroup --cgroup 1383 -m udp --dport 53 -j DNAT --to-destination 169.254.169.254:53
< -A piavpn.r.80.splitDNS -p tcp -m cgroup --cgroup 1383 -m tcp --dport 53 -j DNAT --to-destination 169.254.169.254:53
113,114d108
< -A piavpn.r.90.snatDNS -p udp -m cgroup --cgroup 1383 -m udp --dport 53 -j SNAT --to-source 10.0.0.121
< -A piavpn.r.90.snatDNS -p tcp -m cgroup --cgroup 1383 -m tcp --dport 53 -j SNAT --to-source 10.0.0.121
259,264d252
< -A piavpn.r.320.allowDNS -d 169.254.169.254/32 -p udp -m cgroup --cgroup 1383 -m udp --dport 53 -j ACCEPT
< -A piavpn.r.320.allowDNS -d 169.254.169.254/32 -p tcp -m cgroup --cgroup 1383 -m tcp --dport 53 -j ACCEPT
< -A piavpn.r.320.allowDNS -p udp -m cgroup --cgroup 1383 -m udp --dport 53 -j REJECT --reject-with icmp-port-unreachable
< -A piavpn.r.320.allowDNS -p tcp -m cgroup --cgroup 1383 -m tcp --dport 53 -j REJECT --reject-with icmp-port-unreachable
< -A piavpn.r.320.allowDNS -d 169.254.169.254/32 -p udp -m cgroup ! --cgroup 1383 -m udp --dport 53 -j REJECT --reject-with icmp-port-unreachable
< -A piavpn.r.320.allowDNS -d 169.254.169.254/32 -p tcp -m cgroup ! --cgroup 1383 -m tcp --dport 53 -j REJECT --reject-with icmp-port-unreachable

in other words, all of these rules are present in the working system (ok.txt) but are absent from the iptables' rules of the failing system (ko.txt).

specifically, it seems that the PIA application on the failing system is not setting up splitDNS correctly.

any suggestions on what happenened, and how I can make split tunneling work? thanks.

Describe the solution you'd like
Im looking for a user-friendly setup solution for this application in a QubesOS proxy-vm dedicated to setting up and maintaining a vpn connection (sys-vpn)

Is your feature request related to a problem? Please describe.
When I install this application in an appVM, it installs to the /opt/ directory and no root directories persist across reboots except /rw/

Additional context
This is the setup guide for a proxy-vm in QubesOS
https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts

I dont know if this is helpful but nordVPN have snap support for their VPN app: https://snapcraft.io/nordvpn-electron

It would be better security practice if I could verify if my downloaded VPN client has been subject to a MitM attack. A verifiable publication of sha512 or sha256 checksums would mitigate against that risk. Even better would be a PGP signature of the download or of a checksums file.

Here are the checksums of my download, please can you verify if these are correct?

$ sha512sum pia-linux-3.3.1-06924.run
b4375e95646816d704ea191a758c5bd02299939643d2d81e99e53dcdbecf6167395a339ccbabc8544e78f17ed8d9b845c6f4b9fd34fdff5c6eaeec30fdb56386 pia-linux-3.3.1-06924.run

$ sha256sum pia-linux-3.3.1-06924.run
eee140e511adfac4d74b059ed9d673f1b910163b5b92ac35642a65592fef639d pia-linux-3.3.1-06924.run

In the meanwhile, please can people post their checksums of pia-linux-3.3.1-06924.run below so we can begin some form of informal verification. Thanks.

Describe the bug
When setting the option "Icon style in menu bar" to "Auto", the menu bar icon is always dark, no matter if the other menu bar items are dark or white.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'settings' > 'General'
2. Click on 'Icon style in menu bar' (not sure about the English text, in German it is "Symbolstil im Infobereich")
3. Choose 'Auto'
4. The menu bar icon is now always dark, even if all other menu bar items are white

Expected behavior
The menu bar icon should automatically change the appearance according to the background image, e.g. when the macOS system menu bar items are in light mode, the PIA icon should be white, too, and only when the system menu bar items are in dark mode, the PIA icon should be dark.

This is a new feature on macOS 11 Big Sur where the icon appearance changes depending on the background image (menu bar set to transparent). I use several spaces with different background images, so on some spaces, the icons are white, and on some the icons are black. They change in realtime upon switching spaces. Except the PIA icon, which always remains dark.

Observed on:

• OS: macOS 11
• Version 11.2.3

Is your feature request related to a problem? Please describe.
.run file is fine. But, for Linux noobs who dislike terminal that will be quite problematic.

Describe the solution you'd like
Support .deb and appimage make installation easier

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
Yes. The problem is that on macOS, the settings page has no option to track the system light/dark mode, which makes for a bad experience when using automatic switching between light/dark in macOS.

Describe the solution you'd like
An automatic or "track system" option when selecting between light and dark mode in Settings > General > Theme. Additionally make sure that the system tray icon matches the system light/dark mode setting.

Describe alternatives you've considered
The only alternative solutions to automatic switching are changing the setting twice a day or it not matching the system theme half the day.

Additional context
None.

Thanks!

batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.

$ git-lfs filter-process
Error downloading object: brands/pia/gen_res/img/tray/sample-auto.png (e88793e): Smudge error: Error downloading brands/pia/gen_res/img/tray/sample-auto.png (e88793e7400fdc69ec82c9d778a34b525b0f6624a6cfd26d78897b1a404ff6cf):

Hello, I would like to request a cool feature that will make PIA VPN more awesome.

There's a feature in VyprVPN called "Connect on System Boot" on the Startup Options of their app.

Based on experience, it's really effective in tandem with kill switch wherein during login process on Windows. The VPN is already connected before their VPN application opens.

Thus, the user doesn't really have to worry about applications not loading properly due to internet connection anymore if the kill switch is enabled and the VPN is trying to connect during boot up process.

Reference Articles related to Connect on System Startup/System Boot
https://openvpn.net/community-resources/configuring-openvpn-to-run-automatically-on-system-startup/

https://openvpn.net/vpn-server-resources/use-openvpn-connect-v3-on-windows-in-service-daemon-mode/

sudo ./pia-linux-3.3.1-06924.run
# or
sudo bash pia-linux-3.3.1-06924.run
sudo sh pia-linux-3.3.1-06924.run
# or root
su
./pia-linux-3.3.1-06924.run

out:

pia-linux-3.3.1-06924.run: line 614: ./install.sh: Permission denied
# or
pia-linux-3.3.1-06924.run: 1: eval: ./install.sh: Permission denied

According to the instructions

The installer will prompt you for your [Root/Sudo] password (Note: do not run the installer with sudo)

But I have run it without sudo and the same result:

./pia-linux-3.3.1-06924.run

out

./pia-linux-3.3.1-06924.run: 1: eval: ./install.sh: Permission denied

chmod:

ls -l pia-linux-3.3.1-06924.run 
-rwxrwxrwx 1 user user 70857595 dic 23 16:32 pia-linux-3.3.1-06924.run

Ubuntu Mate 22.04.1 x64

Hi,

First I want to thank you for the wonderful job you do, the app is really good. There is an issue with the app that I've encountered.

App version: 2.8.1
System: Gentoo with OpenRC and NetworkManager.

Relevant info

In OpenRC in Gentoo the NetworkManager service status works in the following way (quote from a changelog):
"Change the NetworkManager OpenRC service to provide net; the service's status is set to 'inactive' when NetworkManager is running but has no connections up, and to 'started' when NetworkManager is connected"

How to reproduce
Just take Gentoo with OpenRC and NetworkManager and install the PIA app and set it to launch on system startup.

Description

When the computer starts, the NetworkManager service starts in the default runlevel. It shows at first 'inactive' status (this means that NetworkManager has started and has not established any connection yet, this is totally normal). After NetworkManager establishes a connection, the NetworkManager service status becomes 'started'. This is obviously a very bad choice of words by the OpenRC/NetworkManager developers, but this is how it is.

The piavpn service does not recognize 'inactive' status of NetworkManager, and starts only when the status of NetworkManager becomes 'started'. Because of that there is a time gap between the moment when NetworkManager has established a connection to the internet and the time when PIA app starts. During this time every app is able to connect directly without VPN (the killswitch starts working only after the PIA app has started).

Solution

The piavpn service should recognize that NetworkManager has started also when its status is 'inactive'. It will also make the connection to the VPN quicker, since the PIA app would start earlier.

I understand that Gentoo is not officially supported. I hope fixing this very small issue would be fine.

Describe the bug
I have Computer A connected to VPN with “Allow LAN Traffic” enabled. I have Computer B on the same subnet as Computer A and Computer C on a different subnet as Computer A.

Computer B is able to successfully ping Computer A. However, Computer C’s ping to Computer A times out. According to a packet trace on Computer A’s LAN interface, Computer A received the ICMP echo request but did not send the ICMP echo reply.

I am only able to reproduce the bug when “Split Tunnel” is disabled. When it is enabled (even with no rules), Computer C is able to successfully ping Computer A.

To Reproduce
Steps to reproduce the behavior:

1. Enable “Allow LAN Traffic” and disable “Split Tunnel”.
2. Turn on the VPN.
3. From a computer on a different subnet, ping the LAN address of the computer that is connected to VPN.
4. Observe that the ping times out.

Expected behavior
The ping should succeed.

Observed on:

• macOS 10.15.5
• Version 2.1 (build 04977)

Problem only started after upgrading to 1.7

Killswitch enabled
Allow LAN traffic enabled

Trying to copy files > ~50MB from another machine on my LAN always result in a connection time out. But used to work just fine prior to upgrade.

Small files *usually copy
Large files always connection time out
Problem eliminated when exiting PIA client

Linux Mint 19.3
Kernel 5.3.0-24-generic
PIA 1.7 build 03949

the latest commit on the master branch, 754080c, pushed a beta update.

wouldn't it be better to push only stable releases to the master branch, while pushing beta stuff in an aptly named beta branch?

Is your feature request related to a problem? Please describe.

I noticed while doing some network monitoring, that the PIA client on OSX will run latency ping checks about once per minute, and to some large number of servers each time. I found a reddit thread that confirms this suspicion. A user there found the relevant code and the latencyRefreshInterval that is set to one minute.

This check happens when the VPN is enabled, and when the VPN is disabled. If I am correct, that means my un-obscured IP address is being sent to some 100ish countries, once per minute, the entire time the daemon is running? That seems like a huge tradeoff, considering the information is only useful to display in some UI most people never see?

Based on the name of the app including "Private", I am to assume sending a very recognizable (and fingerprint-able) batch of requests, once per minute, to every continent in the world, is bordering on a bug. I submitted this request as a feature request, but honestly am not sure why a company that is privacy focussed would think this is a good idea? If the only goal is to generate a list of servers that are most easily accessed by the device, I can think of several more privacy-focused ways of accomplishing this, none of which require a connection to Mongolia or Kazakstan once per minute (picking a couple at random, the list is long).

Describe the solution you'd like

This should not happen by default, on an application designed to enhance user privacy.

I am happy to discuss alternatives in more depth, and am happy to contribute to the FOSS project if the team agrees this is a feature that is worth having? The change to the desktop app to provide a configuration option to disable this feature should be minimal. The changes required to implement a new solution will be slightly more complex, but still quite minimal. For example, a few small things that would make me much happier:

• Randomize the check interval
• Do not check all servers at once
• Change the default ping refresh from 1min per server to minimum 15min
• Allow user to select countries where they want to automatically ping check (most users will not change their physical country location once per minute, so probably pinging countries on the other side of the world will not help with automatic server selection)
• Use client-based heuristic to determine a list of viable servers based on known IP addresses. For example, a client in the US should be able to use its current public IP, and a known list of PIA IPs, to generate a list of anticipated best ping times based on geography (this can be augmented with anonymized data, but absolutely not required). Once a client has a list of likely best options, it tries each option in small batches (...with some jitter between requests), until it finds a clear winner

Describe alternatives you've considered

As someone who has supported PIA for years, all of these options are sad:

• Blocking pia-daemon with device networking rules
• Opening the PIA app less often
• Investigating competitor VPN clients to see if there are other companies who do not require this functionality

Additional context

it would be useful if one could give a label to each split-tunneling item.

if I have set up the IPs of 10 different servers for bypassing PIA, then I will have 10 different IPs in my settings, which makes it quite messy -- just imagine I have to delete an IP... which is which?
labels set up in such a way can also be specified as comments in the piavpn.r.305.allowSubnets iptables chain using the comment module.

e.g. from:

user@host:~$ sudo iptables -L piavpn.r.305.allowSubnets
Chain piavpn.r.305.allowSubnets (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             12.34.56.78

to:

user@host:~$ sudo iptables -L piavpn.r.305.allowSubnets
Chain piavpn.r.305.allowSubnets (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             12.34.56.78              /* PIA: label */

Describe the bug
The Install button doesn't work.
When there is an update, the Download button downloads the new version
The update button does nothing. I have to manually go to /opt/piavpn/var/update and run the update from there
After installing the update, the ChangeLog button does work

To Reproduce

1. Wait for a new update
2. Press "Download"
3. Press "Install"

Expected behavior
The update to install

Observed on:

• OS: Linux - Debian on Amd64
• Version: Buster
• Desktop Environment: LXQT

thanks
Mike

Shouldn't PIA make use of this new framework by now?

running piactl get pubip sometimes returns the wrong public IP address.
if an ISP leases the IP for a short period of time, say 24h, then an always-on computer with PIA smoothly running will get the correct answer to piactl get pubip only for the first day, then it will not refresh the ip, ever.

the PIA application should be instrumented to verify that the public IP is still current every few hours, to be able to use piactl get pubip reliably.

Describe the bug

I reported this to Help desk, but I wanted to make sure it got to a developer.

Symptoms include:

Unable to create Wintun interface: Error creating interface: No driver for device "Wintun" installed

Reinstalling Wintun via the Client interface has no effect.

Expected behavior

If the HKEY_LOCAL_MACHINE\SOFTWARE\Wintun key is present the pia-wintun.msi MSI appears to no-op. It appears that this may occur with using an old version of the MSM provided by WireGuard (I have not confirmed this was been fixed, I just lost where the code moved to).

This appears to mainly occur due to the check done in the MSM: https://git.zx2c4.com/wintun/tree/installer/msi.c?id=27e4d334fcd6b8d706fb0921fe501812622ca988#n95

Normally MSI should be able to repair this problem, but it appears the MSI is using CustomAction's with side-effects preventing normal healing operations (and possibly cleanup on uninstallation).

It's likely dangerous to modify the MSM. I would propose one of the following self-contained solution:

• When the PIA client is reinstalling the pia-wintun.msi, ensure the key HKEY_LOCAL_MACHINE\SOFTWARE\Wintun is removed before attempting to reinstall.

Observed on:

• OS: Windows 10/11

Describe the bug
Running the client on swaywm/wayland crashes with the following output:

[2021-06-29 13:58:29.534][ce87][json.settings][common/src/json.cpp:327][warning] Unable to read from clientsettings.json
[2021-06-29 13:58:29.534][ce87][default][client/src/linux/linux_env.cpp:21][info] XDG_CURRENT_DESKTOP= "sway"
[2021-06-29 13:58:29.534][ce87][default][client/src/linux/linux_env.cpp:69][info] Detected desktop "Unknown" and RTL: false
[2021-06-29 13:58:29.540][ce87][qt.qpa.plugin][info] Could not load the Qt platform plugin "wayland" in "" even though it was found.
[2021-06-29 13:58:29.540][ce87][default][fatal] This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
[2021-06-29 13:58:29.540][ce87][default][fatal] 
[2021-06-29 13:58:29.540][ce87][default][fatal] Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, webgl, xcb.
[2021-06-29 13:58:29.540][ce87][default][fatal] 
[1]    646897 abort (core dumped)  /opt/piavpn/bin/pia-client

To my understanding, this can be resolved by linking against LibQt5Wayland

A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:
In a fresh install of manjaro-sway or another minimal swaywm setup:

1. Install pia-client 2.9-06393
2. Run the client from a terminal

Expected behavior
The app should start and function normally using Qt's wayland library.

Observed on:

• OS: manjaro-sway
• Version current

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. I have all Prerequisites installed as it said in the doumentation but i got that strange error:

C:\Users\FL Studio\Documents\desktop>rake artifacts Architecture not known: "OSArchitecture=64-Bit" rake aborted! TypeError: no implicit conversion of nil into String C:/Users/FL Studio/Documents/desktop/rake/model/qt.rb:51:in "directory?" C:/Users/FL Studio/Documents/desktop/rake/model/qt.rb:51:in "initialize" C:/Users/FL Studio/Documents/desktop/rake/executable.rb:43:in "new" C:/Users/FL Studio/Documents/desktop/rake/executable.rb:43:in "<class:Executable>" C:/Users/FL Studio/Documents/desktop/rake/executable.rb:41:in "<top (required)>" C:/Users/FL Studio/Documents/desktop/Rakefile:2:in "require_relative" C:/Users/FL Studio/Documents/desktop/Rakefile:2:in "<top (required)>" (See full trace by running task with--trace)

Expected behavior
The builded project.
Observed on:

• OS: [Windows 10]

An option to minimize the client to tray on start up on Linux would be fantastic. I'm unsure if this exists already for windows/mac but as far as i can tell this is not possible on the Linux desktop client at the moment.

Is your feature request related to a problem? Please describe.
No. As of now, the PIA app doesn't support the importing of third-party VPN config files and the app is usable only for PIA users.

Describe the solution you'd like
Ability to import any VPN config files and allow the usage of the PIA app without a PIA account.

Describe alternatives you've considered
Windscribe VPN app has this feature. Their app can be used with any VPN provider's config files and doesn't need a Windscribe account.

Is your feature request related to a problem? Please describe.
Microsoft services do not work while connected to PIA. Things like Office 365 apps fail to connect / authenticate. Windows Store itself fails to log you in, etc.

Describe the solution you'd like
Allow an exception for Microsoft services.

Describe alternatives you've considered
A nice alternative may be to allow users to reverse the application exceptions list into an application target list. Where nothing is tunneled unless part of that list of applications. Generally, I only care about specific apps going over the VPN anyway.

Additional context

The installer at https://www.privateinternetaccess.com/installer/x/download_installer_linux
runs and completes fine on Manjaro Linux Arm 64 bit, but the binaries are compiled for x86_64 so they fail to run on aarch64, would it be possible to add aarch64 support to the installer?

can this be made pinephone compatible? It installs find under postmarketos. However, the client does not show on the screen when the program is launched.

it would be useful for all headless installations to be able to control split-tunneling via the command-line piactl tool.

for the time being, it would be awesome to get some clunky way to accomplish the same result, e.g. hard modifying the preferences to simulate what the GUI would have done, etc.

the feature has been proposed here, as well:
https://www.privateinternetaccess.com/helpdesk/community/view/split-tunnelling-through-command-line

at present, it is trivial to connect to the fastest-ping region via the command line:

piactl set region auto

which is great.

independently of the GUI settings, it would be awesome if we could invoke a similar command to connect to the fastest-ping region which supports port forwarding, e.g.:

piactl set region auto-port-forward

so that it could be invoked from a script.

I understand the same can be accomplished from the GUI, but I do not see the portforwarding as a global configuration -- it's more of a local configuration to be changed at will (outside of the GUI).

I don't want to be connected to a PF region all the time, but I would love to be able to connect to one via a script, if needed.

Is your feature request related to a problem? Please describe.
ifconfig, part of net-tools has not been updated since 2001, and is marked as deprecated/obsolete, and is not available on some distros, it's also not recommended to be used.

Describe the solution you'd like
Utilizing ip (iproute2) instead of ifconfig would allow better support for those distros that do not have access to ifconfig.

Describe alternatives you've considered
For now, of course it's possible for the user to maintain their own build of net-tools if it's not available in the distro's package management system, but it's an inconvinience when ip is available across all distros.

Additional context
https://www.reddit.com/r/linux4noobs/comments/bse3wm/is_ifconfig_deprecated/

https://ubuntu.com/blog/if-youre-still-using-ifconfig-youre-living-in-the-past

https://serverfault.com/questions/458628/should-i-quit-using-ifconfig

https://access.redhat.com/sites/default/files/attachments/rh_ip_command_cheatsheet_1214_jcs_print.pdf

https://linux.die.net/man/8/ifconfig

https://wiki.linuxfoundation.org/networking/net-tools

Describe the bug
Sometimes, after waking up from hibernation, Split Tunnel rules aren't applied properly.

My split tunnel is set to bypass VPN by default, with selected applications that should use the VPN.

For instance, I got 2 Firefox installations - with one excluded (implicitly) and one set to only VPN. However, it can happen that the excluded Firefox (the one that should bypass the VPN as its installation path exe is not configured in PIA) connects via the VPN anyway after I wake up from hibernation.

I found out about this due to a site I was logged onto saying my IP was blacklisted and subsequently verifying that the VPN connection was used in my excluded Firefox. There might be a race condition of some sort, perhaps?

Connection protocol used: Wireguard
DNS split mode: Follow app rules

To Reproduce
The issue seems intermittent, it happens most often after waking up from hibernating.

Expected behavior
Excluded applications should never connect via the VPN.

Observed on:
Windows 10 22H2 x64, PIA Client 3.3.1
2 independent PCs, one laptop, one desktop

Is your feature request related to a problem? Please describe.
IPv6 no longer functions on local network.

Describe the solution you'd like
Please re-enable the previously available option to NOT disable IPv6. I'm a big boy, I understand the risks. Give me the option.

Describe alternatives you've considered
Potentially allow IPv6 whitelisting instead. My internal network is a known IPv6 range. I would like to be able to communicate over my local LAN at the very least. Blackhole everything else?

Alternatively, support IPv6 in full

Additional context
N/A

Describe the bug
When I reconnect with PIA vpn, my custom DNS goes away, and in its place is a classic local DNS request.

To Reproduce
Steps to reproduce the behavior:

1. Go to Settings -> Network -> DNS -> Custom -> Primary 1.1.1.1 -> Secondary 8.8.8.8
2. /etc/resolv.conf is updated correctly

        nameserver 1.1.1.1
        nameserver 8.8.8.8

3. Disconnect and reconnect
4. /etc/resolv.conf is now set to a bad setting, which does not allow connection to the internet.

         # Generated by dhcpnameserver 8.8.8.8

         # /etc/resolv.conf.head can replace this line
        nameserver 10.0.2.1
        # /etc/resolv.conf.tail can replace this line

Expected behavior
It should maintain the resolv.conf

Observed on:
OS: Linux
Version: Arch Linux, Cinnamon DE

Description

My intrusion detection system is sending me alerts telling me it detected DShield-listed ICMP traffic from the following IP addresses to my computer:

• 185.200.118.154
• 185.200.118.156
• 185.200.118.157

After analyzing the network traffic on my computer, I found that pia-daemon was sending ICMP echo requests to these IP addresses (and my IDS was alerting me about the replies). However, my VPN was off.

Why is PIA pinging IP addresses when my VPN is off and why are they DShield-listed IP addresses?

Reproduction Steps

1. Leave VPN off.
2. Wait.
3. Periodically, pia-daemon will ping the above IP addresses. (I don’t see any pattern in when it does so.)

Expected Behavior

PIA should not send any network traffic when my VPN is off. Furthermore, the traffic should not be flagged by my intrusion detection system.

Observed On

• macOS 10.15.5
• Version 2.2.1 (build 05193)

Is your feature request related to a problem? Please describe.
On the Windows version, PIA apparently uses, but does not include, several binary libraries. I was updating an application, but was unable to, because several of its libraries were in use: libEGL.dll, libgcc_s_seh-1.dll, libGLESv2.dll, libstdc++-6.dll, and libwinpthread-1.dll. Trying to delete the same libraries manually via File Explorer showed that they were in use by PIA. My assumption is that the other application has its binaries in the system path, and PIA found them and opened them, preventing me from deleting them. My supposition is that PIA is using Qt5, which is in turn looking for plugin libraries for a GUI backend.

Describe the solution you'd like
I suggest moving these libraries to a subdirectory that is off the system path. Alternatively, linking them statically should also work.

Describe alternatives you've considered
I've also filed a bug against the other application, but this seems like a straightforward change that would prevent the problem defensively.

Hello.
I noticed three days ago that port forwarding has stopped working.
I tried connecting to various servers across the globe and according to the site canyouseeme.org none of the ports are forwarding properly. The error says that the connection has timed out. This was working fine and the site reported that ports were forwarding properly until three days ago when it seems to have suddenly stopped.

This happens when using either OpenVPN or Wireguard.

Steps to reproduce the behavior:

1. Connect to a server allowing port forwarding. Copy the port number
2. Go to https://canyouseeme.org and paste the port number to test
3. View error:
   Error: I could not see your service on XXX.XXX..207 on port (29721)
   Reason: Connection timed out

Expected behavior
Port should forward normally as before.

** Observed On**
Windows 11 64 bit
Firefox 103
Chrome 103.0.5060.134
PIA 3.3.1 (Build 03924)

** Troubleshooting Steps**

1. Re-installed TAP, WinTUN and Split Tunnel filters manually through the desktop application
2. Uninstalled and re-installed PIA five separate times.
3. Rebuilt TCP/IP stack via command prompt
4. Uninstalled all Ethernet and WiFi network adapters as well as removing related software via the Device Manager
5. Re-installed network adapters

Screen Shots:
https://ibb.co/Chy1mjQ
https://ibb.co/ZJ0GhC2

Describe the solution you'd like
I would like to know if there is some kind of document outside the repository that could resume the steps, for example in terms of terminal commands executed and code, to achieve Split Tunneling, especially on macOS.

Describe alternatives you've considered
I have tried to understand the solution by reading the code, but I still lack a complete understanding of it.

Additional context
I am referring to the macOS version of the project. Thanks a lot for your attention.

Please update the code here to match the current release or give a clear indication that the app is no longer open source, and why.

Describe the bug
When I enable Advanced kill switch and disconnect vpn qbittorent still keeps downloading, Internet access for other applications is blocked but not of qbittorent. I have tried toggeling all the options but still it is same. Even when I enable split tunnel and set VPN Only for qbittorent and it will still keep downloading when I turn off VPN.

Issue recreated in attached video.

Expected behavior
When I enable Advanced kill switch and split tunnel and set VPN Only for qbittorent and disconnect vpn, qbittorent should stop downloading.

Observed on:

• OS: Windows 10
• Version 3.2.0

ideally PIA should have some automation scripts built in their process to publish latest versions.

lacking that, PIA developers should still be able to manually publish the latest version in a timely fashion.

later version on GH at present is v 2.10.0 which is several months old, as opposed to the new version currently served by the PIA website, v 3.0.1 .

also, there does not seem to be a way to download ARM64 versions of the PIA app from the PIA website.

Describe the bug
Connecting to Wireguard does not work, the "VPN IP" remains blank and PIA attempts to reconnect about every 60 sec
Only working fix was to uninstall, boot into safe mode, reset network in windows network settings and reinstall. However After an additional reboot Wireguard stops working again.

To Reproduce
Steps to reproduce the behavior:

1. Attempt to connect to wireguard, it does not.
2. Uninstall PIA
3. Boot into safe mode with networking
4. Perform network reset from settings panel
5. Reboot into normal windows, reinstall PIA, Wireguard now connects fine
6. Reboot again
7. Go to step 1

Expected behavior
Connect to VPN via Wireguard

Observed on:

• OS: Windows 10
• Version 22H2 (OS Build 19045.2193)

Description

My intrusion detection system is sending me alerts telling me it detected DShield-listed ICMP traffic from the following IP addresses to my computer:

• 185.200.118.154
• 185.200.118.156
• 185.200.118.157

After analyzing the network traffic on my computer, I found that pia-daemon was sending ICMP echo requests to these IP addresses (and my IDS was alerting me about the replies). However, my VPN was off.

Why is PIA pinging IP addresses when my VPN is off and why are they DShield-listed IP addresses?

Reproduction Steps

1. Leave VPN off.
2. Wait.
3. Periodically, pia-daemon will ping the above IP addresses. (I don’t see any pattern in when it does so.)

Expected Behavior

PIA should not send any network traffic when my VPN is off. Furthermore, the traffic should not be flagged by my intrusion detection system.

Observed On

• macOS 10.15.5
• Version 2.2.1 (build 05193)

Is your feature request related to a problem? Please describe.
it is prominent that SteamOS users aka Steam Deck are growing fast and it will be great if PIA support it.

Describe the solution you'd like
there are lots of unofficial manual how to setup the PIA VPN on SteamOS and it will be great if PIA steps in to provide a guidance and lead the user

Describe alternatives you've considered
There are lots of unofficial instructions from Reddit

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
My intrusion detection system sent me an alert:

Threat Management Alert 1: Potential Corporate Privacy Violation. Signature ET DNS Non-DNS or Non-Compliant DNS traffic on DNS port Opcode 8 through 15 set. From: 192.168.1.10:53391, to: 199.116.118.176:53, protocol: UDP

The alert is saying a DNS request to 199.116.118.176 (a Total Server Solutions server) is using an unassigned DNS OpCode.

To Reproduce
Not sure yet… but if I remember correctly, the VPN was on.

Expected behavior
Any DNS requests should be standards-compliant.

Observed on:

• macOS 10.15.5
• Version 1.2 (build 04977)

running the latest PIA application on a headless server.

if I set the region to auto, how can I get the actual region I'm being connected to?

on the GUI it would show the region in parentheses, e.g. VPN Server: Auto (US California).
on the command line piactl get region just returns auto, which does not help at all.

Describe the bug
Much like the following bug from mullvadvpn: mullvad/mullvadvpn-app#3651

With the PIA desktop app installed it's throwing issues when trying to start an lxc/lxd container (see this forum thread: https://discuss.linuxcontainers.org/t/help-help-help-cgroup2-related-issue-on-ubuntu-jammy-with-mullvad-and-privateinternetaccess-vpn/14705/14

To Reproduce
Steps to reproduce the behavior:

1. Install LXD on any Linux distro that can install snaps (sudo snap install lxd)
2. Ensure PIA Desktop App is installed and running
3. Initialize LXD: sudo lxd init (just take all defaults)
4. Try to launch a basic ubuntu container: sudo lxc launch ubuntu:22.04 test
5. Container will fail to launch, use the following command to see log: sudo lxc info --show-log test
6. See error

Note: if you close PIA VPN than lxc can properly launch containers, this absolutely is caused by PIA's Desktop application.

Expected behavior
Mount net_cls anywhere else lol or alternatively add an env var/setting that will allow mounting net_cls somewhere else on a per user basis such as what was done here: mullvad/mullvadvpn-app#3660

Observed on:

• OS: Linux Mint 21.1
• OS Kernel: 5.15.0-56-generic
• Version 3.3.1

Is your feature request related to a problem? Please describe.
Currently there is no problem, but knowing Apple, they will want to remove x86_64 support from M1 asap. Better to get the native app done.

Describe the solution you'd like
After Qt 6.2 releases (expected at the end of September?) it should just take a few build system changes/script updates to compile for macOS arm64.

Describe alternatives you've considered
N/A

Additional context
N/A

The piactl utility currently allows you to run get vpnip and it returns your VPN connected IP address. However, there is no apparent command to return your non-VPN public IP. If you're setup to pass everything through the VPN it's difficult to get your public IP address otherwise (unless you split-tunnel curl or something).

I would love it if there was a piactl get pubip command to go along with vpnip I assume this is possible given that the GUI client shows this.