Staff

14 hours ago, A1rX said:

When i do the ipleak.net test, Browser default (IPV4) is green and Fallback (IPV6) is green.  This is correct, right?  And both port # check out right. 

Hello!

Yes, from your description everything is fine.
 

14 hours ago, A1rX said:

Also, on a Mac computer, what do I set the firewall to?

If you run the AirVPN software Eddie, you can consider to let it set firewall rules to prevent traffic leaks outside the VPN tunnel by activating Network Lock feature. On Eddie's main window please click "Activate Network Lock" button before you start a connection. You may also tell Eddie to activate Network Lock by itself when it is started by checking "Activate Network Lock at start" in Eddie's "Preferences" > "General" window.

Kind regards
 

7 hours ago, fawken_kelpo said:

Update: I was able to resolve this issue by having 2 forwarded ports, when 1 stopped working, I switched to the other one within qBittorrent, and now it's been working well so far, not sure why this happens though.

Hello!

Problem solved. The reason of the problem and why your method works perfectly can be inferred from GlueTun behavior described here: https://airvpn.org/forums/topic/63708-gluetun-port-forwarding-works-for-an-hour/?do=findComment&comment=239350

By changing port you force a new socket on the rebuilt tunnel. Re-starting qBittorrent from scratch or the whole container should fix the issue as well. Please note that you have an additional option for mitigation described in the linked thread that does not require the workaround you implemented, worth a try.

Side note, please insert the proper port for qBittorrent on your compose file ports: section and if necessary set properly the FIREWALL_VPN_INPUT_PORTS variable. Ref. https://github.com/qdm12/gluetun-wiki/blob/main/setup/options/firewall.md

Kind regards
 

11 hours ago, TheBoss1980 said:

That would be great if it actually worked i tried that already and i still have to enter a password on launch everytime

Hello!

This depends on your desktop wallet configuration/behavior. Perhaps after a suspend the wallet gets encrypted and you need to enter the password to decrypt it (and therefore Eddie will be able to decrypt the configuration file). Different issue is when Eddie asks for root privileges. To bypass this security feature Eddie backend can start as a systemd service (only on systemd based systems) during the bootstrap. That's why when you start the GUI you should not be prompted for the password to gain root privileges: the backend already runs with root privileges.

It should be clarified now whether the password you need to enter relates to the wallet password (in order to decrypt Eddie's configuration file) or to the authorization to gain root privileges. In particular, please note that if Eddie was already running before the suspension, then at resume Eddie should find the configuration file already decrypted, and Eddie's backend already runs with root privileges. The passwords could match (it depends on your configuration) but they are used for different purposes.

Can you also tell us your Desktop Environment name and version?

Kind regards
 

12 hours ago, ELODIEW said:

I entered this into the terminal several times and now I can't even type my password

Hello!

The characters you type for a password are generally not echoed on the terminal emulator for security reasons. You have to type the password (of the Mac account with which you opened the terminal emulator) "blindly", then press ENTER. If you typed the wrong password the system will warn you.

Kind regards
 

3 hours ago, Huuva said:

The port doesn't disappear, it just goes from open to closed after 6-7 days. My premium access expires in 1115 days.

It happened again yesterday but seems to be just me so I will check what qbittorrent is doing next time as I only use the port for that docker.

Hello!

This is a not infrequent situation with those containers that destroy the tunnel at each VPN re-connection. Please see here for a specific GlueTun case and an effective mitigation:
https://airvpn.org/forums/topic/63708-gluetun-port-forwarding-works-for-an-hour/?do=findComment&comment=239350

In general, if there's no way to prevent tunnel destruction and rebuild, re-starting qBittorrent (or anyway the listening program) could be the only solution.

Kind regards
 

1 hour ago, ELODIEW said:

same problem here 

Hello!

We confirm it's the same problem, so you can apply the identical solution.

Kind regards
 

On 1/18/2025 at 12:41 PM, Staff said:

Hello!

Good news, we will start testing a 10 Gbit/s server in Germany before the end of January and if everything goes well we should make it available a few days later. We are waiting for the equipment to be connected between January 20 and 25.

Kind regards
 

Hello!

A new 10 Gbit/s (full duplex) server is now available in Germany.
Kind regards
 

Hello!

Hello!

For the readers' comfort and to suggest troubleshooting ideas, we paste the answer by the support team to your ticket (with a few omissions for privacy reasons):

Hello and thank you for your choice!

This is what we see on the server you are currently connected to (xxx):
<...>
 

a.b.c.d is your VPN IPv4 address, so the port forwarding is active and properly configured. We have noticed that when we try to send a packet to your node, the attempted connection is actively reset by your system (TCP RST) on both ... and ... ports. As you can see from the nftables counters, packets are sent to your system.

When this problem occurs you should verify your virtual environment to understand why the attempted connections are reset. It could be a firewall rule, but it could also be your kernel that's configured to reset attempted connections to non-existing ports. This last case would imply that the qBittorrent process is either not running or binding to a wrong interface, or maybe stuck to a previous socket because the VPN connection dropped and was re-established. When it happens, if the container destroys the tun and re-creates it, then qBittorrent needs to be restarted. This is a known issue for example in GlueTun:

https://github.com/qdm12/gluetun/issues/1407

 

The above would also explain why you experience the problem 1-2 times per week, which could be a disconnection event frequency.

 

Kind regards

On 1/29/2025 at 6:25 PM, leechko said:

'/sbin/nft --version' gives me 'nftables v1.0.2 (Lester Gooch)', a Feb 2022 release, according to project's website. Latest is v1.1.1, Oct 2024.

I think I'm out of luck on this one, but I'll try the new release when it comes out anyway.

Hello!

It is possible that we are interpreting the problem incorrectly. However, by editing the /etc/hosts file you should be able to resolve the issue. The next beta 3 is expected to be out in a few days.

Kind regards
 

Hello!
 

On 1/29/2025 at 11:23 AM, 8bit_dodger said:

I deleted the app, redownloaded the latest 2.24.6,

The unpacking will restore the old files with the wrong ownership, so the problem will likely re-appear when you re-install.

The problem is still the same, but for another file:
E 2025.01.29 21:21:14 - WireGuard > Error: Executable '/Applications/Eddie.app/Contents/MacOS/wg' not allowed: Not owned by root;

Please change ownership of this file too and any other file in case of additional errors of the same type:

sudo chown root /Applications/Eddie.app/Contents/MacOS/wg
sudo chown root /Applications/Eddie.app/Contents/MacOS/wireguard-go

Kind regards
 

On 1/29/2025 at 10:20 AM, leechko said:

What am I doing wrong?

Hello!

Perhaps nothing wrong, this looks like a Bluetit bug which causes a critical error to the latest nft version (so it went unnoticed with the previous nft versions). If this is the problem we suspect, then it has been fixed and the new, imminent beta 3 will include the patch. As soon as Suite 2.0.0 beta 3 is out please test it and let us know whether it solves the problem.

If you need urgently to run AirVPN Suite 2.0.0 beta 2, you should be able to fix the issue by editing your /etc/hosts file (root privileges required) and adding the following line:
82.196.3.205  bootme.org

Thank you very much for your tests!

Kind regards
 

1 hour ago, Av Demeisen said:

This didn't solve the problem for me on macOS 15.3.

Hello!

Please re-check the ownership of any file to verify that Eddie detects it correctly and that you really changed the ownership to root. From a terminal:

sudo ls -l /Applications/Eddie.app/Contents/MacOS

If you see that the file Eddie complains of does not belong to root, then Eddie is right. Proceed to change ownership of any other file if necessary. If in doubt please send us the output of the above command.

Kind regards

 

Hello!

Please try again to change ownership of the following file:
/Applications/Eddie.app/Contents/MacOS/wireguard-go

The critical error is that Eddie will refuse to run with root privileges binaries or scripts not owned by root. It is an important security feature. From a terminal where you can gain root privileges and owned by a user that can gain root privileges, please enter the following command:

sudo chown root:wheel /Applications/Eddie.app/Contents/MacOS/wireguard-go

Kind regards

 

48 minutes ago, jasonkaruda1965 said:

Authorities in Belarus started blocking VPNs on Saturday, so no connection to airvpn on my iphone and ipad (OpenVPN Connect 3.5.1.), however the vpn works on my mac (eddie).  Connected to the same Wi-Fi. Any suggestions? OpenVPN settings are set to default.

Hello!

Please check the connection mode configured on Eddie Desktop edition and try to reproduce it on your iOS systems. Not all connection modes can be replicated on iOS, unfortunately. Eddie Desktop edition connects via WireGuard by default (starting from version 2.24); if that's the case, you can consider to run WireGuard on your iOS devices too.

Kind regards
 

On 1/18/2025 at 12:45 PM, Staff said:

Hello!

Good news. A new server in New Zealand was ordered early on January and it has just been connected. We are going to configure it in the next business day, and if everything goes well it will be available a few days later.

Kind regards
 

Hello!

Now available https://airvpn.org/forums/topic/67050-new-1-gbits-server-available-nz

Kind regards
 

On 1/27/2025 at 9:52 AM, 8bit_dodger said:

am also experiencing this issue on a new MacBook Pro

Hello!

The problem:

Quote

E 2025.01.27 19:49:08 - WireGuard > Error: Executable '/Applications/Eddie.app/Contents/MacOS/wireguard-go' not allowed: Not owned by root;

It is strange that Eddie can not authenticate (through file hash checksum) those files, can you please tell us which package you downloaded (Intel or M1/M4, ZIP or DMG)?

The problem is (also) a consequence of the enforcement of a relevant security feature: Eddie will not run with root privileges binaries or scripts not owned by root, if such binaries can not be checksum-authenticated. You can fix the problem (after you have verified that wireguard-go is safe) by changing ownership of that file. From a terminal:

sudo chown root /Applications/Eddie.app/Contents/MacOS/wireguard-go

Kind regards
 

Hello!

8 hours ago, HellatGlitch said:

Hey. Just got a notice about a torrent I'd gotten. I use AirVPN all the time but it apparently didn't shield me.

Hello!

Provided that it was not an error by your ISP (were you really performing the illegal activity the notice describes?), and you were running AirVPN software, this is possible only if you disabled Network Lock. Network Lock is a set of firewall rules which will prevent any possible traffic leak, not only leaks caused by unexpected disconnection, but even leaks caused by a misconfiguration of the torrent program, for example when it is forced to bind to the physical network interface, through UPnP or wrong setting. Please make sure that you follow the recommendations you have received in the welcome e-mail, the web site answers to FAQ and the general guide.

if you are not running AirVPN software, then you can set your own rules to prevent leaks (several guides are available in our How-To forum), and/or configure properly the torrent program to prevent it from generating traffic outside the VPN tunnel.

Reading documentation is always a good investment.

Kind regards
 

2 hours ago, raptor2003 said:

Hello,

When using servers from the Netherlands, it seems that the IP reported to the outside world is sometime completely different from the server's IP. I have seen that behaviour on multiple of them.
I switched to Sweden servers, and I don't have that "issue".

Why would that be ?

Hello!

It is related to the geo-routing feature:
https://airvpn.org/faq/routingtable/

You can disable this feature from your AirVPN account DNS panel by changing the setting of the "AirVPN anti geo-location system" combo box. Please note that if the forced routing was implemented in order to bypass a block, you will have that block again when you disable the routing.

Kind regards
 

On 1/20/2025 at 6:32 PM, Gevurahel said:

Here's the system report.

Hello!

We're very sorry, nothing new. Something is blocking your VPN connections.

Kind regards
 

20 minutes ago, JonathanM said:

Hi Staff,

How's the deployment going ?

Hello!

An unexpected problem related to IPMI is causing a delay but we're working with the datacenter to resolve it as expeditiously as possible.

Kind regards
 

On 1/18/2025 at 3:10 PM, vizard82 said:

F 2025.01.18 13:59:05 - There is no available or enabled Network Lock mode, sorry.

Hello!

The quoted log entry shows that core problem. Debian 12 is based on nftables. Can you please check which of the following userspace utilities you have in your system: nft, iptables-legacy, iptables-nft, and any other iptables* ?

Kind regards
 

31 minutes ago, Gevurahel said:

I checked the Defender and Firewall, both remain turned off; changed over to WireGuard but still couldn't connect. I already updated Eddie to the latest stable version.

Hello!

We've run out of ideas then. Please send us a system report generated by Eddie just in case it contains some enlightening clue, please see here:
https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/

Kind regards
 

11 hours ago, skunkyone11 said:

I have gluetun and qbittorrent setup and working successfully thanks to other posts in the forum but I’m running into a problem.  When the vpn reconnects in gluetun, I need to manually restart qbittorrent otherwise I’m not connectable (firewalled).  Is there a way to do this automatically?

Hello!

In a GlueTun-based environment, please be aware of the following issue, that's considered by some people a GlueTun bug:
https://airvpn.org/forums/topic/63708-gluetun-port-forwarding-works-for-an-hour/

The thread includes suggestions to significantly mitigate the problem exclusively through GlueTun specific configuration.

Kind regards