TorGuard Client v4.4.0

[Support]

Release torguard-v4.4.0, 2020-01-19
===================================

- All platforms: when using a dedicated IP, OpenConnect tunnel type is now optional and with a customizable port.
                 OpenConnect must be activated and the port chosen when the dedicated IP is added to the settings.
- All platforms: when adding a new DedicatedIP, show a warning if the IP is already in use.
- All platforms: when adding a new NameServer, show a warning if the selected name is already in use.
- All platforms: when adding a new NameServer, show all DNSs in the list.
                 Some of them are only available in the "when VPN is connected" state.
- All platforms: display a notification every 60 seconds if the VPN is not running.
- All platforms: Updated Stunnel to v5.57
- Windows: update WireGuard installer to new version 0.3.4

Internal Changes:
-----------------

- All platforms: internal refactoring

Downloads

[19807409]

On 1/20/2021 at 2:20 PM, Support said:

Release torguard-v4.4.0, 2020-01-19
===================================

- All platforms: when using a dedicated IP, OpenConnect tunnel type is now optional and with a customizable port.
                 OpenConnect must be activated and the port chosen when the dedicated IP is added to the settings.
- All platforms: when adding a new DedicatedIP, show a warning if the IP is already in use.
- All platforms: when adding a new NameServer, show a warning if the selected name is already in use.
- All platforms: when adding a new NameServer, show all DNSs in the list.
                 Some of them are only available in the "when VPN is connected" state.
- All platforms: display a notification every 60 seconds if the VPN is not running.
- All platforms: Updated Stunnel to v5.57
- Windows: update WireGuard installer to new version 0.3.4

Internal Changes:
-----------------

- All platforms: internal refactoring

Downloads

 

I had no issues at all with this version, works great, also tested 4.3.1 beta arm64 on ubuntu 20.04 with mate desktop, worked without any issues.

However, there is one issue which some users might get crazy about

OS used: Debian (Linux hystou 5.10.0-1-amd64 #1 SMP Debian 5.10.4-1 (2020-12-31) x86_64 GNU/Linux)

TorGuard Client options used: start on boot, autoconnect on start, kill switch

 

How to reproduce

1. Enable torguard client to autoconnect on boot/startup with kill switch (I did not test with disabled kill switch)

2. Disconnect your video (hdmi/dp/...) so that no monitor/plug is connected (xrandr says no monitor is connected) and reboot

3. Torguard still connects properly but GUI can not be launched as no desktop is running

4. If one needs to change IP address or switch at all to lets say wireguard original client, then the first that normally comes to mind is to uninstall TorGuard client (sudo dpkg -r torguard)

5. After uninstallation, logically no torguard connection is established on boot. Here a user suddenly finds out that the internet is not working.

 

Next step a normal user does is to reset ip routes and tables, together with the network interface reset/reconfigure without any success. In best case user does not break fully its  network config, ip routes/tables etc.. and after hours of not understanding why internet does not work, one gives up and trashes a night in backing up and resintalling OS, where again, hopefully not losing data.

With step 5 I mean with internet is not working is what a normal Joe user would experience and how it is/was described to me. In fact it is only dns resolution which does not work, pinging ip's directly works. Your customer sent me this as a bug explaning that he had to reinstall whole OS, he is experienced in  linux but not so much in networking and vpn's on linux.

After he told me step 5, I already assumed that it is about dns resolution and did not know if pinging works, by that I suggested him to reproduce it again, he wasnt that happy and was kinda scared he would end up in reinstalling OS again. After I reproduced it and came to step 5, I checked /etc/resolv.conf file and bang:

# resolv.conf(5) file generated byTorGuard
nameserver 10.9.0.1
nameserver 10.8.0.1

# ORIGINAL CONTENT:
# was symbolic link to /var/run/NetworkManager/resolv.conf
# # Generated by NetworkManager
# search lan
#nameserver 1.1.1.1
#nameserver 1.0.0.1

 

With that it was clear why dns resolution does not work, changing it to original content (or marking out torguard's and unmarking original):

# resolv.conf(5) file generated byTorGuard
#nameserver 10.9.0.1
#nameserver 10.8.0.1

# ORIGINAL CONTENT:
# was symbolic link to /var/run/NetworkManager/resolv.conf
# # Generated by NetworkManager
# search lan
nameserver 1.1.1.1
nameserver 1.0.0.1

 

This is fully reproducable on any debian based OS on all architectures where you offer TorGuard client. After user was shown it, he said, he does not know if he shuold cry that he fully reinstalled his OS and waisted a day for nothing or to smile because this mystery is resolved for that user.

Solution proposal

During uninstallation, all edited files (if there are more/other than just resolv.conf) should be reverted to originals or at least edited values. This would probably spare some time to those who run into this issue. I tested this and reproduced it also on ubuntu, meaning that this issue is for all debian based OS's, not sure about other OS's, but I am sure you will check them too.

[Support]

2 hours ago, 19807409 said:

 

I had no issues at all with this version, works great, also tested 4.3.1 beta arm64 on ubuntu 20.04 with mate desktop, worked without any issues.

However, there is one issue which some users might get crazy about

OS used: Debian (Linux hystou 5.10.0-1-amd64 #1 SMP Debian 5.10.4-1 (2020-12-31) x86_64 GNU/Linux)

TorGuard Client options used: start on boot, autoconnect on start, kill switch

 

How to reproduce

1. Enable torguard client to autoconnect on boot/startup with kill switch (I did not test with disabled kill switch)

2. Disconnect your video (hdmi/dp/...) so that no monitor/plug is connected (xrandr says no monitor is connected) and reboot

3. Torguard still connects properly but GUI can not be launched as no desktop is running

4. If one needs to change IP address or switch at all to lets say wireguard original client, then the first that normally comes to mind is to uninstall TorGuard client (sudo dpkg -r torguard)

5. After uninstallation, logically no torguard connection is established on boot. Here a user suddenly finds out that the internet is not working.

 

Next step a normal user does is to reset ip routes and tables, together with the network interface reset/reconfigure without any success. In best case user does not break fully its  network config, ip routes/tables etc.. and after hours of not understanding why internet does not work, one gives up and trashes a night in backing up and resintalling OS, where again, hopefully not losing data.

With step 5 I mean with internet is not working is what a normal Joe user would experience and how it is/was described to me. In fact it is only dns resolution which does not work, pinging ip's directly works. Your customer sent me this as a bug explaning that he had to reinstall whole OS, he is experienced in  linux but not so much in networking and vpn's on linux.

After he told me step 5, I already assumed that it is about dns resolution and did not know if pinging works, by that I suggested him to reproduce it again, he wasnt that happy and was kinda scared he would end up in reinstalling OS again. After I reproduced it and came to step 5, I checked /etc/resolv.conf file and bang:

# resolv.conf(5) file generated byTorGuard
nameserver 10.9.0.1
nameserver 10.8.0.1

# ORIGINAL CONTENT:
# was symbolic link to /var/run/NetworkManager/resolv.conf
# # Generated by NetworkManager
# search lan
#nameserver 1.1.1.1
#nameserver 1.0.0.1

data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

 

With that it was clear why dns resolution does not work, changing it to original content (or marking out torguard's and unmarking original):

# resolv.conf(5) file generated byTorGuard
#nameserver 10.9.0.1
#nameserver 10.8.0.1

# ORIGINAL CONTENT:
# was symbolic link to /var/run/NetworkManager/resolv.conf
# # Generated by NetworkManager
# search lan
nameserver 1.1.1.1
nameserver 1.0.0.1

data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

 

This is fully reproducable on any debian based OS on all architectures where you offer TorGuard client. After user was shown it, he said, he does not know if he shuold cry that he fully reinstalled his OS and waisted a day for nothing or to smile because this mystery is resolved for that user.

Solution proposal

During uninstallation, all edited files (if there are more/other than just resolv.conf) should be reverted to originals or at least edited values. This would probably spare some time to those who run into this issue. I tested this and reproduced it also on ubuntu, meaning that this issue is for all debian based OS's, not sure about other OS's, but I am sure you will check them too.

 

Thanks for your input as always - we will look into that right away.

Regards

 

 

 

 

[Morphy]

Just curious - why have you disabled the "There is an update - please download latest version" or something. ?

I remember that TG had this feature, so annoying that you have to go to the site, to see there is a new update and then download it from the site. Why don't you have this feature enabled anymore? Would be great to have feature back.

 

And now I really want to know - when can we expect Split tunneling as you wrote on the blog ages ago , I recall I saw an email where TG posted that info.

 

[Support]

3 hours ago, Morphy said:

Just curious - why have you disabled the "There is an update - please download latest version" or something. ?

I remember that TG had this feature, so annoying that you have to go to the site, to see there is a new update and then download it from the site. Why don't you have this feature enabled anymore? Would be great to have feature back.

 

And now I really want to know - when can we expect Split tunneling as you wrote on the blog ages ago , I recall I saw an email where TG posted that info.

 

 

We haven't disabled this no, we are improving the update process currently.

Split tunnelling is coming next, we are working out how to fit in with current protocols and certain features.

Regards

[Morphy]

Sounds awsome

 

By the way - a huge thing that would make TG even better .

Make an “app” for Synology which has the features from ie Ubuntu client

Synology deeply lack of support of a good vpn client . With split tunneling for this NAS would open so many new options for Synology Nas

[Support]

1 minute ago, Morphy said:

Sounds awsome

 

By the way - a huge thing that would make TG even better .

Make an “app” for Synology which has the features from ie Ubuntu client

Synology deeply lack og support of a good vpn client . With split tunneling for this NAS would open so many new options for Synology Nas

 

We do have one btw  we just need to get it finished off.

Regards

[19807409]

15 hours ago, Support said:

 

We do have one btw  we just need to get it finished off.

Regards

Taking in mind that most binaries are now available for download, I guess, if torguard does not create a snap for torguard client then I will. This will let every user stay autoupdated and each time they launch their TG client it would be up to date, in ubuntu using livepatch does autoupdate it.

[Support]

On 1/21/2021 at 9:40 PM, 19807409 said:

 

I had no issues at all with this version, works great, also tested 4.3.1 beta arm64 on ubuntu 20.04 with mate desktop, worked without any issues.

However, there is one issue which some users might get crazy about

OS used: Debian (Linux hystou 5.10.0-1-amd64 #1 SMP Debian 5.10.4-1 (2020-12-31) x86_64 GNU/Linux)

TorGuard Client options used: start on boot, autoconnect on start, kill switch

 

How to reproduce

1. Enable torguard client to autoconnect on boot/startup with kill switch (I did not test with disabled kill switch)

2. Disconnect your video (hdmi/dp/...) so that no monitor/plug is connected (xrandr says no monitor is connected) and reboot

3. Torguard still connects properly but GUI can not be launched as no desktop is running

4. If one needs to change IP address or switch at all to lets say wireguard original client, then the first that normally comes to mind is to uninstall TorGuard client (sudo dpkg -r torguard)

5. After uninstallation, logically no torguard connection is established on boot. Here a user suddenly finds out that the internet is not working.

 

Next step a normal user does is to reset ip routes and tables, together with the network interface reset/reconfigure without any success. In best case user does not break fully its  network config, ip routes/tables etc.. and after hours of not understanding why internet does not work, one gives up and trashes a night in backing up and resintalling OS, where again, hopefully not losing data.

With step 5 I mean with internet is not working is what a normal Joe user would experience and how it is/was described to me. In fact it is only dns resolution which does not work, pinging ip's directly works. Your customer sent me this as a bug explaning that he had to reinstall whole OS, he is experienced in  linux but not so much in networking and vpn's on linux.

After he told me step 5, I already assumed that it is about dns resolution and did not know if pinging works, by that I suggested him to reproduce it again, he wasnt that happy and was kinda scared he would end up in reinstalling OS again. After I reproduced it and came to step 5, I checked /etc/resolv.conf file and bang:

# resolv.conf(5) file generated byTorGuard
nameserver 10.9.0.1
nameserver 10.8.0.1

# ORIGINAL CONTENT:
# was symbolic link to /var/run/NetworkManager/resolv.conf
# # Generated by NetworkManager
# search lan
#nameserver 1.1.1.1
#nameserver 1.0.0.1

 

With that it was clear why dns resolution does not work, changing it to original content (or marking out torguard's and unmarking original):

# resolv.conf(5) file generated byTorGuard
#nameserver 10.9.0.1
#nameserver 10.8.0.1

# ORIGINAL CONTENT:
# was symbolic link to /var/run/NetworkManager/resolv.conf
# # Generated by NetworkManager
# search lan
nameserver 1.1.1.1
nameserver 1.0.0.1

 

This is fully reproducable on any debian based OS on all architectures where you offer TorGuard client. After user was shown it, he said, he does not know if he shuold cry that he fully reinstalled his OS and waisted a day for nothing or to smile because this mystery is resolved for that user.

Solution proposal

During uninstallation, all edited files (if there are more/other than just resolv.conf) should be reverted to originals or at least edited values. This would probably spare some time to those who run into this issue. I tested this and reproduced it also on ubuntu, meaning that this issue is for all debian based OS's, not sure about other OS's, but I am sure you will check them too.

Quick question - have you tried just sending a SIGTERM? TorGuard should then clean and gracefully die.

Regards

[19807409]

3 hours ago, Support said:

Quick question - have you tried just sending a SIGTERM? TorGuard should then clean and gracefully die.

No I did not, the first is that it happened to another user and I tried to reproduce it. It happened very simple to that user, he was working remote and hist monitor went off, then he rebooted and due to the monitor not being connected his connection to display 0 was not available. On that point he was a little lost and could not find how to switch off torguard client which still was loaded.

What he then did is kill -9 torguard, but he had no internet after it, then he rebooted, still no internet, then he uninstalled torguard with dpkg -r torguard in hope that after that it will work. He rebooted and still had no internet.

Point here was that user had no internet at all.

Probably its of a value to have that info info, to write somewhere how to kill/shutdown properly from command line so that users do not run into these issues.

Also, do you want to try snap? I already created it and it works . I will not release it for now as wireguard does not work on it and module compilation over snap is a little tricky. However, I compile from source openconnect, openvpn, wireguard tools for that snap. I use for it deb packages, however, having a real one where torguard client is compiled would be much better and would alllow probably i386 too.

[19807409]

@Supportsnap works fine, for base 18.04 it compiles without issues, created today 20.04 which ends up with QT related error which I will resolve by compiling qt related packages from source instead of using shared libs. I included for now openconnect, openvpn and wireguard (wireguard-tools and wireguard-compat).

In the attachment is snapcraft.yaml which I will push after I've added qt libs. However, I have to use for now existing deb packages which is ok, but better would be if it could be compiled directly, biggest part is already done by me, you can also move all parts into one single, however, I splitted them and they all are install with one command (after I have published, snap install torguard would not work now).

To install torguard client, you will just have to run:

sudo snap install torguard

Thats it, it would be autoupdated by OS (as long as the maintenance of snap is provided), or if you want manually upgrade or change beta/stable/release/edge channels.

If you want to try the snap in the attachment, then git clone according repo, replace snapcraft.yaml with the file from attachment, then cd into root of git projects folder and run:

snapcraft try

when it finished, you can test it with:

snap try /full/path/to/torguard-snap/prime

run all parts with prefix torguard., as example openconnect would be torguard.openconnect, wg would torguard.wg, wg-quick would be torguard.wg-quick, torguard client itself would be torguard.qt

By that, if you have installed torguard client from deb package, it would not interfere with snap package which can coexist on a system.

snap works and autobuilds currently for arm32, aarch64 and amd64.

If you do patch openvpn and openconnect some specifically, your devs should then take a look at the repo and commit, I would give your devs also full access to snap store where you can trigger manually new builds.

If you did run snap try, to clean it, you have to run snapcraft clean and then uninstall torguard snap:

sudo snapcraft clean
sudo snap remove torguard

 

Here are versions of included compiled packages (final version should compile all other required libs/bins which torguard uses from source, like stunnel4, openssl etc.., I lacked on ability to provide more time to this, created it quickly over a weekend, adding all libs will require some time, you/your devs are welcome to do it as you guys do  not need to find out which libs exactly you need/require)

$ torguard.openconnect --version
WARNING: Cannot set locale: No such file or directory
OpenConnect version v8.10-153-gf07d798f
Using OpenSSL 1.1.1f  31 Mar 2020. Features present: TPM (OpenSSL ENGINE not present), HOTP software token, TOTP software token, DTLS, ESP
Supported protocols: anyconnect (default), nc, gp, pulse

$ torguard.openvpn --version
OpenVPN 2.6_git [git:master/2d7e1954cae51ff3+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 27 2021
library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc <[email protected]>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto_ofb_cfb=yes enable_debug=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_werror=no enable_win32_dll=yes enable_x509_alt_username=no with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no

$ torguard.wg --version
wireguard-tools v1.0.20200513 - https://git.zx2c4.com/wireguard-tools/

 

snapcraft.zip

[Cytane89]

Not the biggest deal, and not sure if it's just me, but form 4.3.0 to 4.4.0 it takes decently longer to connect to the VPN. It felt like 2 seconds max with 4.3.0, but now it's near 10 seconds with 4.4.0.

[Support]

Try these steps:

1) Go to more settings --> general tab --> click restore defaults
2) Go to more settings --> general tab --> click Refresh next to Refresh Server List
3) Go to more settings --> network tab --> click clean cache and refresh cache in that order

Let me know how you go. Thanks

[Support]

13 hours ago, 19807409 said:

@Supportsnap works fine, for base 18.04 it compiles without issues, created today 20.04 which ends up with QT related error which I will resolve by compiling qt related packages from source instead of using shared libs. I included for now openconnect, openvpn and wireguard (wireguard-tools and wireguard-compat).

In the attachment is snapcraft.yaml which I will push after I've added qt libs. However, I have to use for now existing deb packages which is ok, but better would be if it could be compiled directly, biggest part is already done by me, you can also move all parts into one single, however, I splitted them and they all are install with one command (after I have published, snap install torguard would not work now).

To install torguard client, you will just have to run:

sudo snap install torguard

Thats it, it would be autoupdated by OS (as long as the maintenance of snap is provided), or if you want manually upgrade or change beta/stable/release/edge channels.

If you want to try the snap in the attachment, then git clone according repo, replace snapcraft.yaml with the file from attachment, then cd into root of git projects folder and run:

snapcraft try

when it finished, you can test it with:

snap try /full/path/to/torguard-snap/prime

run all parts with prefix torguard., as example openconnect would be torguard.openconnect, wg would torguard.wg, wg-quick would be torguard.wg-quick, torguard client itself would be torguard.qt

By that, if you have installed torguard client from deb package, it would not interfere with snap package which can coexist on a system.

snap works and autobuilds currently for arm32, aarch64 and amd64.

If you do patch openvpn and openconnect some specifically, your devs should then take a look at the repo and commit, I would give your devs also full access to snap store where you can trigger manually new builds.

If you did run snap try, to clean it, you have to run snapcraft clean and then uninstall torguard snap:

sudo snapcraft clean
sudo snap remove torguard

 

Here are versions of included compiled packages (final version should compile all other required libs/bins which torguard uses from source, like stunnel4, openssl etc.., I lacked on ability to provide more time to this, created it quickly over a weekend, adding all libs will require some time, you/your devs are welcome to do it as you guys do  not need to find out which libs exactly you need/require)

$ torguard.openconnect --version
WARNING: Cannot set locale: No such file or directory
OpenConnect version v8.10-153-gf07d798f
Using OpenSSL 1.1.1f  31 Mar 2020. Features present: TPM (OpenSSL ENGINE not present), HOTP software token, TOTP software token, DTLS, ESP
Supported protocols: anyconnect (default), nc, gp, pulse

$ torguard.openvpn --version
OpenVPN 2.6_git [git:master/2d7e1954cae51ff3+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 27 2021
library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc <[email protected]>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto_ofb_cfb=yes enable_debug=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=no enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_werror=no enable_win32_dll=yes enable_x509_alt_username=no with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no

$ torguard.wg --version
wireguard-tools v1.0.20200513 - https://git.zx2c4.com/wireguard-tools/

 

snapcraft.zip 3.4 kB · 0 downloads

 

Thanks, im passing over to the relevant folk to take a look

[19807409]

15 hours ago, Support said:

Thanks, im passing over to the relevant folk to take a look

They should give me email address which I can add as collaborator on those ressources (github, snapcraft, launchpad, ...), that way you guys can have access to release process and release it by yourself, as example, instead of sending me email in saying I should update the package, you simply click and trigger rebuild, thats it, then 30 minutes later all your releases are available over store.

I also put the information which is to be found under your homepage (look at snap store when you get access). Currently it is not visible as I did not publish any release. Snap version which I attached previously includes actually everything required, as libs etc..., I will probably add them to depends folder, then during the build cd depends, build all libs, then compile all binaries using those prebuilt libs. That way you can have deterministic releases.

I also did not upload installation deb files available over your homepage as it would mean that on github there would your releases hosted without actually your approval, by that it would not be clever of me hosting it on gituhub if torguard did permit it. Current script uses urls to Torguard, where in fact there is inconsistency either in your versioning or release process, because all release/binaries have different naming schemes. By that I would say the latest which you have is the one to be used:

releases: vX.X.X, example v4.4.0

beta (?release?), example v4.4.0-beta

For aarch64 (and some other), there is different naming scheme which would require code change, the only one is torguard-latest for amd64 which would not require any change in snap script. By that, you should have torguard-latest for all versions available, then script can be also short and after the release you click simply rebuild and you released it already to snap store without any edits. Of course, if version number changes, then you edit it and by commiting it to github, snap build will be automatically triggered without any other additional steps, where I would assume that you still want release/stable branch to be released only manualy, edge (master) to be automatically.

 

torguard app/snapcraft/github name is reserved (they are my). But I gladly can transfer the ownerships or add torguard as admins/collaborators