Description:

In v3.3.10, when zooming in/out while the geolocation API is updating the location info (i.e. on connecting/disconnecting state), if the user zooms in/out the map at the same time, the map will change positions abruptly.

Expected result:

The map should always keep the position when the user is zooming in or out.

Steps to reproduce:

1. Install v3.3.10 on e.g. macOS.
2. Login
3. Connect to the VPN.
4. During the connecting state, zoom in or out.
5. Observe that the map position changes abruptly.
6. Disconnect from the VPN.
7. During the disconnecting state, zoom in or out.
8. Observe that the map position changes abruptly.

Environment:

IVPN: v3.3.10
OS: All Platforms

Feature request

Description

As I hope the engineers at IVPN are aware of, the systemd init system that has been widely adopted by most Linux distros has caused huge concerns among the privacy community. There are already many distros that are centered specifically around not using systemd, which is considered a bloated, inefficient system, that loads pre-compiled blobs that are not open-source. There are many many resources online that expose the flaws of this init system that pushed onto everyone without any choice in the matter.
https://thehackernews.com/2019/01/linux-systemd-exploit.html
https://suckless.org/sucks/systemd/
http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html
https://chiefio.wordpress.com/2016/05/18/systemd-it-keeps-getting-worse/
http://without-systemd.org/wiki/index.php/Arguments_against_systemd
https://www.theregister.co.uk/2019/01/31/systemd_exploit/

Some of the biggest distros that are designed to not use it are the Debian-based Devuan (my friend uses with OpenRC), and the Arch-based Artix (i use, with OpenRC init)
https://artixlinux.org/index.php
https://devuan.org/

So my request is that for the sake of privacy, which I'm happy that IVPN has shown so far that they are truly concerned for, that other init systems be considered for the IVPN linux app

Some notable ones are OpenRC and s6. I could also help you guys test both of these init systems, especially OpenRC, since I use it every day.

Currently I'm running IVPN on my OpenRC Artix distro with a python implementation of systemd, to get around this restriction, but honestly this defeats my goal of complete privacy, since I'm using a system that has shady code to run my vpn service.

Please let me know what your thoughts are. As I said, I would love to help test this, since it benefits me directly.

Describe the solution you'd like

Solution is described above

Describe alternatives you've considered

workaround currently described above

Implement different colors for tray icon according to windows color scheme (dark\light):

• black icon for the light theme
• white icon for the dark theme

Bug report

Description
Users on Ubuntu 20.x+ are unable to connect with Obfsproxy enabled as the system uses obfs4proxy package instead of obfsproxy (obfs3).

obfproxy package is available only for Ubuntu 16 and 18. Ubuntu 20+ has only obfs4proxy available via default repositories.

Description:

On IVPN version 3.3.1, when Device A has enabled "Launch at login" and "Autoconnect at login" and Device B forces logout on Device A, if the user boots Device A, the IVPN will still connect when logged out, consequently there will be not connectivity in the user's device since the session is not active and the firewall will be active. The only option to solve the issue is either to uninstall the app or to use the command line to disconnect from IVPN.

Note:
See attached screenshot for further details.
The issue happens when WireGuard is the protocol selected.

Expected result:

When the user is forced logout in a different device, the device should not connect at system's launch successfully. When the device attempts the connects, the user should be logged out and the connection to the VPN should fail.

Steps to reproduce:

1. DEVICE A: Install version 3.3.1 e.g. Windows 10.
2. DEVICE A: Login.
3. DEVICE A: Enable "Launch at login" and "Autoconnect at launch"
4. DEVICE A: Turn the machine off.
5. DEVICE B: Reach the session limit and force the logout on DEVICE A.
6. DEVICE A: Boot the device.
7. DEVICE A: Observe that the app appears logout, but it's still connecting, so the user ends up logged out, but connected, although the session is not valid and since the firewall is enabled, the user will not have internet connection.

Environment:

IVPN: v3.3.1
Platforms: macOS and Windows

Screenshot:

When I go into the settings and change to Wireguard and try to connect, I get the above. Here are some relevant logs:

Jun  5 18:08:50.660 [wg    ] Installing service...
Jun  5 18:08:50.809 [wg    ] Waiting for service install...
Jun  5 18:08:50.809 [wg    ] Service installed
Jun  5 18:08:50.809 [wg    ] Waiting for service start...
Jun  5 18:08:51.119 [wg    ] Failed to install service. Uninstalling...
Jun  5 18:08:51.119 [wg    ] Disconnecting...
Jun  5 18:08:51.119 [wg    ] Uninstalling service...
Jun  5 18:08:51.137 [wg    ] Service uninstalled
Jun  5 18:08:51.137 [wg    ] Connection stopped
Jun  5 18:08:51.137 [servc ] ERROR service.go:712:(in github.com/ivpn/desktop-app-daemon/service.(*Service).connect): connection error: failed to install windows service: service start error: The service has not been started.
Jun  5 18:08:51.137 [servc ] Route change receiver stopped
Jun  5 18:08:51.137 [servc ] State: {DISCONNECTED failed to install windows service: service start error: The service has not been started. WireGuard 1622934531 false <nil> 0 <nil> 0  false false }
Jun  5 18:08:51.137 [prtcl ] [-->] VpnStateResp
Jun  5 18:08:51.137 [servc ] VPN state forwarder stopped
Jun  5 18:08:51.137 [servc ] VPN process stopped
Jun  5 18:08:51.137 [servc ] ERROR service.go:408:(in github.com/ivpn/desktop-app-daemon/service.(*Service).keepConnection): Connection error: connection error: failed to install windows service: service start error: The service has not been started.

I am also sending you guys the logs directly through the IVPN UI

Description:

In version 3.2.82, macOS, when closing the map, it is observed that the cursor does not change to pointer when hovering over the top menu icons.

Apparently this a known Electron issue which has been around for some years, link to the Electron issue - electron/electron#5723

Expected result:

When the map is closed, the selection pointer should be displayed when hovering over the menus on top

Steps to reproduce:

1. Install version 3.3.10 on macOS.
2. Login.
3. Close the map.
4. Place the cursor over the menu icons on top.
5. Observe that the selection pointer is not shown.

Environment:

IVPN: 3.3.10
Platforms: macOS Catalina, BigSur

Bug report

Describe your environment

• Device: _____
• OS name and version: OpenSUSE Tumbleweed Gnome
• IVPN app version: both daemon and apps are latest

Describe the problem

When installing the daemon, it doesn't ask you to install wiregurad-tools. If one doesn't manually install wiregurad-tools, WireGuard protocol won't work. I think the installation package should include wiregurad-tools as a required dependency to avoid this confusion.

Feature request

Description

Native Apple Silicon (ARM) builds for the new M1 Macs and future Apple chips.

Describe the solution you'd like

Native Apple Silicon builds for your macOS app.

Describe alternatives you've considered

The app does currently work fine in Rosetta 2, but as Apple is rolling out their ARM chips across all Macs within the next two years max it's a good idea to have native support. A native app should use less power on the machine as well.

P.S. Keep up the good work!

Bug report

Describe your environment

• Device: Dell XPS 9380
• OS name and version: Ubuntu Budgie 20.04.2 LTS
• IVPN app version: 3.3.7

Describe the problem

After the first boot and login, IVPN starts automatically at startup, but even if a known Wifi is set as trusted, the VPN connection remains active.

Steps to reproduce:

0. set up IVPN to run automatically at startup.
1. connect to Wifi and set it up as trusted.
2. reboot
3. log in and see that VPN is connected and Wifi is marked as trusted.

Expected Results:

• What did you expect to happen?
  I expected the VPN connection to be disabled automatically.

In certain Linux distributions, in those where the IVPN system tray icon is available, it is observed that the IVPN icon is displayed poorly. So far on Linux Mint and MX Linux.

We should improve the quality of the system tray icon, but since we are using the same icon in all distributions, this is not an easy task, therefore please consider this task for future releases.

Screenshot from Linux Mint of the actual icon:

On a side note, on Linux mint, when hovering over the system tray icon, the text ivpn-ui is displayed, this should be changed to IVPN.

Bug report

Describe your environment

• Device: desktop
• OS name and version: Fedora 34
• IVPN app version: v3.3.7 (ivpn-ui)

Describe the problem

ivpn-ui has .build-id collisions with 1Password.

I was able to find a number of other projects in a similar situation:

• jordansissel/fpm#1503
• atom/atom#19692
• bitwarden/desktop#277
• taw00/element-rpm#11

I do not fully understand whether .build-id files are used by the IVPN team, but if they're not, would it be possible to have these files excluded from the build process?

Steps to reproduce:

1. Install 1Password using the steps noted here for Fedora: https://support.1password.com/getting-started-linux/#centos-fedora-or-red-hat-enterprise-linux
2. Follow the IVPN installation steps here for Fedora: https://www.ivpn.net/apps-linux/#fedora

Observed Results:

file /usr/lib/.build-id/13/070cd6d4401903dee7a42e402d150de4362b18 from install of ivpn-ui-3.3.7-1.x86_64 conflicts with file from package 1password-8.0.33_39.BETA-1.x86_64 file /usr/lib/.build-id/3e/d503d7be965ab698b328fe3a69162a4efb5351 from install of ivpn-ui-3.3.7-1.x86_64 conflicts with file from package 1password-8.0.33_39.BETA-1.x86_64 file /usr/lib/.build-id/50/300d22dcba520f8681cbf4f8bd71ff9320371c from install of ivpn-ui-3.3.7-1.x86_64 conflicts with file from package 1password-8.0.33_39.BETA-1.x86_64 file /usr/lib/.build-id/5b/8864b69ddfe3bd034d5dbef9b814a8f9b59cbd from install of ivpn-ui-3.3.7-1.x86_64 conflicts with file from package 1password-8.0.33_39.BETA-1.x86_64 file /usr/lib/.build-id/ae/f8abf3f50b39abd59d73628e8cd89cceee8f54 from install of ivpn-ui-3.3.7-1.x86_64 conflicts with file from package 1password-8.0.33_39.BETA-1.x86_64 file /usr/lib/.build-id/af/4374e54497edac9a84703037832fafb0d99308 from install of ivpn-ui-3.3.7-1.x86_64 conflicts with file from package 1password-8.0.33_39.BETA-1.x86_64 file /usr/lib/.build-id/b4/fe1769dc0dbcd634d93f5ffd826d0354016f9e from install of ivpn-ui-3.3.7-1.x86_64 conflicts with file from package 1password-8.0.33_39.BETA-1.x86_64 file /usr/lib/.build-id/f0/d8c634c19103e2e50b980cc1fb5cbacdc8d07c from install of ivpn-ui-3.3.7-1.x86_64 conflicts with file from package 1password-8.0.33_39.BETA-1.x86_64 file /usr/lib/.build-id/f3/13677b4c4d959f49800be71689dc788f06ae94 from install of ivpn-ui-3.3.7-1.x86_64 conflicts with file from package 1password-8.0.33_39.BETA-1.x86_64

Expected Results:

I expected ivpn-ui to install properly.

Relevant Code:

https://github.com/ivpn/desktop-app-ui2/blob/master/References/Linux/build.sh

Include --rpm-rpmbuild-define "_build_id_links none" in fpm command (link)

Description
A user has reported that he is unable to start/stop/restart his localhost docker service when connected via our CLI app with Firewall and ‘Allow LAN’ option enabled.

The issue appears to be Firewall related and ‘Allow LAN’ option might not be working as intended. No issue occurs when he connects via NetworkManager using our config files.

VPN : CONNECTED
us-ga.gw.ivpn.net, Atlanta, GA (US), United States
Protocol : OpenVPN
Local IP : 10.48.16.5
Server IP : 107.150.22.74
Connected : 2020-06-03 06:30:29 -0400 AST
AntiTracker : Enabled
Firewall : Enabled
Allow LAN : true

Environment
IVPN Client 2.12.2

Fedora Workstation 32 (latest updates)

Steps To Reproduce

1. Connect to the OpenVPN (?WireGuard?) server with 'firewall -lan_allow' option
2. Run Start/Stop/Restart docker commands, e.g. "sudo systemctl start docker"
3. Observe the following error:
   "Job for docker.service failed because the control process exited with error code.
   See "systemctl status docker.service" and "journalctl -xe" for details."

Bug report

Describe your environment

On Linux, when updating IVPN from our repository, all settings are reset to default.

Describe the problem

Steps to reproduce:

1. Make sure you have added our testing repository (also run sudo apt-get update)
2. On e.g. Ubuntu, install version 2.3.67.
3. Login and set different settings, e.g. AntiTracker, auto-connect on launch, enable logging etc.
4. Run either sudo apt-get upgrade to update all packages or sudo apt-get install ivpn and sudo apt-get install ivpn-ui
5. Launch the IVPN app.
6. Observe that all settings are reset to default

In the list of servers, it is observed that single-line elements are centered vertically. Two-line elements are top-aligned, so we can see the second line. Therefore, the blank space between single-line elements is bigger.

We need to edit single-line elements alignment so we have the same spacing between elements.

See screenshot below of current implementation.

Environment:
IVPN: 3.3.10
Platforms: Windows 10, MacOS Catalina, Linux Ubuntu

Feature request

Description

For example:

• subnetworks that have to be processed as 'LAN': 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24
• the real (to which the computer belongs to) LAN network 192.168.1.5/24

The current implementation of 'Allow LAN' functionality permits the communication only with the network to which the computer belongs (192.168.1.5/24).
It could be a nice feature to have to be able manually to define additional 'LAN' networks which can be processed by 'Allow LAN' functionality

Describe the solution you'd like

So we would need some way for the user to specify which networks he considers local and for which he wants a static route added and for the FW to allow. The best UI would probably be a comma separated list of networks e.g. 192.168.20.0/24, 192.168.30/24, 192.168.40/24
or if the customer is lazy (could have some security consequences) 192.168.0.0/16

Describe alternatives you've considered

Have you considered any alternative solutions or workarounds?

Description

IVPN apps load connection information from IVPN API server (https://api.ivpn.net/v4/geo-lookup), in several cases:

• After app is launched
• After VPN is connected
• After VPN is disconnected

Current apps only load IPv4 information.

New version of apps will call /geo-lookup API with both IPv4 and IPv6 IP addresses by default.

Control panel IPv4/IPv6 tabs

When both IPv4 and IPv6 connection info is available, results needs to be visible in the Control panel.
A toggle is used to show IPv4 or IPv6 connection information.

Map IPv4/IPv6 tabs

When both IPv4 and IPv6 connection info is available, but location (city) is different, apps need to show "IPv4/IPv6" tabs on the map view with label "Location does not match".

API access with IP addresses

Our app are using a range of IPv4 addresses used as a fallback if API server cannot be reached with api.ivpn.net hostname.

When app is loading both IPv4 and IPv6 connection information from IVPN API server, app should use provided IPv4 and IPv6 IP address ranges, and not using hostname.

Description:

On Windows, Linux and macOS, when Device A has enabled "Always-on", but device B forces logout on Device A, when Device A logs back in, the firewall will be deactivated, but the option "Always-on" will still be enabled.

Expected result:

"Always-on" should be disabled after being forced logout e.g. due to reaching session limit on a different device.

Steps to reproduce:

1. DEVICE A: Install version 3.3.10 e.g. Windows 10.
2. DEVICE A: Login.
3. DEVICE A: Enable "Always-on" firewall and connect.
4. DEVICE B: Reach the session limit and force the logout on DEVICE A.
5. DEVICE A: Observe that the app logs the user out.
6. DEVICE A: Login and observe that the firewall is disabled, but the option "Always-on" is still enabled.

Environment:

IVPN: v3.3.10
Platforms: All platforms

Description:

On the latest linux beta version 3.3.10, any distribution, when adding IVPN to favourites and opening the app, two IVPN icons will be displayed in the system dock.

Note:
See attached screenshot for further details.

Expected result:

Only one IVPN icon should be displayed in the system dock.

Steps to rerproduce:

1. Install latest Linux version 3.0.12 (deb or rpm) on any system e.g. Ubuntu.
2. Click on Show Applications.
3. Right click in the IVPN icon.
4. Add IVPN to favourites.
5. Open the IVPN UI app.
6. Observe that two IVPN icons will be displayed in the dock.

Environment

IVPN version: 3.3.10
System: Ubuntu 20.04, Fedora 31

Screenshot;

Description:

In the latest Windows version 3.3.10, when updating the app, the old system tray icon is not removed, so the user will end up with two ivpn system tray icons.

Please note that once moving the cursor over the icons, Windows removes the old system tray icon.

Note:
See attached screenshot for further details.

Expected result:

Only one IVPN system tray icon should be shown after the update.

Steps to reproduce:

1. Install on Windows version e.g. 3.2.69.
2. Launch the app.
3. Once the update notification pops-up, update the app.
4. When the update is complete, observe two system tray icons.

Environment:

IVPN: 3.3.10
Platform: Windows 10

Screenshot:

Feature request

Description

This is a really nice feature on the Android version, that allows specific applications to not use the VPN tunnel, while pushing the remaining traffic through iVPN

Describe the solution you'd like

A UI to opt-in at the app or executable level

Describe alternatives you've considered

Desktop OS network routing might be less flexible at the app level 😦

In a future update for the IVPN App for Linux, I hope to see improved support for custom DNS addresses, like keweonDNS DoH/DoT addresses and that they can also include / and https:// strings.
The iOS app already supports this.

Split tunneling (at least on macOS)

Description

Allow users to specify which apps do / don't send traffic through the VPN connection.

Describe the solution you'd like

Ability to specify an inclusion / exclusion list of apps that will use the VPN.
I believe the ivpn Android app supports this already.

Describe alternatives you've considered

On Linux there are several options like Namespaces, but platforms such as macOS offer no realistic options for isolating binaries in this way. The sandboxing of binaries is inadequate and jails don't exist in macOS. A full VM might work, but is extremely heavy if we just want 1 app to go through the VPN. There might be some kind of proxy option, but really such as feature should be easy for users. Other VPN providers such as ExpressVPN support Split Tunneling, so it must be possible.

Bug report

Describe your environment

• Device: Windows 10 Pro
• OS name and version: _____
• IVPN app version: 3.3.10

Describe the problem

Icon files are created in the user's %temp% folder each time the app is launched and they are not removed. These icons are for the connection status in the system tray.

Steps to reproduce:

1. Launch the IVPN App one or more times.
2. Open Windows Explorer and go to %temp%
3. Confirm that 4 new icon files are created.

Observed Results:

Expected Results:

Icons should either be removed or only one set should be created or not created at all.

Relevant Code:

This setting should be disabled (or hidden) and on by default.

When user enabled IPv6 for VPN tunnel, this setting should became visible. 

When both "Enable IPv4" and "Show gateways without IPv6 support" are enabled, on the servers list there should be "IPv6" label next to servers that support IPv6.

It may be a good idea for greater compatibility with distros we don't currently support, also no dependancies on system libraries, puts our app into a sandbox for better security etc.

Description

With the current app implementation, there is a case when it is not possible to force login when reaching session limit with 2FA or captcha enabled.

Apps need to handle the case like this:

• 2FA or captcha code is sent to /session/new API
• If API returns "Too many sessions" response and user starts /session/new with force: true, app needs to also include 2FA or captcha code from the previous API call

Expected result

User should be able to force the login when reaching the session limit after entering the correct captcha or 2FA code.

Steps to reproduce

1. Login with 2FA until reaching the session limit.
2. Tap on "Logout from all other devices".
3. Observe the issue.
4. Repeat the same steps, but this time by reaching the session limit after entering the captcha code.

Allow users access to the IPv6 internet after they connect to the WireGuard VPN.

In current clients, WireGuard [Interface] is only configured with IPv4 address.By adding IPv6 address in the client config, VPN tunnel will have IPv6 traffic as well, when connected to gateway which support IPv6.

Example client config:

[Interface]
Address = 192.0.2.0,2001:0db8:0:0::2001:0db8/64
ListenPort = 51820
PrivateKey = <PrivateKey>
DNS = 198.51.100.0

[Peer]
PublicKey = <PublicKey>
AllowedIPs = 0.0.0.0/0,::/0
Endpoint = 203.0.113.0:2049
PersistentKeepalive = 25

There should be an option in the app settings that enables IPv6 inside VPN tunnel, which is off by

Add a button with Show (Anzeigen) and Hide (Verbergen)

Bug report

A customer reported a conflict with the IVPN App and the 1Password Linux client beta on Fedora 33.

https://support.1password.com/getting-started-linux/

I have replicated the issue and the cause seems to be related to unique debug paths and symlinks in /usr/lib/.build-id/ that are included in the ivpn-ui and 1Password RPM packages.

The /usr/lib/.build-id/ paths are symlinks are supposed to be unique, so it is unclear why they are included. It may be possible to disable debugging:
https://access.redhat.com/discussions/5045161#comment-1802881

Thanks.

Environment
Fedora 33

Steps To Reproduce

• install ivpn-ui
• install 1Password beta
• 1Password install fails due to /usr/lib/.build-id unique path conflicts

[j@localhost ~]$ sudo dnf install 1password
1Password                                       667  B/s | 833  B     00:01    
1Password                                       8.5 kB/s | 4.8 kB     00:00    
Importing GPG key ***:
 Userid     : "Code signing for 1Password <[email protected]>"
 Fingerprint: ****
 From       : https://downloads.1password.com/linux/keys/1password.asc
Is this ok [y/N]: y
1Password                                       1.1 kB/s | 1.9 kB     00:01    
Dependencies resolved.
================================================================================
 Package          Architecture  Version                  Repository        Size
================================================================================
Installing:
 1password        x86_64        8.0.33_53.BETA-1         1password         66 M

Transaction Summary
================================================================================
Install  1 Package

Total download size: 66 M
Installed size: 244 M
Is this ok [y/N]: y
Downloading Packages:
1password-8.0.33-53.BETA.x86_64.rpm                                                                                           5.1 MB/s |  66 MB     00:13    
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                         5.1 MB/s |  66 MB     00:13     
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
  file /usr/lib/.build-id/13/070cd6d4401903dee7a42e402d150de4362b18 from install of 1password-8.0.33_53.BETA-1.x86_64 conflicts with file from package ivpn-ui-3.3.10-1.x86_64
  file /usr/lib/.build-id/3e/d503d7be965ab698b328fe3a69162a4efb5351 from install of 1password-8.0.33_53.BETA-1.x86_64 conflicts with file from package ivpn-ui-3.3.10-1.x86_64
  file /usr/lib/.build-id/50/300d22dcba520f8681cbf4f8bd71ff9320371c from install of 1password-8.0.33_53.BETA-1.x86_64 conflicts with file from package ivpn-ui-3.3.10-1.x86_64
  file /usr/lib/.build-id/5b/8864b69ddfe3bd034d5dbef9b814a8f9b59cbd from install of 1password-8.0.33_53.BETA-1.x86_64 conflicts with file from package ivpn-ui-3.3.10-1.x86_64
  file /usr/lib/.build-id/ae/f8abf3f50b39abd59d73628e8cd89cceee8f54 from install of 1password-8.0.33_53.BETA-1.x86_64 conflicts with file from package ivpn-ui-3.3.10-1.x86_64
  file /usr/lib/.build-id/af/4374e54497edac9a84703037832fafb0d99308 from install of 1password-8.0.33_53.BETA-1.x86_64 conflicts with file from package ivpn-ui-3.3.10-1.x86_64
  file /usr/lib/.build-id/b4/fe1769dc0dbcd634d93f5ffd826d0354016f9e from install of 1password-8.0.33_53.BETA-1.x86_64 conflicts with file from package ivpn-ui-3.3.10-1.x86_64
  file /usr/lib/.build-id/f0/d8c634c19103e2e50b980cc1fb5cbacdc8d07c from install of 1password-8.0.33_53.BETA-1.x86_64 conflicts with file from package ivpn-ui-3.3.10-1.x86_64
  file /usr/lib/.build-id/f3/13677b4c4d959f49800be71689dc788f06ae94 from install of 1password-8.0.33_53.BETA-1.x86_64 conflicts with file from package ivpn-ui-3.3.10-1.x86_64

[j@localhost ~]$



[root@localhost ~]# ls -l /usr/lib/.build-id/13/070cd6d4401903dee7a42e402d150de4362b18
lrwxrwxrwx. 1 root root 40 Apr 23 12:19 /usr/lib/.build-id/13/070cd6d4401903dee7a42e402d150de4362b18 -> ../../../../opt/ivpn/ui/bin/libffmpeg.so
[root@localhost ~]# ls -l /usr/lib/.build-id/3e/d503d7be965ab698b328fe3a69162a4efb5351
lrwxrwxrwx. 1 root root 49 Apr 23 12:19 /usr/lib/.build-id/3e/d503d7be965ab698b328fe3a69162a4efb5351 -> ../../../../opt/ivpn/ui/bin/swiftshader/libEGL.so
[root@localhost ~]# ls -l /usr/lib/.build-id/50/300d22dcba520f8681cbf4f8bd71ff9320371c
lrwxrwxrwx. 1 root root 35 Apr 23 12:19 /usr/lib/.build-id/50/300d22dcba520f8681cbf4f8bd71ff9320371c -> ../../../../opt/ivpn/ui/bin/ivpn-ui
[root@localhost ~]# ls -l /usr/lib/.build-id/5b/8864b69ddfe3bd034d5dbef9b814a8f9b59cbd
lrwxrwxrwx. 1 root root 52 Apr 23 12:19 /usr/lib/.build-id/5b/8864b69ddfe3bd034d5dbef9b814a8f9b59cbd -> ../../../../opt/ivpn/ui/bin/swiftshader/libGLESv2.so
[root@localhost ~]# ls -l /usr/lib/.build-id/ae/f8abf3f50b39abd59d73628e8cd89cceee8f54
lrwxrwxrwx. 1 root root 40 Apr 23 12:19 /usr/lib/.build-id/ae/f8abf3f50b39abd59d73628e8cd89cceee8f54 -> ../../../../opt/ivpn/ui/bin/libGLESv2.so
[root@localhost ~]# ls -l /usr/lib/.build-id/af/4374e54497edac9a84703037832fafb0d99308
lrwxrwxrwx. 1 root root 37 Apr 23 12:19 /usr/lib/.build-id/af/4374e54497edac9a84703037832fafb0d99308 -> ../../../../opt/ivpn/ui/bin/libEGL.so
[root@localhost ~]# ls -l /usr/lib/.build-id/b4/fe1769dc0dbcd634d93f5ffd826d0354016f9e
lrwxrwxrwx. 1 root root 42 Apr 23 12:19 /usr/lib/.build-id/b4/fe1769dc0dbcd634d93f5ffd826d0354016f9e -> ../../../../opt/ivpn/ui/bin/chrome-sandbox
[root@localhost ~]# ls -l /usr/lib/.build-id/f0/d8c634c19103e2e50b980cc1fb5cbacdc8d07c
lrwxrwxrwx. 1 root root 42 Apr 23 12:19 /usr/lib/.build-id/f0/d8c634c19103e2e50b980cc1fb5cbacdc8d07c -> ../../../../opt/ivpn/ui/bin/libvulkan.so.1
[root@localhost ~]# ls -l /usr/lib/.build-id/f3/13677b4c4d959f49800be71689dc788f06ae94
lrwxrwxrwx. 1 root root 48 Apr 23 12:19 /usr/lib/.build-id/f3/13677b4c4d959f49800be71689dc788f06ae94 -> ../../../../opt/ivpn/ui/bin/libvk_swiftshader.so
Checking the RPM packages shows that both `ivpn-ui-3.3.10-1.x86_64.rpm` and `1password-8.0.33-53.BETA.x86_64.rpm` include the same unique `/usr/lib/.build-id/` paths and files:

[j@localhost ~]$ rpm -qlp ivpn-ui-3.3.10-1.x86_64.rpm
/opt/ivpn/ui/IVPN.desktop
/opt/ivpn/ui/bin/LICENSE.electron.txt
/opt/ivpn/ui/bin/LICENSES.chromium.html
/opt/ivpn/ui/bin/chrome-sandbox
/opt/ivpn/ui/bin/chrome_100_percent.pak
/opt/ivpn/ui/bin/chrome_200_percent.pak
/opt/ivpn/ui/bin/icudtl.dat
/opt/ivpn/ui/bin/ivpn-ui
/opt/ivpn/ui/bin/libEGL.so
/opt/ivpn/ui/bin/libGLESv2.so
/opt/ivpn/ui/bin/libffmpeg.so
/opt/ivpn/ui/bin/libvk_swiftshader.so
/opt/ivpn/ui/bin/libvulkan.so.1
/opt/ivpn/ui/bin/locales/am.pak
...
/opt/ivpn/ui/bin/locales/zh-TW.pak
/opt/ivpn/ui/bin/resources.pak
/opt/ivpn/ui/bin/resources/app.asar
/opt/ivpn/ui/bin/resources/public.pem
/opt/ivpn/ui/bin/snapshot_blob.bin
/opt/ivpn/ui/bin/swiftshader/libEGL.so
/opt/ivpn/ui/bin/swiftshader/libGLESv2.so
/opt/ivpn/ui/bin/v8_context_snapshot.bin
/opt/ivpn/ui/bin/vk_swiftshader_icd.json
/opt/ivpn/ui/ivpnicon.svg
/usr/lib/.build-id
/usr/lib/.build-id/13
/usr/lib/.build-id/13/070cd6d4401903dee7a42e402d150de4362b18
/usr/lib/.build-id/3e
/usr/lib/.build-id/3e/d503d7be965ab698b328fe3a69162a4efb5351
/usr/lib/.build-id/50
/usr/lib/.build-id/50/300d22dcba520f8681cbf4f8bd71ff9320371c
/usr/lib/.build-id/5b
/usr/lib/.build-id/5b/8864b69ddfe3bd034d5dbef9b814a8f9b59cbd
/usr/lib/.build-id/ae
/usr/lib/.build-id/ae/f8abf3f50b39abd59d73628e8cd89cceee8f54
/usr/lib/.build-id/af
/usr/lib/.build-id/af/4374e54497edac9a84703037832fafb0d99308
/usr/lib/.build-id/b4
/usr/lib/.build-id/b4/fe1769dc0dbcd634d93f5ffd826d0354016f9e
/usr/lib/.build-id/f0
/usr/lib/.build-id/f0/d8c634c19103e2e50b980cc1fb5cbacdc8d07c
/usr/lib/.build-id/f3
/usr/lib/.build-id/f3/13677b4c4d959f49800be71689dc788f06ae94
[root@localhost 1p]# rpm -qlp 1password-8.0.33-53.BETA.x86_64.rpm 
/opt/1Password/1Password-BrowserSupport
/opt/1Password/1Password-KeyringHelper
/opt/1Password/1password
/opt/1Password/LICENSE.electron.txt
/opt/1Password/LICENSES.chromium.html
/opt/1Password/after-install.sh
/opt/1Password/after-remove.sh
/opt/1Password/chrome-sandbox
/opt/1Password/chrome_100_percent.pak
/opt/1Password/chrome_200_percent.pak
/opt/1Password/com.1password.1Password.policy
/opt/1Password/icudtl.dat
/opt/1Password/install_biometrics_policy.sh
/opt/1Password/libEGL.so
/opt/1Password/libGLESv2.so
/opt/1Password/libffmpeg.so
/opt/1Password/libvk_swiftshader.so
/opt/1Password/libvulkan.so.1
/opt/1Password/locales/am.pak
...
/opt/1Password/locales/zh-TW.pak
/opt/1Password/resources.pak
/opt/1Password/resources/1password.desktop
/opt/1Password/resources/app.asar
/opt/1Password/resources/app.asar.unpacked/CREDITS.html
/opt/1Password/resources/app.asar.unpacked/index.node
/opt/1Password/resources/custom_allowed_browsers
/opt/1Password/resources/icons/hicolor/256x256/apps/1password.png
/opt/1Password/resources/icons/hicolor/32x32/apps/1password.png
/opt/1Password/resources/icons/hicolor/512x512/apps/1password.png
/opt/1Password/resources/icons/hicolor/64x64/apps/1password.png
/opt/1Password/snapshot_blob.bin
/opt/1Password/swiftshader/libEGL.so
/opt/1Password/swiftshader/libGLESv2.so
/opt/1Password/v8_context_snapshot.bin
/opt/1Password/vk_swiftshader_icd.json
/usr/lib/.build-id
/usr/lib/.build-id/13
/usr/lib/.build-id/13/070cd6d4401903dee7a42e402d150de4362b18
/usr/lib/.build-id/3e
/usr/lib/.build-id/3e/d503d7be965ab698b328fe3a69162a4efb5351
/usr/lib/.build-id/50
/usr/lib/.build-id/50/300d22dcba520f8681cbf4f8bd71ff9320371c
/usr/lib/.build-id/5b
/usr/lib/.build-id/5b/8864b69ddfe3bd034d5dbef9b814a8f9b59cbd
/usr/lib/.build-id/9d
/usr/lib/.build-id/9d/41f958929cbe6474f668de4c96432a4c99ba88
/usr/lib/.build-id/a7
/usr/lib/.build-id/a7/033af106723fab4aee68536984ae7ffc8cc522
/usr/lib/.build-id/ae
/usr/lib/.build-id/ae/f8abf3f50b39abd59d73628e8cd89cceee8f54
/usr/lib/.build-id/af
/usr/lib/.build-id/af/4374e54497edac9a84703037832fafb0d99308
/usr/lib/.build-id/b4
/usr/lib/.build-id/b4/fe1769dc0dbcd634d93f5ffd826d0354016f9e
/usr/lib/.build-id/f0
/usr/lib/.build-id/f0/d8c634c19103e2e50b980cc1fb5cbacdc8d07c
/usr/lib/.build-id/f3
/usr/lib/.build-id/f3/13677b4c4d959f49800be71689dc788f06ae94
/usr/share/applications/1password.desktop
/usr/share/icons/hicolor/256x256/apps/1password.png
/usr/share/icons/hicolor/32x32/apps/1password.png
/usr/share/icons/hicolor/512x512/apps/1password.png
/usr/share/icons/hicolor/64x64/apps/1password.png
Note: I removed most of the `/locales/` to try to keep this shorter.

The `ivpn-3.3.7-1.x86_64.rpm` does not include these paths:

$ rpm -qlp ivpn-3.3.7-1.x86_64.rpm 
/opt/ivpn/etc/ca.crt
/opt/ivpn/etc/client.down
/opt/ivpn/etc/client.up
/opt/ivpn/etc/firewall.sh
/opt/ivpn/etc/servers.json
/opt/ivpn/etc/ta.key
/usr/lib/.build-id
/usr/lib/.build-id/fc
/usr/lib/.build-id/fc/397197e3ee1aa130951239ee94cd15bc9e17f0
/usr/local/bin/ivpn
/usr/local/bin/ivpn-service
/usr/share/pleaserun/ivpn-service/generate-cleanup.sh
/usr/share/pleaserun/ivpn-service/install-path.sh
/usr/share/pleaserun/ivpn-service/install.sh
/usr/share/pleaserun/ivpn-service/launchd/10.9/files/Library/LaunchDaemons/ivpn-service.plist
/usr/share/pleaserun/ivpn-service/launchd/10.9/install_actions.sh
/usr/share/pleaserun/ivpn-service/systemd/default/files/etc/default/ivpn-service
/usr/share/pleaserun/ivpn-service/systemd/default/files/etc/systemd/system/ivpn-service.service
/usr/share/pleaserun/ivpn-service/systemd/default/install_actions.sh
/usr/share/pleaserun/ivpn-service/sysv/lsb-3.1/files/etc/default/ivpn-service
/usr/share/pleaserun/ivpn-service/sysv/lsb-3.1/files/etc/init.d/ivpn-service
/usr/share/pleaserun/ivpn-service/upstart/0.6.5/files/etc/default/ivpn-service
/usr/share/pleaserun/ivpn-service/upstart/0.6.5/files/etc/init/ivpn-service.conf
/usr/share/pleaserun/ivpn-service/upstart/1.5/files/etc/default/ivpn-service
/usr/share/pleaserun/ivpn-service/upstart/1.5/files/etc/init/ivpn-service.conf

Bug report

Describe your environment

1. Connect VPN (any protocol)
   1.1 (not obligatory step) We can also set custom DNS or enable AntiTracker
2. Check OS DNS config - DNS is OK
3. Disable WiFi
4. Enable WIFI (for OpenVPN connection: enable WiFi in less than 30 seconds after wifi was disabled)
5. Check OS DNS

Expected:
OS is using IVPN DNS (or custom DNS, if defined)

Observed:
OS is using the default DNS server (non-IVPN configured).
If the IVPN firewall is enabled -> user is unable to use web browsers because the default DNS is blocked by the firewall.

Possible solution

The app has to monitor all changes to the DNS configuration on a computer and fix it (when required)

Bug report

Describe your environment

• Device: Desktop
• OS name and version: Fedora Workstation 33
• IVPN app version: Client v.3.2.3, Daemon v2.12.16

Describe the problem

Steps to reproduce:

1. Install obfsproxy using sudo pip install obfsproxy
2. Set IVPN to use obfsproxy
3. Try to connect to a VPN server

Observed Results:

• What happened? This could be a description, log output, etc.
  IVPN will only look for the obfsproxy binary at /usr/bin/obfsproxy, while pip will actually install it it at /usr/local/bin/obfsproxy. Of course, if obfsproxy is installed as a user app, it will be at another location as well.

Expected Results:

IVPN should attempt to look for the obfsproxy binary at other common places (such as /usr/local/bin/obfsproxy) instead of the 1 path it is doing right now. In fact, as of now, I don't know of a way to make it work with obfsproxy yet.

When the map is closed the IP connection info (Your IP, location, ISP) is half visible at the bottom and requires scrolling. Move this information up to below “Connection details” so it's more prominent since its part of our customers “proof” and it should be very visible.

For consistency it should remain here even when the map is opened.

Bug report

Describe your environment

A customer reported an issue where the IVPN App leaves files on the system after an uninstall.

I have replicated the issue on a Windows 10 system with v2.10.3. Some of the remnants are .lnk files inside the user profile, though there are TAP driver files that remain in the C:\Win\Sys32 folder.

Thanks.

Describe the problem

Steps to reproduce:

• Exit the IVPN App.
• Run the uninstaller.exe inside the IVPN folder in 'Program Files'.
• Reboot.
• Open a Command Prompt.
• Run: dir ivpn.* /s
• Notice entries remain in C:\Windows\System32\drivers\ and ...\System32\DriverStore\

Feature request

Description

In my opinion the cli tool should be able to toggle killswitch capabilities.
At the moment the only way to have a killswtich set up in a pure command line environment is a fully manual configuration.

Bug report

Describe your environment

• Device: Apple hardware
• OS name and version: macOS 11.3.1
• IVPN app version: 3.3.10

Describe the problem

On macOS, [there is] an issue when I have Custom DNS configured to use my local DNS server IP. Even when that is configured, it still uses the IVPN resolver, which means it isn't using the DNS search domains configured with my local DNS.

As a result, I'm unable to connect to a network share using a hostname such as smb://NAS.local.lan

Steps to reproduce:

1. Set a custom DNS server
2. Connect the VPN
3. Run scutil --dns to check the search domain

Observed Results:

$ scutil --dns

# Connected with AntiTracker enabled:

resolver #1
  search domain[0] : ivpn-client
  nameserver[0] : 10.0.254.2

# Connected with Custom DNS set to 1.1.1.1:

resolver #1
  search domain[0] : ivpn-client
  nameserver[0] : 1.1.1.1

# Disconnected:

resolver #1
  search domain[0] : domain.local
  nameserver[0] : 192.168.0.1

# Connected, Custom DNS set to local router, search domain set to local domain name
  
$ networksetup -setsearchdomains Ethernet local.lan
$ scutil --dns

resolver #1
  search domain[0] : domain.local
  nameserver[0] : 192.168.0.1
  
# Reset search domain 

$ networksetup -setsearchdomains Ethernet empty

Expected Results:

Use the resolver and search domains specified by the IP address when using the Custom DNS option. This works as expected on a different VPN provider (Private Internet Access)

Relevant Code:

n/a

Add "Allow access to IVPN servers when Firewall is enabled" option to enable/disabled to the CLI

Description

On latest beta 3.3.16, Windows 10, when the user connects with WireGuard and goes to the Settings, once the user goes back to the main screen, the map locations will be out of place instead of focusing in the location the user is connected to.

Note:
The issue ONLY happens on Windows AND with WireGuard.

Expected result

The map should always focus in the location the user is connected to.

Steps to reproduce

1. Install version 3.3.16.
2. Login.
3. With WireGuard, connect.
4. While the app is establishing connection, go to Settings.
5. Go back to the main screen, map.
6. Observe the issue.

Bug report

Describe your environment

• Device: _____
• OS name and version: Windows 10
• IVPN app version: 3.3.10

Describe the problem

Hover the mouse cursor over the Windows network icon in the system tray after the VPN is connected and the WireGuard interface has a number on it. This number is incremented with each connection and persists through a reboot.

Steps to reproduce:

1. Connect via WireGuard.
2. Check the Network icon in the system tray.
3. Disconnect, reconnect, and check the Network icon again.

Observed Results:

The counter increases with each connection and this could be seen as "annoying".

Expected Results:

Use a consistent and non-changing interface name for the WireGuard connection's interface.

Bug report

Describe your environment

• Device: _____
• OS name and version: OpenSUSE Tumbleweed Gnome
• IVPN app version: 3.3.10

Describe the problem

I have always-on firewall enabled. It just happened in the recent days that the app cannot regenerate Wireguard keys on reboot and I had to manually disable always-on firewall to regenerate keys.

Bug report

Describe your environment

• Device: PC
• OS name and version: Arch Linux, using systemd-networkd and systemd-resolved.
• IVPN app version: Latest

Describe the problem

When using the CLI, the DNS being used doesn't appear to change. This is unexpected to me, because the NordVPN client does exactly this somehow.

Steps to reproduce:

1. Connect to VPN with the CLI
2. Notice that DNS queries are still going to the old DNS provider.

Bug report

Describe your environment

• Device: _____
• OS name and version: OpenSUSE Tumbleweed Gnome
• IVPN app version: 3.3.10

I set my desktop to dark mode, and I set Settings -> General -> Color theme to "system default". Normally it follows my system-wide dark mode. But if I set VPN to autoconnect on reboot, on reboot, "system default" color theme no longer recognises system-wide dark mode.

Description:

On version 3.3.10, all platforms, when failing to manually generate WG keys e.g. due to no internet connection, the app shows the following error.

Expected result:

The error presented to the user should describe the problem accurately.

Steps to reproduce:

1. Install version 3.3.10
2. Login.
3. Turn off WIFI.
4. Attempt to generate manually a WG key.
5. Observe the error.

Environment:

IVPN: v3.3.10
Platforms: All

Bug report

Describe your environment

A user experiencing a long connection time on WireGuard (>5 seconds)

According to the logs which were provided, there are two long delays during connection:

1. initializing WG tunnel (starting a separate WG process wireguard-go) (~3 sec)
2. configuring WireGuard channel by starting separate process wg setconf (~3 sec)

The first impression is that the user's system took much time to run new processes (in our case - WireGuard binaries).

Description:

Currently, the update notification is shown in the following scenarios:

• 5 seconds after UI starts
• when a user manually clicks "Check For Updates"
• Automatically every 12 hours

However, on Windows, at application start, if there is not connectivity such as when the user has enabled "Always-on Firewall", the update notification doesn't show up, not even when the app connects to the VPN and the connectivity is reestablished.

This has been mainly observed on Windows, on macOS works as expected, the update notification is shown when the app connects to the VPN.

Expected:

Therefore, It is suggested to show the update notification at application start ALSO when the user reestablishes the connection by connecting to the VPN.

Environment:

IVPN: 3.3.10
Platform: Windows 10

Please offer a gpg signature of binaries

Description

GitHub / website hosting infrastructure, certificate authorities, (or anyone with access to these) may try to post fake VPN binaries and try to trick users into installing them. While this may be remote, such a risk is dramatically reduced or eliminated through the use of OpenPGP digital signatures. Ideally signing keys should be kept on hardware smartcard such as Yubikey, Nitrokey, etc.

Describe the solution you'd like

In order to reduce trust on GitHub / website hosting infrastructure, certificate authorities, etc -- please make gpg signatures available for each binary. Another option is to sha256 hash all binaries and sign that list once.

Describe alternatives you've considered

The sha256 hash on the website is inadequate when trying to verify authenticity -- both are hosted on the same platform, so an attacker should just replace the hash with their own.

Description

In version 3.3.10 (or latest beta, 3.3.12), all platforms, when logging in with a Standard account and reaching the session limit, clicking on the button "Upgrade your subscription" doesn't do anything.

Expected result:

Clicking on "Upgrade your subscription" should redirect the user to the website - client area.

Steps to reproduce:

1. On any desktop platform, reach the device limit screen upon login with a Standard account.
2. Click on "Upgrade your subscription"
3. Observe the issue

Environment:

IVPN: v3.3.10
OS: All Platforms

Description:

On all platforms, version 3.3.10, MultiHop, when selecting Random Server as the exit server and then changing the exit server in the map (everything while connected), once disconnecting from the VPN, the exit server will still be Random Server instead of the last server selected in the map.

Expected result:

The exit server should always be the last selected server, either in the map or in the list of servers.

Steps to reproduce:

1. Install version 3.3.10 on Windows or macOS.
2. Login with a Pro account.
3. Select OpenVPN + MultiHop.
4. Enable connection by selecting a server in the map.
5. Connect to any entry/exit servers.
6. Select Random server in the list of servers as the exit server.
7. Connect to different servers through the map.
8. Disconnect from VPN.
9. Observe that the exit sever is "Random Server" instead of the last server selected in the map.

Environment:

IVPN: v.3.3.10
Platforms: Windows 10, macOS Catalina, BigSur, Linux Ubuntu

Description:

Currently, each protocol can have a different fastest server configuration to be used as the fastest servers.

The fastest server configuration should be the same for all protocols, so even if the server lists differs, if user deselect one location, it should be saved for all protocols.

Note:
Already implemented on iOS.

Environment:

IVPN: 3.3.10
Platforms: All