Staff

Hello!

Some customers have contacted the support team asking for a comment on the port shadow attack described in CVE-2021-3773 and brought into the spotlight for the umpteenth time during the Privacy Enhancing Technologies Symposium 2024: https://citizenlab.ca/2024/07/vulnerabilities-in-vpns-paper-presented-at-the-privacy-enhancing-technologies-symposium-2024/

To explain why, unlike many other VPN services, AirVPN is not vulnerable to various attacks under the generic port shadow umbrella, please download the new paper and read below while watching table 2 on page 121:
in our infrastructure public entry-IP addresses and public exit-IP addresses are not the same (M6). This is an absolute protection against ATIP, connection inference, and port forwarding overwrite and also makes port scan impossible (another reason for which port scan is impossible is given by additional isolation, see the end of the message) per-host connection limit is enforced (M3) making eviction re-route extremely difficult if not impossible static private IP address is implemented (M2) with WireGuard (it can be changed by explicit key renewal user's action) and highly likely with OpenVPN as long as the user connects to the same server with the same key, another (redundant) protection against port scan   In our infrastructure additional protections are in place. We prefer not to disclose them all at the moment, we will just mention the block of any communication between nodes in the same virtual network either through private or public addresses. That's why, unlike any corporate VPN with shared resources, you can't contact any service inside the VPN (except the DNS), not even your own, from a machine connected to the same VPN in our infrastructure. Decapsulation as described on the paper is doomed to fail for this isolation/compartmentalization and this is also another reason for which port scans are not possible.

TL;DR
AirVPN infrastructure, according to the current state of the art in remediation and mitigation by security researchers as well as paper authors, is not vulnerable to the attacks described under the port shadow umbrella in this new paper.
 
Kind regards & datalove
AirVPN Staff
 

Hello!

We're still gathering information from various sources, therefore this is only a provisional answer. At the moment:
 
OpenVPN over SSH and OpenVPN over SSL, to various ports except port 53, work WireGuard to port 51820 works on a limited set of servers. Unfortunately reports on this subject contradict each other about working servers so we can't say for sure which ones. UPDATE: multiple confirmations that WireGuard to port 51820 works on various servers, but not all of them access to bootstrap servers is blocked therefore you can't use Eddie Desktop or Android edition, or the AirVPN Suite integration, but you will need configuration files. UPDATE: we have new reports confirming that "secret" bootstrap servers DO work. You will obtain them by opening a ticket only from your valid AirVPN account to generate configuration from the Configuration Generator it's crucial that you can access one of our web sites. Currently they seem all accessible configuration files can be used with Eddie Android edition, Hummingbird, OpenVPN and WireGuard native clients, and Eddie Desktop edition through the external provider support option OpenVPN in tls-crypt mode over TCP to port 443 (connect to entry-IP address 3 to have this mode) works but only towards a small amount of servers (please test as many as you can) NEW circumvention option: please check this message: https://airvpn.org/forums/topic/59479-block-vpn-in-russia/?do=findComment&comment=237288
Kind regards
 

First the address is clearly written, second you have never sent any refund request (not a ticket, not an e-mail), third you don't need to be "techy" unless with "techy" you mean someone capable to download a software from the Internet and using a mouse to click and double-click.
 
Go trolling somewhere else, we have no time to waste.
 
For the readers: we follow a no-questions-asked refund policy in the first three days. Our refunds are normally delivered within 2 working days (the law prescribes 30 days and we will never break this limit). Additionally (and obviously) you are protected by the EU legal framework on consumers protection for the remote purchase of goods or services, according to which you have the right to a refund within 30 days from the service delivery with a simple written request.
 
Regards

Hello!

The problem:

DCO can be used only by OpenVPN 2.6 (or higher version), it is not supported by 2.5.5, the OpenVPN version launched by Eddie in your case. Quickly solve the problem by telling Eddie to create its own interface and ignore DCO: from Eddie's main window select "Preferences" > "Networking" type eddie in the "VPN interface name" field click "Save" Alternatively you can configure Eddie to run OpenVPN 2.6 with DCO but at the moment DCO is highly experimental so if you want a stable environment just don't use DCO at the moment. If you want a VPN software working mainly in the kernel space then please consider WireGuard, as at this stage it's definitely more stable than OpenVPN with DCO. To switch to WireGuard via Eddie (you can then go back to OpenVPN anytime of course): from Eddie's main window select "Preferences" > "Protocols" uncheck "Automatic" select a line with WireGuard. The line will be highlighted click "Save" Kind regards
 

Hello!
 
We're very glad to inform you that a new Eddie Air client version has been released: 2.24 beta. It is ready for public beta testing.
 
How to test our experimental release:
Go to download page of your OS Click the button Switch to EXPERIMENTAL Download and install
This is a new version of Eddie Desktop (Windows / Linux / MacOS).
We know there is still 2.21.8 as stable, and 2.22.x and 2.23.x series never reached the stable version.
We hope that this version 2.24.x will be tested and reach a stable release.

Internally (in terms of development and code) it represents a significant step forward for us: the CLI editions are compiled with dotnet 7, without Mono, Xamarin and any dependency on NetFramework (Windows) or Mono (Linux, MacOS). 
All CLI projects can be opened in Visual Studio Code and debugged on any OS (macOS, Linux, Windows) without the need to use Xamarin, Visual Studio or Visual Studio for Mac. 
A new UI is in the works that will finally remove the dependency on Mono and Xamarin, but we don't have a release date to announce yet. 
The MacOS CLI is new (previously there was only the UI, or the UI with "-cli"), and it's also native for arm64. 
Overall, there has been a significant effort to clean up and modernise the code, and to prepare our build/deploy scripts for the new UI as well. 

We understand that there are still tickets or posts that we haven't responded to yet, but we preferred to complete this step first.

Main changelog: [new] WireGuard is now the default communication protocol [new] All CLI editions can be compiled and debugged with VSCode and .NET7 [new] [macOS] CLI-only edition, built with .NET7, without Xamarin [new] New commandline only option "elevated.method" [change] OpenVPN 2.6.9 [change] [linux] CLI edition, built with .NET7, without Mono [change] [linux] .deb and .rpm, removed Mono dependency [change] [linux] .deb package tries to initialize elevated service at install/uninstall, .rpm package still missing this feature. [change] [windows] CLI edition, built with .NET7 [change] [all] Better management of SIGTERM signal [change] [all] Don't check if app dir is writable for portable-mode, now managed by presence of "portable.txt". [bugfix] [linux] terminal issue with sudo elevation [deprecation] [all] -cli mode for UI. Use CLI edition directly, now available in all supported platform. [deprecation] [windows] Vista builds [deprecation] [windows] Windows Firewall Network Lock mode [deprecation] [linux] x86 builds [deprecation] [linux] Portable Mono builds
 

Hello!

The paramount IPv6 privacy problem, which was considered by many as a critical or fatal flaw compromising adoption and usage, has been resolved through privacy extensions:
https://www.internetsociety.org/resources/deploy360/2014/privacy-extensions-for-ipv6-slaac/

Nowadays, ten years after that article by The Internet Society and 17 (seventeen) years after RFC 4941 virtually all widespread systems have finally adopted the very much needed privacy extensions. However, one bad apple may compromise the whole local network. See for example this paper: https://arxiv.org/abs/2203.08946 where the authors show how a single device at home that encodes its MAC address into the IPv6 address can be utilized as a tracking identifier for the entire end-user prefix. Therefore, it is good practice to verify with care every and each device and making sure that their Operating Systems implement the privacy extensions.

Other than that, we can't see any serious hindrance to adopt IPv6 as far as it pertains to privacy. Furthermore, in AirVPN we picked an unorthodox approach, i.e. we implemented NAT66 with ULA, as it is one of those rare cases where it comes handy to strengthen the anonymity layer (a thoughtful analysis of the pros and cons of NAT in IPv6 can be found in the following article for example https://blogs.infoblox.com/ipv6-coe/you-thought-there-was-no-nat-for-ipv6-but-nat-still-exists/ while a pragmatic approach is here: https://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question/).

Switching from privacy to security, probably an informed choice can start by reading this article, that also includes other precious sources, again by the Internet Society:
https://www.internetsociety.org/deploy360/ipv6/security/faq/

Kind regards
 

Hello!

We're very glad to inform you that Eddie 3.2.0 beta 2 is available, featuring even more bug fixes and improvement of important features. All the essential changes can be found in the first message of this thread, with updated link to download the new APK.

Thank you for your invaluable tests so far, and thanks in advance for any future test!

Kind regards & datalove
AirVPN Staff
 

I can only verify it from one device as changing the endpoint on the other device is quite tedious, but it seems that this happens only with Menkent so far. But I need to test it more in order to make sure. Also, it seems that it only happens with the default port, using port 47107 seems to work flawlessly. I'm going to switch the port and report back about it.

Hello!

We regret to inform you that we will be discontinuing the service to residents of Italy as of February the 19th, 2024.
From the above date, any user registering on the platform must declare that he/she is not a resident of Italy. The purchase page will have IP address-based geolocation and will not be served to IP addresses located in Italy. We will not interrupt the service to current subscribers until the natural expiry date and the refund policy will be granted as usual.
 
REASONS FOR DISCONTINUATION
The so-called "Italian Piracy Shield" is a legal framework with implementing regulation by AGCOM (Italian Telecommunications Authority) that forces operators offering services in Italy to block access to end services through IP blocking and/or DNS poisoning.  The list of IP addresses and domain names to be blocked is drawn up by private bodies authorised by AGCOM (currently, for example, Sky and DAZN). These private bodies enter the blocking lists in a specific platform. The blocks must be enforced within 30 minutes of their first appearance by operators offering any service to residents of Italy.

There is no judicial review and no review by AGCOM. The block must be enforced inaudita altera parte and without the possibility of real time refusal, even in the case of manifest error. Any objection by the aggrieved party can only be made at a later stage, after the block has been imposed. For further details:
https://www-wired-it.translate.goog/article/piracy-shield-agcom-piattaforma-streaming-pirata-calcio-segnalazioni/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp

The above requirements are too burdensome for AirVPN, both economically and technically. They are also incompatible with AirVPN's mission and would negatively impact service performance. They pave the way for widespread blockages in all areas of human activity and possible interference with fundamental rights (whether accidental or deliberate). Whereas in the past each individual blockade was carefully evaluated either by the judiciary or by the authorities, now any review is completely lost. The power of those private entities authorized to compile the block lists becomes enormous as the blocks are not verified by any third party and the authorized entities are not subject to any specific fine or statutory damage for errors or over-blocking.

By withdrawing service availability from Italy, AirVPN will be able to stay outside the scope of the framework and maintain integrity and efficient operations.

We certainly sympathise with our fellow Italian citizens, and we will be happy to offer advice and alternatives. We would also like to remind them of our more than ten years of support for the Tor network, which is freely accessible even from Italy, and which is becoming increasingly reliable and fast thanks to a myriad of small contributions like ours.

Kind regards and datalove
AirVPN Staff
 

Hello!

We checked thoroughly and all of your tickets have been answered in an average time of 8 hours. All of them. EDIT: we want to add to make it clear to the readers and to be fair to the support team that your last ticket was replied to in 1 hour and 15 minutes.



Kind regards
 

Hello!

We were easy prophets in this case. The catastrophic blackout referred to in the article is a concrete example of the risk we denounced, a violation of fundamental rights, a confirmation of the wisdom of our decision and a demonstration of the irresponsible and odious frivolity of decisions taken by private actors. Our infrastructure must not be polluted by repugnant decisions taken by private entities that seem to have little or no technical competence and that, so far, enjoy impunity for any mistake, no matter how serious.

Kind regards
 

Hello!

The paramount IPv6 privacy problem, which was considered by many as a critical or fatal flaw compromising adoption and usage, has been resolved through privacy extensions:
https://www.internetsociety.org/resources/deploy360/2014/privacy-extensions-for-ipv6-slaac/

Nowadays, ten years after that article by The Internet Society and 17 (seventeen) years after RFC 4941 virtually all widespread systems have finally adopted the very much needed privacy extensions. However, one bad apple may compromise the whole local network. See for example this paper: https://arxiv.org/abs/2203.08946 where the authors show how a single device at home that encodes its MAC address into the IPv6 address can be utilized as a tracking identifier for the entire end-user prefix. Therefore, it is good practice to verify with care every and each device and making sure that their Operating Systems implement the privacy extensions.

Other than that, we can't see any serious hindrance to adopt IPv6 as far as it pertains to privacy. Furthermore, in AirVPN we picked an unorthodox approach, i.e. we implemented NAT66 with ULA, as it is one of those rare cases where it comes handy to strengthen the anonymity layer (a thoughtful analysis of the pros and cons of NAT in IPv6 can be found in the following article for example https://blogs.infoblox.com/ipv6-coe/you-thought-there-was-no-nat-for-ipv6-but-nat-still-exists/ while a pragmatic approach is here: https://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question/).

Switching from privacy to security, probably an informed choice can start by reading this article, that also includes other precious sources, again by the Internet Society:
https://www.internetsociety.org/deploy360/ipv6/security/faq/

Kind regards
 

Wait.. in this case it's even possible to configure any BitTorrent client for this if the client offers the option to set which IP address is announced to the trackers. libtorrent-rasterbar can do that via the announce_ip option, at least (qBittorrent: Settings > Advanced > Announced IP address to trackers (Restart required)). It's a bit of a hassle, though, as you will need to know the second exit address in advance. But it should work if the tracker supports the ip parameter.

Hello!

p2p is allowed on pool 2 but it can be really used only by those programs that let you configure which IP address to announce (non existing, as far as we know). More in general, pool 2 is not suitable for any program which announces itself autonomously. In AirVPN infrastructure, the VPN traffic reaches the Internet through one exit IP address, but "pool 2" is the set of ports of another IP address (let's name it exit IP address 2, in brief exit 2). If a program receives an unsolicited incoming packet from the Internet through exit 2, it will reply properly. This happens whenever you advertise on your own how to reach your service (a web or FTP server, a game server, and so on).

However, with p2p programs, it's the program itself which must advertise. DHT or a tracker will record the address they receive the advertisement (of the port etc.) from, and they will say to other peers that your p2p program is reachable on exit 1, with its pool 1 ports; however, if you have remotely forwarded a pool 2 port, peers would never be able to reach your program, because they would send packets to a port of another IP address (exit 1, the address recorded by DHT and/or trackers). The problem could be resolved by manual setting (see for example https://userpages.umbc.edu/~hamilton/btclientconfig.html#BTConfig ) when you need to seed only - additional tests are required.

This is an important limitation that might be overcome in the future, for example by letting the user pick which exit IP address its traffic must go to the Internet through. In the meantime, by using pool 2 (and when necessary additional pools) for anything different from p2p and crypto wallets, port exhaustion problem is solved (in most cases only 1 forwarded port is needed for p2p).

Kind regards
 

Hello!

Thank you for linking to this interesting and well written article.
 
Yes, it has been highlighted by Windscribe, by us, and by multiple sources as early as 2022. For example:
https://airvpn.org/forums/topic/53136-vpn-companies-relationship-mesh/?tab=comments#comment-189777

and you may also like to check the search results:
https://airvpn.org/search/?q=crossrider
 
The company name, VAT ID and the Registration Code at the Chamber of Commerce of Italy is written at the bottom of each web site page. Through the European Commission VIES you can verify the company data by entering the VAT ID:
https://ec.europa.eu/taxation_customs/vies/#/vat-validation

If you have a subscription to a business intelligence and analytics reporting companies, for example Dun & Bradstreet, you can also get more information such as business reliability, solvency and so on, which, when correlated to other information, for example donations to specific organizations, can provide you with at least clues of what you may look for.

Kind regards
 

Hello!

DNS management has been improved in Eddie 2.24.2 beta version. Some systemd-resolved questionable working modes are now handled more properly. Since Ubuntu latest releases have systemd-resolved installed and running by default, can you please test the new Eddie and check whether the problem gets resolved? Please see here: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/

An alternative is disabling systemd-resolved to revert back to a more robust, UNIX-like DNS management. https://gist.github.com/zoilomora/f7d264cefbb589f3f1b1fc2cea2c844c

Please let us know whether or not the suggestion you will adopt solves the problem.

Kind regards
 

Hello!

We're sorry to inform you that Altais (Kiev, Ukraine) has been canceled by the service provider due to our refusal to provide 100% warranty that non-permitted activities will ever take place on the server, which is of course an impossible commitment not only for VPN but for any ISP providing private citizens with any online service in general.

We're also sorry to inform you that we have no plans at the moment to rent new servers in Kiev or anywhere else in Ukraine because of various factors, among which the behavior of local police (remember in the past the request for bribes masked as fines to unlock servers) and the unreliability of local datacenter managers, which seem to be used to cancel services without notification and without refunds.

Over the past decade, the behavior of Ukrainian datacenters and local authorities has brought nothing but inconvenience to our customers, so it is time to (at least temporarily) suspend operations there.

Kind regards
AirVPN Staff
 

Hello!

p2p is allowed on pool 2 but it can be really used only by those programs that let you configure which IP address to announce (non existing, as far as we know). More in general, pool 2 is not suitable for any program which announces itself autonomously. In AirVPN infrastructure, the VPN traffic reaches the Internet through one exit IP address, but "pool 2" is the set of ports of another IP address (let's name it exit IP address 2, in brief exit 2). If a program receives an unsolicited incoming packet from the Internet through exit 2, it will reply properly. This happens whenever you advertise on your own how to reach your service (a web or FTP server, a game server, and so on).

However, with p2p programs, it's the program itself which must advertise. DHT or a tracker will record the address they receive the advertisement (of the port etc.) from, and they will say to other peers that your p2p program is reachable on exit 1, with its pool 1 ports; however, if you have remotely forwarded a pool 2 port, peers would never be able to reach your program, because they would send packets to a port of another IP address (exit 1, the address recorded by DHT and/or trackers). The problem could be resolved by manual setting (see for example https://userpages.umbc.edu/~hamilton/btclientconfig.html#BTConfig ) when you need to seed only - additional tests are required.

This is an important limitation that might be overcome in the future, for example by letting the user pick which exit IP address its traffic must go to the Internet through. In the meantime, by using pool 2 (and when necessary additional pools) for anything different from p2p and crypto wallets, port exhaustion problem is solved (in most cases only 1 forwarded port is needed for p2p).

Kind regards
 

Thanks, appreciate your prompt and detailed response. 

Wrt to performance on mac, would you expect wireguard or openvpn (using hummingbird) to be "better"? Idk enough to know what the best way to measure performance would be, but would love to get your perspective. Have been drawn to wireguard for its simplicity and performance, but I didn't realize I wasn't getting the full benefit on a mac due to the kernel restrictions. 

In reality none of this matters for my typical use, I'm just curious and enjoy trying to tweak things to get best performance. I have really appreciated how Airvpn allows users to look behind the hood and dig into the technical details of what's going on, if they are so inclined.

Hello!

Currently not, Hummingbird searches in "/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/homebrew/bin:/opt/homebrew/sbin". Reading the $PATH variable and add it to the search paths is an option we will consider for sure. Should WireGuard library become available for macOS too we will of course use it.

As a momentary patch you can consider a symlink for wg and wireguard-go - both are used by Hummingbird.
 
No, we don't, sorry. Hummingbird makes the OpenVPN3-AirVPN library available to macOS users in a single comfortable binary, to boost performance remarkably over OpenVPN 2 or the OpenVPN3 mainline library, but for WireGuard it is just a wrapper of the tools as we don't have the library in this environment.

Since in macOS WireGuard does not run in the kernel space (no kernel module) this core feature for performance is lost and running wg tools or Hummingbird is most probably equivalent. We can't even design a kernel extension (not even if we had the time to plan it) because kexts are no longer allowed.

However, with Hummingbird you have a built-in Network Lock (through pf) which wg tools don't offer and that may come very handy to prevent any possible traffic leak outside the VPN tunnel.

Kind regards
 

Hello!

UFW is an iptables wrapper which adds its own chains. To complicate the matter even more, UFW does not work with nftables, but probably your system is based on nftables (unless it is a very old distribution). Therefore translations iptables<->nftables are continuously needed and we have seen that some bug affects them. You should consider to drop UFW and use directly the nft userspace tool to set rules, or iptables-nft if you prefer the iptables syntax. In this last case, force Eddie to use iptables too (if Eddie finds nft in your system, it will use it) in the "Preferences" > "Network Lock" window.

Kind regards
 

Hello!

The paramount IPv6 privacy problem, which was considered by many as a critical or fatal flaw compromising adoption and usage, has been resolved through privacy extensions:
https://www.internetsociety.org/resources/deploy360/2014/privacy-extensions-for-ipv6-slaac/

Nowadays, ten years after that article by The Internet Society and 17 (seventeen) years after RFC 4941 virtually all widespread systems have finally adopted the very much needed privacy extensions. However, one bad apple may compromise the whole local network. See for example this paper: https://arxiv.org/abs/2203.08946 where the authors show how a single device at home that encodes its MAC address into the IPv6 address can be utilized as a tracking identifier for the entire end-user prefix. Therefore, it is good practice to verify with care every and each device and making sure that their Operating Systems implement the privacy extensions.

Other than that, we can't see any serious hindrance to adopt IPv6 as far as it pertains to privacy. Furthermore, in AirVPN we picked an unorthodox approach, i.e. we implemented NAT66 with ULA, as it is one of those rare cases where it comes handy to strengthen the anonymity layer (a thoughtful analysis of the pros and cons of NAT in IPv6 can be found in the following article for example https://blogs.infoblox.com/ipv6-coe/you-thought-there-was-no-nat-for-ipv6-but-nat-still-exists/ while a pragmatic approach is here: https://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question/).

Switching from privacy to security, probably an informed choice can start by reading this article, that also includes other precious sources, again by the Internet Society:
https://www.internetsociety.org/deploy360/ipv6/security/faq/

Kind regards
 

Have just put a post on the Ubiquity forums if anyone else is running into simlar issues...

https://community.ui.com/questions/AirVPN-Wireguard-Timeout-Issues-UDM-SE/cabd29e4-675d-4de4-b9ff-5d6e216afc8e

Hello!

Some customers have contacted the support team asking for a comment on the port shadow attack described in CVE-2021-3773 and brought into the spotlight for the umpteenth time during the Privacy Enhancing Technologies Symposium 2024: https://citizenlab.ca/2024/07/vulnerabilities-in-vpns-paper-presented-at-the-privacy-enhancing-technologies-symposium-2024/

To explain why, unlike many other VPN services, AirVPN is not vulnerable to various attacks under the generic port shadow umbrella, please download the new paper and read below while watching table 2 on page 121:
in our infrastructure public entry-IP addresses and public exit-IP addresses are not the same (M6). This is an absolute protection against ATIP, connection inference, and port forwarding overwrite and also makes port scan impossible (another reason for which port scan is impossible is given by additional isolation, see the end of the message) per-host connection limit is enforced (M3) making eviction re-route extremely difficult if not impossible static private IP address is implemented (M2) with WireGuard (it can be changed by explicit key renewal user's action) and highly likely with OpenVPN as long as the user connects to the same server with the same key, another (redundant) protection against port scan   In our infrastructure additional protections are in place. We prefer not to disclose them all at the moment, we will just mention the block of any communication between nodes in the same virtual network either through private or public addresses. That's why, unlike any corporate VPN with shared resources, you can't contact any service inside the VPN (except the DNS), not even your own, from a machine connected to the same VPN in our infrastructure. Decapsulation as described on the paper is doomed to fail for this isolation/compartmentalization and this is also another reason for which port scans are not possible.

TL;DR
AirVPN infrastructure, according to the current state of the art in remediation and mitigation by security researchers as well as paper authors, is not vulnerable to the attacks described under the port shadow umbrella in this new paper.
 
Kind regards & datalove
AirVPN Staff
 

Hello!

We're very glad to announce a remarkable expansion of our inbound remote port forwarding system aimed at avoiding once and for all the port exhaustion problem.
The comfort and the growth problem
In the AirVPN "Port Forwarding" service, unlike some of our competitors we grant that assigned ports are not server specific. We also ensure that they remain permanently reserved to an account for as long as any valid plan is active. This unique system offers unparalleled comfort as you don't have to worry about server switches, zone selections and program re-configurations. However, ports are only 65536, because the space reserved for them in a TCP/IP packet header is 2 bytes, and the inconvenience of the great comfort brought by the AirVPN service is that the port exhaustion is nearing as more and more users decide to use the service.
 
 
A "no compromise" solution
Our goal was to avoid port exhaustion while maintaining maximum comfort. We are introducing a new system specifically designed to achieve this goal.

Now we allocate not only a port number, but a port number associated with a port pool. For example a port on pool :1 can be assigned to a user, and the same port number in pool :2 can be assigned to another user.
Existing assigned port will come from the first pool (:1). Currently we offer two pools, but more pools can be added whenever necessary. With this method, port exhaustion is postponed indefinitely while the comfort of the service is preserved.

In the following example you can see the pool (:1, :2 for now) specified right after the port number. The account has port 24860 reserved in both pools.
    How it works
Each Air VPN server sends out clients' VPN traffic through a shared exit IP address.
From now on, AirVPN servers feature multiple exit IP addresses, each of which is linked to a specific port pool. Therefore we can determine which pool a port/address is associated with and route traffic accordingly.
  The implications for AirVPN users and customers
The obvious good impact is that port availability increases dramatically. The new system is not difficult at all and extremely similar to the previous one: simply use DDNS (*) names with port forwarding, and not the direct IP address. Your account name(s) based on AirVPN's DDNS will always resolve into the correct server's exit-IP address related to the pool of your assigned port.
If you prefer to rely on IP addresses or anyway you don't want to define domain names through AirVPN's DDNS, you can find the correct IP address used by clicking the Test Open button available in your AirVPN account port panel. Please note that this IP address could change over time, so domain names defined by DDNS are a more comfortable solution.
There is only a modest caveat (which could be resolved in the future), please see below.
 
Caveat
Any setup not involving manual communication on how to connect to a service, as it happens with a p2p program, does not need domain names at all. If a program transmits autonomously how it can be reached (typical examples: some blockchain wallet programs, all torrent programs), at this stage please make sure you forward a port from pool 1 for those programs. For p2p programs that allow manual announcement configuration of the IP address, you can also use pool 2.

(*) DDNS is a service offered automatically for free to all accounts and included on every and each AirVPN plan.

Kind regards & datalove
AirVPN Staff