Feature request

Currently, the IVPN Client erasing application configuration when a user logs out.

This has to be changed:

1. keep unchanged the app configuration on logout by default (with an option to clear it in the app)
2. when FW is enabled then there should be a warning on the logout page that FW is enabled and all network access will be blocked (the same functionality have to be implemented in CLI)
3. Necessary to implement the possibility to control the Firewall state even when the user is logged out: Add a switcher at the bottom of the login UI which shows the current firewall state. IF the 'always-on' firewall is enabled then when the user attempts to switch the firewall off we show a dialog box saying The always-on firewall is enabled. If you disable the firewall the 'always-on' feature will be disabled. [Disable Always-on firewall] / [Cancel].

Additionally, implement the possibility to control Firewall "Always-on" state from CLI

Bug report

Describe your environment

• Device: Desktop
• OS name and version: Arch Linux
• IVPN app version: 3.7.0

Describe the problem

Steps to reproduce:

1. systemctl enable --now systemd-resolved
2. Connect to IVPN

Observed Results:

Whether /etc/resolv.conf is a symbolic link or not, just having resolved running will leak DNS. Many Linux distributions now use systemd. This is a issue.

Expected Results:

Allow IVPN and resolved to coexist

Relevant Code:

// TODO(you): code here to reproduce the problem

Hi,

I am not sure whether I should create this issue under bug report or feature request, but I figured I would just use feature request because I am suggesting a change.

Feature request

Moving the installation path to /usr/bin instead of /usr/local/bin to support rpm-ostree systems (like Fedora Silverblue) and avoid breaking atomic updates/inconsistency on systems like openSUSE MicroOS or openSUSE Tumbleweed/Leap.

More information

On rpm-ostree based systems like Fedora Silverblue, they currently cannot work with packages that use /usr/local/bin due to a bug on their part: https://github.com/coreos/rpm-ostree/issues/233. This practically make the IVPN app uninstallable on those systems :/

On openSUSE distros, /usr/local/bin belong to the BTRFS subvolume @/usr/local is not part of the root subvolume (@/.snapshots/X/snapshot), and thus do not get snapshotted and does not rollback with the rest of the system should the user choose to do so. This essentially make the MicroOS variant lose its atomic update and cause in consistency with the Tumbleweed/Leap variants. The package manager (zypper) will think that IVPN is rolled back to an older version along with the rest of the system, while in reality the executable on /usr/local/bin is the newer version.

And while I have not tested this on Ubuntu yet (I have on Fedora Silverblue and openSUSE), it seems like Ubuntu's ZFS partition layout also uses a seperate pool for /usr/local as well, and thus could probably lead to the same issue on openSUSE.

Accoding to the Linux filesystem heirachy, /usr/local is supposed to contain programs the user installed from source, while /usr is for programs installed using the package manager. IVPN is distributed as pre compiled packages, and thus it should not be installed in /usr/local/bin in the first place. The issue I described with openSUSE and potentially Ubuntu with ZFS looks to be more like an issue with the IVPN package than the way they setup their BTRFS subvolumes/ZFS pools. I also think that it is unlikely rpm-ostree will support /usr/local as well, since you cannot make install anything on the host OS's immutable filesystem.

Have you considered any alternative solutions or workarounds?

Yes I have, but it is practically not doable on rpm-ostree systems. However, I don't think IVPN should be installed at /usr/local/bin in the first place, since it is being distributed as a .deb, .rpm, and pacman package that is being installed by the package manager.

Bug report

Describe your environment

• Device: Librem 14
• OS name and version: Qubes 4.1.1 host, Fedora 36 guests
• IVPN app version: 3.9.0

Describe the problem

If I install the official IVPN client in a ProxyVM, DNS in the AppVMs based on it will not work. I am aware that I can use a set up similar to https://mullvad.net/en/help/wireguard-on-qubes-os/, however, it is extremely cumbersome and I would like to use the official IVPN client instead.

Steps to reproduce:

1. Make a standalone Fedora 36 VM on Qubes. Set networking to use sys-firewall. Name this VM `sys-ivpn. (We need to use a standalone VM for the IVPN client here because login session gets lost after a reboot in a normal AppVM setup, and I will make a seperate issue for that later).
2. Give sys-ivpn the network-manager service and tick the box "Provides Network".
3. Install the IVPN client on it and log into IVPN.
4. Make a new AppVM, set networking to use sys-ivpn.

Observed Results:

Observe that DNS is broken regardless of VPN protocol, killswitch and local LAN support settings. The user has to manually set a custom DNS server in /etc/resolv.conf for the AppVM to work.

Expected Results:

DNS is set up properly.

Notes:

This appears to be some issues with some VPN providers and not the other providers. In particular:

• ProtonVPN works perfectly well with this set up, however it only supports OpenVPN.
• Mullvad OpenVPN works with this setup. However, their Wireguard has the same issue as IVPN. I have made a report for that here: https://github.com/mullvad/mullvadvpn-app/issues/3803
• Riseup and Windscribe work with this setup out of the box, however they have other issues with their killswitches and whatnot which I won't get into here.

I suspect that this has something to do with the integration with NetworkManager. Note that if I do not give the network-manager service to the other VPN providers, they have the exact same issue: DNS is broken, though the packets are still routed through the VPN itself.

Bug report

Describe your environment

• Device: macbook pro
• OS name and version: Mojave
• IVPN app version: 3.4.0

Describe the problem

favorite servers list is lost every couple of days, reassigning favs solves the problem temporarily, but the list turns out empty again after a few days (this is not linked to updating the client application)

Steps to reproduce:

1. use client, and assign favorite servers
2. keep using for a few days
3. try to open favs list

Observed Results:

list empty

Expected Results:

• What did you expect to happen? the list remains filled with my favs forever

Relevant Code:

// TODO(you): code here to reproduce the problem

Bug report

Describe your environment

• Device: Laptop
• OS name and version: fedora-33
• IVPN app version: 3.3.30

Describe the problem

On login a previously enabled firewall is always disabled. This even happens when the firewall is configured to be always on.

Steps to reproduce:

1. Logout: ivpn logout
2. Enable firewall: ivpn firewall -on
3. Check that firewall is enabled: ivpn firewall -> Firwall is enabled, iptables rules present
4. login: ivpn login .....
5. Check firewall again -> Firewall is now disabled, iptables rules are removed.

Observed Results:

• Login resets iptables rules (disables firewall)

Expected Results:

• Login should preserve firewall state

Relevant Code:

ivpn logout
ivpn firewall -on
ivpn login .....
ivpn firewall

Background

I am currently evaluating ivpn to be deployed onto managed clients. A crucial requirement is the functionality of the fail-close or "always on" firewall. This means, under absolutely no circumstances there must be any traffic leaking.

For that I do deploy ivpn with the IsFwPersistant value in /opt/ivpn/mutable/settings.json changed to true. When I then start ivpn-service the firewall is set up as expected. But as soon as a user logs in, all firewall rules are truncated. Which is really bad.

Bug report

Describe your environment

• Device: macbook Air m1
• OS name and version: MacOS Monterey 12.5.1
• IVPN app version: 3.9.8

Describe the problem

VPN must be disabled to access internet after changing WiFi networks.

Steps to reproduce:

1. Enable VPN on a known WiFi network
2. Travel to new location with another known WiFi network
3. Wake macbook from sleep

Observed Results:

• No internet access until disabling VPN. After that, re-enabling VPN continues to permit internet access

Expected Results:

• Internet access without needing to toggle VPN

Bug report

Describe your environment

• Device: Odroid N2 (an arm64 SoC device)
• OS name and version: Armbian 11 "bullseye" (arm64 derivative of Debian 11 "bullseye")
• IVPN app version: 3.8.7

Describe the problem

On an arm64 SoC device running Armbian 11 "bullseye", when uname -m returns aarch64, the iVPN GUI build fails because the Electron build artifacts are created at dist_electron/linux-arm64-unpacked, but the GUI build script at desktop-app/ui/References/Linux/build.sh expects these artifacts to be at a different location.

If the desktop-app/ui/References/Linux/build.sh script is modified to set the ARCH variable to arm64 when uname -m returns aarch64, the GUI build proceeds to a successful completion.

Steps to reproduce:

1. Install Armbian 11 "bullseye" on an arm64 device. Likely, you can install any other distro which returns aarch64 for uname -m and the problem will be repro'd.
2. Install all prerequisites to build the iVPN source code. I installed:
   • Go v1.18
   • nodejs 16 and npm v8.9.0
   • fpm v1.14.2
   • Other deps as listed in main readme
3. Clone this repo.
4. cd desktop-app/ui/References/Linux && ./build.sh -v 3.8.7

Observed Results:

• What happened? This could be a description, log output, etc.
  The GUI build fails with the following message:

Architecture: aarch64
======================================================
============ Building UI binary ======================
======================================================
  "version": "3.8.7",
*** Installing NPM molules ... ***

<SNIP>

INFO  Building app with electron-builder:
  • electron-builder  version=22.14.5 os=5.10.106-meson64
  • writing effective config  file=dist_electron/builder-effective-config.yaml
  • packaging       platform=linux arch=arm64 electron=14.2.9 appOutDir=dist_electron/linux-arm64-unpacked
 DONE  Build complete!
[!] Folder not exists: '/root/IVPN_SOURCE_CODE/desktop-app/ui/References/Linux/../../dist_electron/linux-unpacked'
    Build IVPN UI project (do not forget to set correct version for it in 'package.json')

Expected Results:

• What did you expect to happen? I expected that the GUI build would complete successfully.

If the desktop-app/ui/References/Linux/build.sh script is modified to set the ARCH variable to arm64 when uname -m returns aarch64, the GUI build does indeed proceed to a successful completion. In the section below, I have attached a patch file which, when applied to the source code, fixes this problem.

Relevant Code:

To fix this issue, apply the attached patch file at the root of the source code using patch -p1 < ui_build_fix_for_aarch64.patch.txt and then perform the GUI build on aarch64.

ui_build_fix_for_aarch64.patch.txt

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.

Feature request

Description

ivpn connect -any US always connects to us-tx because that is the first server in the servers.json file.

ivpn connect -p ovpn -any US always connects to us-ca because that is the first server in the OpenVPN section of the servers.json file.

Adding a -random CLI option offers a way to randomize the -any option for countries with multiple locations, like US, UK, and Canada.

Describe alternatives you've considered

Scripting a custom wrapper for the IVPN App to select a random server is currently the only option to achieve this behaviour.

Bug report

Describe your environment

Occurs on any version of macOS (tested Big Sur and Monterey).

Describe the problem

When I install IVPN via the Homebrew Cask, launching it for the first time shows an error connecting to the daemon.

I thought it might be because the application had been quarantined, but sudo xattr -rd com.apple.quarantine /Applications/IVPN.app/ and attempting to reconnect to the daemon produced the same result. Installing the application manually from the site over the cask does work, but brew install --cask ivpn --no-quarantine produces no change in results.

The daemon is definitely loaded (verified sudo launchctl load /Library/LaunchDaemons/net.ivpn.client.Helper.plist), so I'm not sure why this is occurring.

Steps to reproduce:

1. Run "brew install --cask ivpn"
2. Launch app

Observed Results:

The app never works or gets past the initial error screen

Expected Results:

Expect to be able to use the app normally.

It would be nice to have a list of anti trackers to choose from to be more flexible in ad/trackers blocking. For now there is an only option with "OISD" running implicitly with the optional "hardcore" toggle. It doesn't cover some edge cases, it's more like a general filter to satisfy the most people using it. It would be 2x nicer to have a possibility to add own anti-tracker lists by url with some update interval.

Bug report

Describe your environment

• Device: Macbook Pro 16" 2022 (arm64)
• OS name and version: MacOS 12.6.1
• IVPN app version: 3.9.32 (reproduced also with 3.10.0 beta)

Describe the problem

Steps to reproduce:

1. Try to connect to a server using the App, Wireguard, Port 2049. Same config used to work. Connecting with OpenVPN succeeds

Observed Results:

...
Dec 20 19:52:21.052 [servc ] ERROR service.go:569:(in github.com/ivpn/desktop-app/daemon/service.(*Service).keepConnection): Connection error: connection error: failed to initialize configuration: failed to initialize interface: exit status 1
Dec 20 19:52:21.052 [prtcl ] ERROR protocol.go:1192:(in github.com/ivpn/desktop-app/daemon/protocol.(*Protocol).processRequest): connection error: failed to initialize configuration: failed to initialize interface: exit status 1
...

Expected Results:

Connecting to the server.

Feature request

Details: https://github.com/ivpn/android-app/issues/16

The ISP info must be shown in GUI: the ISP info has to be added to the 'location' description in the servers list. To think: Shall it be configurable from app settings?

Feature request

Correspondent settings windows must be shown by clicking on the "Firewall"/"AntriTracker" labels in the main window.

The iVPN window can be brought to the front of the screen with the following sequence

• point (to the menu bar)
• click to open the menu
• point to the right menu item
• click on "show iVPN" This looks short, but it does actually take very long - in particular if used many times a day. Could you please consider adding a simple keyboard shortcut, ideally one that can be selected by the user ? Thank you for a great service !!

Bug report

Describe your environment

• Device: Asus ROG Zephyrus G15
• OS name and version: Arch Linux x86_64, Linux Kernel - 6.0.9-arch1-g14-1
• IVPN app version: 3.9.45

Describe the problem

When using libvirt(through libvirt-manager), can not connect to the internet.

Steps to reproduce:

1. Just enable firewall.

Observed Results:

• GuestOSes can not connect to the internet.