go558a83nk

Hello!

We inform you that due to a few problems we are forced to replace the server Kitalpha in Switzerland. A much more powerful server will replace Kitalpha in the next days and it will be connected to a 10 Gbit/s full duplex port and line. As usual, the new server will be announced in this "News" forum in due time. The new server will not only replace Kitalpha but will also provide the additional bandwidth that several users require in Switzerland. We roughly estimate that the server will be available to you by November the 25th.

Kind regards & datalove
AirVPN Staff
 

Hello!

We're very glad to inform you that a new 1 Gbit/s full duplex server located in Madrid (Spain) is available: Jishui.

The AirVPN client will show automatically the new server. If you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

The server accepts OpenVPN connections on ports 53, 80, 443, 1194, 2018 UDP and TCP, and WireGuard connections on ports 1637, 47107 and 51820.

Just like every other Air server, Jishui supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, tls-crypt and WireGuard.
Full IPv6 support is included as well.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

You can check the server status as usual in our real time servers monitor:
https://airvpn.org/servers/Jishui

Do not hesitate to contact us for any information or issue.


Kind regards and datalove
AirVPN Team
 

This is honestly one of the most inspiring things I've read lately. It solidifies why we're all here, either as a customer, contributor, or whatever. I have used nord for the last few years and never thought twice about it. After recent life changes I decided to take the time to invest into my understanding of networking, the internet, etc. On top of future proofing myself I want to learn how to be less reliant on services that I can't trust to not sell every last ounce of privacy I have left. This is some next level community support, I love to see it, and hope nothing but the best for you and those who helped / continue to help every day.

make sure to try wireguard if you haven't already

Wireguard in Eddie

Hello!

We're very glad to inform you that three new 10 Gbit/s full duplex servers located in Phoenix, Arizona, are available: Gunibuu, Kambalia, Sheratan. They have replaced Chalawan, Indus, Phoenix and Virgo with more powerful hardware and higher overall bandwidth.

The AirVPN client will show automatically the new servers; if you use any other OpenVPN or WireGuard client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

The servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637 UDP for WireGuard.

Haedus and Iklil support OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard.

Full IPv6 support is included as well.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

You can check the status as usual in our real time servers monitor by clicking the names of the servers.
 
Do not hesitate to contact us for any information or issue.
 


Kind regards & datalove
AirVPN Team
 

Whoever just helped me, I am literally crying. That was so nice. Jeez.

Hello!

We're very glad to inform you that four new 10 Gbit/s full duplex servers located in New York City are available: Muliphein, Paikauhale, Terebellum, Unukalhai. They have replaced Haedus, Iklil and Lich with more powerful hardware and higher overall bandwidth.

The AirVPN client will show automatically the new servers; if you use any other OpenVPN or WireGuard client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

The servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637 UDP for WireGuard.

Haedus and Iklil support OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard.

Full IPv6 support is included as well.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

You can check the status as usual in our real time servers monitor by clicking the names of the servers.
 
Do not hesitate to contact us for any information or issue.


Kind regards and datalove
AirVPN Team

This is indeed great news!  Well done AirVPN!
 

Does it include Saclateni, which was recently deployed late of last year?  If so, are the new servers more powerful than Saclateni?  And will each of these servers have full-duplex bandwidth of 20 Gbps?
 
As you can see from the attached screenshot, connecting to Saclateni from Anaheim, CA, it shows similar latency (~ 8-9 ms) to other servers (Groombridge and Teegarden) in Los Angeles, CA.  However, it's always puzzled me why I'd get similarly low latency (~ 8-9 ms) to other servers (Bootes, Chalawan, Indus, and Virgo) in Phoenix, AZ.  How is it possible?  It defies the laws of physics!  Anaheim, CA to Los Angeles, CA is a shorter distance than to Phoenix, AZ.  And latency is definitely affected by distance.  Unless these ISPs figure out a way to tunnel packets through a worm hole!  I call shenanigans! 😁
 

Hello!

We're very glad to inform you that in the coming days, according to our infrastructure expansion and improvement plan, all the servers in Los Angeles, New York City and Phoenix will be replaced.

The new servers will have much more powerful hardware and all of them will be connected to a 10 Gbit/s (full duplex) port with guaranteed bandwidth. Therefore, the infrastructure in the mentioned locations will be entirely upgraded to new 10 Gbit/s servers, with 3 servers in LA, 3 servers in Phoenix and 4 servers in New York City. The current servers will be decommissioned on November the 1st.

Please note that all the new servers will have new IP addresses. Connectivity will be very similar, with the notable addition of GTT and Zayo as fiber and tier1 transit providers.

Kind regards and datalove
AirVPN Staff
 

I must say I'm disappointed... AirVPN stopped using the gif of the child throwing money out the window on their deal posts. You can't break tradition AirVPN team!

Good note. By code it seems to be trackers only. In libtorrent's http_tracker_connection.cpp:
[…] if (!m_ses.settings().anonymous_mode) { if (!settings.announce_ip.empty()) { url += "&ip=" + escape_string( settings.announce_ip.c_str(), settings.announce_ip.size()); […] m_tracker_connection->get(url, seconds(timeout) , tracker_req().event == tracker_request::stopped ? 2 : 1 , &m_ps, 5, settings.anonymous_mode ? "" : settings.user_agent , bind_interface() […] I don't think nodes establish connections via HTTP between each other. So yeah, good note. Probably doesn't work the way I imagined. And the docs do mention the necessity for the tracker to accept the ip parameter. That's why.
 

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!

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
 

Hello!

It's ISO 3166 used by Eddie. It does not necessarily reflect AirVPN management ideas on Taiwan's independence. Quite the contrary, if you consider that AirVPN management now operates a server in Taiwan but always refused to consider servers in mainland China and withdrew servers in Hong Kong before it was clawed back by mainland China.

We do understand your complaint even for the reasons explained in this petition https://www.change.org/p/iso-international-organization-for-standardization-correct-taiwan-province-of-china-on-iso-3166-and-change-it-to-taiwan-let-tw-be-taiwan but Eddie Desktop edition considers ISO 3166 in its current code so it takes the current ISO denomination.

Kind regards
 

I love seeing new servers in new countries, thank you!

However, I connected to the Taiwan ("province of China", really?) server today and tried to watch my daily news from Democracynow [dot] org and it wouldn't load the page.

I then switched to one of the new USA servers in San Jose and it loaded the page just fine. 

I wonder who or what is preventing the Democracynow page from loading?  I also wonder if any other pages with "democracy" in them will be blocked on that server or if it's the web site, are they blocking it because it's a Chinese-named server?  

As a non-tech savvy user I'm guessing it's the web page that's blocking it but that's only a guess although I imagine Democracynow would want "province of China" people to watch their show. 
 

Disappointed this is called "province of China" in Eddie, hope this is an oversight.

So is it working?  The other thing that often breaks port forwarding on pfsense is if there are any rules in the openvpn or wireguard "group" firewall rules since those group rules override individual interface rules.

The Telegram CEO political arrest finally settled the debate.
It's unjustifiable, AirVPN need to stay away from these lands or one day or another people in charge of the service will be sent there by a plane and put in a cage for 20 years.

Neither AirVPN's port open test nor yougetsignal's port open test will show "green" unless your whole chain is working and your server (qbit) is listening and responds to the query.  This is important.  Your server must be up and responding.  So if things seem correct on pfsense then then problem is somewhere else, that's my thought.

May be it is all just snake oil but yesterday I was playing with the MTU settings of my OpenVPN client (SSL-wrapped) and for some reason the values around
--tun-mtu 700 --mssfix 692 mtu improve the situation with the throttling quite visibly. SpeedTest shows that higher values (1000 or more) cause the speed to drop steeper and in larger steps, finally causing the complete freezing of transmission, lower values (500 or less) make the connection just slow and unreliable. It seems like 700 is sort of the golden middle.

Also for Linux enabling BBR (Bottleneck Bandwidth and RTT) may increase the throughput. If your Linux kernel is recent enough (4.9 or later), add the following lines to /etc/sysctl.conf: net.core.default_qdisc=fq net.ipv4.tcp_congestion_control=bbr Then execute sysctl --system or reboot.

And one more advice: switch cipher to CHACHA20-POLY1305, it seems that it's now supported by almost all AirVPN servers. It probably means next to nothing but as far as I understand in theory its presence is not that easily detectable by DPI in the SSL-encrypted traffic as AES. To switch add the following parameter to openvpn (if it's started manually): --data-ciphers CHACHA20-POLY1305 Or alternatively edit the data-ciphers line in the .conf file.

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!

Just to avoid potential confusion, the limit is 5 ports per account. Only accounts registered with the earlier contractual agreements can still enjoy 20 ports, i.e. the change enforced on June 2023 is not retro-active:
https://airvpn.org/forums/topic/56405-port-forwarding-availability-change/

We are finalizing a deep infrastructure change, started more than 6 months ago, which will avoid port exhaustion for many years (we guess for the whole company lifetime) and which will allow us to offer more inbound forwarded ports per account (if needed) at a fair price. The change will not rely on "regional" or "server group" ports, so the comfort of the current system will remain.

Kind regards
 

@Greyzy

Hello!

The domain name included in the configuration file generated by the Configuration Generator is fully qualified, as you can verify independently.

The problem is always the same as you can see even from nslookup: poisoned/wrong resolution (into a non-routable address). The problem is not in domain names or configuration files.

Specific example for de3.vpn.airdns.org: note how Quad9 (9.9.9.9) resolves correctly and this adds another strange piece to the puzzle because nslookup said that it queried Quad9 to resolve de3.vpn.airdns.org, but gets an answer that surely does not come from Quad9. This suggests some worrying scenario, but don't let us jump to conclusions too early: just switch to DNS over TLS (supported by Quad9). Configuration needs a little bit of documentation, please check (while you are in the VPN): https://www.elevenforum.com/t/enable-dns-over-tls-dot-in-windows-11.9012/

DNS over TLS will ensure that your DNS queries will not be tampered by your ISP or any MITM (when you are in the VPN you are already protected as the DNS is inside the VPN, but when you're not connected to the VPN you're not protected).


$ drill @9.9.9.9 de3.vpn.airdns.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 27288
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0  
;; QUESTION SECTION:
;; de3.vpn.airdns.org.  IN      A

;; ANSWER SECTION:
de3.vpn.airdns.org.     300     IN      A       37.120.217.245

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 151 msec
;; SERVER: 9.9.9.9
;; WHEN: Wed Jun 26 20:58:14 2024
;; MSG SIZE  rcvd: 52


Also, please answer to the relevant question by @go558a83nk

Kind regards
 

Yes, that's what I'm wondering.  So I'm concerned that your DNS lookups were/are poisoned and that's why you couldn't connect.  Your system was resolving de3.vpn.airdns.org to 127.124.0.3 according to the log.  That's totally wrong.

You definitely need a VPN to avoid whatever DNS your system was/is using but also change to a trusted, secure DNS for when you aren't using VPN.