pia-foss / desktop Goto Github PK
View Code? Open in Web Editor NEWPrivate Internet Access - Desktop VPN Client for Windows/macOS/Linux
License: Other
Private Internet Access - Desktop VPN Client for Windows/macOS/Linux
License: Other
Shouldn't PIA make use of this new framework by now?
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.
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?
pia-daemon
will ping the above IP addresses. (I don’t see any pattern in when it does so.)PIA should not send any network traffic when my VPN is off. Furthermore, the traffic should not be flagged by my intrusion detection system.
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:
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.
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:
pia-client
on a HiDPI machine.Expected behavior
The tray menu should observe the same scaling rules as the app window.
Observed on:
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
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:
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
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:
nameserver 1.1.1.1
nameserver 8.8.8.8
# 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
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:
Expected behavior
The ping should succeed.
Observed on:
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:
Describe alternatives you've considered
As someone who has supported PIA for years, all of these options are sad:
Additional context
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.
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):
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.
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
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
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:
pia-wintun.msi
, ensure the key HKEY_LOCAL_MACHINE\SOFTWARE\Wintun
is removed before attempting to reinstall.Observed on:
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:
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:
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
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:
sh pia-linux-arm64-2.9-00032.debug.run
.pia-client
process running.Expected behavior
The client's GUI should launch and the pia-client process should be running.
Observed on:
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.
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?
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
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:
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.
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.
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.
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/
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
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:
sudo snap install lxd
)sudo lxd init
(just take all defaults)sudo lxc launch ubuntu:22.04 test
sudo lxc info --show-log test
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:
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?
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:
Expected behavior
The app should start and function normally using Qt's wayland library.
Observed on:
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:
Expected behavior
Connect to VPN via Wireguard
Observed on:
$ git lfs install
$ git clone https://github.com/pia-foss/desktop.git pia-desktop
Cloning into 'pia-desktop'...
remote: Enumerating objects: 10395, done.
remote: Counting objects: 100% (3676/3676), done.
remote: Compressing objects: 100% (2225/2225), done.
remote: Total 10395 (delta 1807), reused 2810 (delta 1371), pack-reused 6719
Receiving objects: 100% (10395/10395), 56.48 MiB | 15.41 MiB/s, done.
Resolving deltas: 100% (5248/5248), done.
Downloading brands/pia/gen_res/img/tray/sample-auto.png (1.6 KB)
Error downloading object: brands/pia/gen_res/img/tray/sample-auto.png (a70d879): Smudge error: Error downloading brands/pia/gen_res/img/tray/sample-auto.png (a70d879b122d80c3db6e66084670cb5afde09842972af27e740fb59894549979): batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
Errors logged to '/home/triffid/Projects/pia-desktop/.git/lfs/logs/20221010T213233.230265197.log'.
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: brands/pia/gen_res/img/tray/sample-auto.png: smudge filter lfs failed
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'
pia-desktop $ git lfs pull
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
Failed to fetch some objects from 'https://github.com/pia-foss/desktop.git/info/lfs'
$ QTROOT=/usr/include/qt5/QtCore/5.15.5 rake --trace
Found Qt: /usr/include/qt5/QtCore/5.15.5
note: Different patch number from preferred version 5.15.2
Host: x86_64 -
Target: x86_64 -
Detected clang 14 at /usr/lib/llvm/14/bin (/usr/lib/llvm/14/bin/clang, /usr/lib/llvm/14/bin/clang++)
rake aborted!
Repository was not cloned with LFS. Set up Git LFS and update; see README.md
/home/triffid/Projects/pia-desktop/Rakefile:19:in `<top (required)>'
/usr/lib64/ruby/gems/2.7.0/gems/rake-13.0.3/lib/rake/rake_module.rb:29:in `load'
/usr/lib64/ruby/gems/2.7.0/gems/rake-13.0.3/lib/rake/rake_module.rb:29:in `load_rakefile'
/usr/lib64/ruby/gems/2.7.0/gems/rake-13.0.3/lib/rake/application.rb:703:in `raw_load_rakefile'
/usr/lib64/ruby/gems/2.7.0/gems/rake-13.0.3/lib/rake/application.rb:104:in `block in load_rakefile'
/usr/lib64/ruby/gems/2.7.0/gems/rake-13.0.3/lib/rake/application.rb:186:in `standard_exception_handling'
/usr/lib64/ruby/gems/2.7.0/gems/rake-13.0.3/lib/rake/application.rb:103:in `load_rakefile'
/usr/lib64/ruby/gems/2.7.0/gems/rake-13.0.3/lib/rake/application.rb:82:in `block in run'
/usr/lib64/ruby/gems/2.7.0/gems/rake-13.0.3/lib/rake/application.rb:186:in `standard_exception_handling'
/usr/lib64/ruby/gems/2.7.0/gems/rake-13.0.3/lib/rake/application.rb:80:in `run'
/usr/lib64/ruby/gems/2.7.0/gems/rake-13.0.3/exe/rake:27:in `<top (required)>'
/usr/bin/rake:9:in `load'
/usr/bin/rake:9:in `<main>'
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:
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**
Screen Shots:
https://ibb.co/Chy1mjQ
https://ibb.co/ZJ0GhC2
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.
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
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
Expected behavior
The update to install
Observed on:
thanks
Mike
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.
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.
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.
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
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.
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?
pia-daemon
will ping the above IP addresses. (I don’t see any pattern in when it does so.)PIA should not send any network traffic when my VPN is off. Furthermore, the traffic should not be flagged by my intrusion detection system.
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.
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
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.
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
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.