Staff

In this case you're most probably fine: if we interpret correctly the data set you provided the behavior is expected. The "pinger" has always remained disabled (as far as we remember) when Eddie is connected to the VPN. Maybe you had some release with a bug? The unexpected behavior in this case would be Eddie that "pings" the VPN servers even while the system is connected to one of them. Kind regards

@tranquivox69 Hello! Probably everything is fine. The "pinger" is disabled when the system is connected to some VPN server, according to the logic that the round trip times for Eddie connection purposes make sense only between the client node and the VPN servers, and not between client+VPN server and the all other VPN servers. https://github.com/AirVPN/Eddie/blob/de5c1ebb91030dc654a4cd3de81bfa8225982400/src/App.CLI.Common.Elevated/ping.cpp public bool GetCanRun() { bool canRun = true; // Logic: Can't ping when the connection is unstable. Can't ping when connected to server. if (Engine.Instance.IsConnected()) { canRun = false; } else if (Engine.Instance.IsWaiting() && (Engine.Instance.WaitMessage.StartsWithInv(LanguageManager.GetText("WaitingLatencyTestsTitle")) == false)) canRun = false; return canRun; } If you want the pinger to be active even while the system is connected to the VPN you can set canRun to true (here above), even when Engine.Instance.IsConnected() is true. When the pinger is active you should not see in Windows "ping.exe" processes (if we're not mistaken). See also: https://github.com/AirVPN/Eddie/blob/de5c1ebb91030dc654a4cd3de81bfa8225982400/src/App.CLI.Common.Elevated/ping.cpp and https://github.com/AirVPN/Eddie/blob/de5c1ebb91030dc654a4cd3de81bfa8225982400/src/Lib.Core/Jobs/Latency.cs Kind regards

@jahoolala Hello! Does anything change if you add the following custom directive: mssfix 1280 To add it, from Eddie's main window select "Preferences" > "OVPN Directives", type the above directive in the custom directives field, click "Save". Re-start a connection to apply the change. If the problem persists let us see a system report. https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-%E2%80%93-heres-what-to-do/ Kind regards

@Bertin Hello! Please try to side load it: https://airvpn.org/android/eddie/apk/tv/ Kind regards

@doncammne Hello! Please open a ticket, because we don't see any delay at the moment. Kind regards

Use https://www.startpage.com - it will query Google Search and return to you the exact Google Search reply. Kind regards

@p9974839 Hello, we also see a sea of green. We still have 11000 Mbit/s free (full duplex), or if you prefer 22000 Mbit/s free total, in Canada which are never used by anyone, so the infrastructure is greatly oversized. Yellow means that you still have at least 1000 Mbit/s free on the server. Look at the very screenshot you sent us: it shows that you have plenty of choices in Canada on poorly used servers: 15 servers offer more than 1 Gbit/s (more than 500 Mbit/s full duplex)! Check our previous message as well. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s full duplex server located in Berlin (Germany) is available: Taiyi. 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 connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637 and 47107 UDP for WireGuard. Taiyi supports 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 and 4096 bit DH key not shared with any other VPN server. You can check the status as usual in our real time servers monitor: https://airvpn.org/servers/Taiyi Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team 

@kbps Hello! Not really, because the feature is included in our WireGuard setup since the very beginning, when we offered WireGuard as a beta feature some years ago. If you want more information, please see here: https://www.wireguard.com/protocol/ In this way we can implement a recognized as quantum-resistant cipher if needed, according to our customers request . You may ask why don't you pick one PQ cipher right now? You already configured the most part! We have excellent reasons not to do so right now: It's premature. In spite of the hype, currently a quantum computer doesn't work for any practical purpose to break even the weakest encryption algorithm and in the last 40 years or so the expected date to have a working quantum computer capable to perform something more than basic arithmetic have been shifted decade after decade. Research has progressed more slowly than ultra-optimists expected. To break RSA 2048 in a reasonable time a rigorous simulation shows that you need at least 1 million (probably up to 10 millions) of physical qubit (you need probably at least 10'000 logical qubits, and due to the astronomically high error rate of qc, to rely on them you need ~ x100 physical qubits). Nowadays the biggest companies are struggling to beat 433 logical qubits qc (IBM promised 1000 logical qubits machine within the beginning of 2024). It hits performance. Some promising PQ ciphers use 64 KB or larger public and private keys and you will notice a performance hit if you have a Gbit/s line and you're used to the high performance our infrastructure is normally capable to provide. The load both on server and client will increase. It exposes our customers to unnecessary risks. Post-quantum algorithms are far less well-studied. Any PQ algorithm, that today is considered safe, can be compromised tomorrow by "classical" computes.. It happened already to SIKE, which before the spectacular fall was considered one of the strongest and best algorithm for Diffie-Hellman key exchange in a post-quantum world. It was cracked in a matter of hours a few months ago with a program running in a single thread of a single core of a desktop CPU. SIKEp434 was broken within approximately an hour, SIKEp503 cracking required 2 hours, SIKEp610 8 hours and SIKEp751 21 hours. See also https://www.securityweek.com/nist-post-quantum-algorithm-finalist-cracked-using-classical-pc/ So, we have the infrastructure ready to add a PQ cipher, when and above all if it will be necessary, without exposing you to risks of cracking by classical computers and/or "performance hit for nothing". Kind regards

Hello! Please see here: https://airvpn.org/forums/topic/49876-new-feature-dns-block-lists/ Kind regards

Hello! We 100% confirm what @OpenSourcerer wrote. If we assumed that the "selection" is not performed by some source outside AirVPN, the reported behavior would be inexplicable. We can only confirm that we do not alter traffic payload in any way (and we can't do it, not even if we wanted to, when you have end-to-end encryption). So we are reasonably convinced that it is caused by something outside AirVPN, and this something (a web server?) modifies its behavior according to the source which accesses the resource. Kind regards

Hello! 34000 Mbit/s (full duplex, i.e. 68000 Mbit/s total) available in Canada, in peak hours about 23000 Mbit/s used. Plenty of bandwidth still available. Considering Canada extension, and the fact that WireGuard diffusion will cause higher bandwidth demand (mobile devices and routers can get more), the asymmetry between Vancouver (12000 Mbit/s) and Toronto (52000 Mbit/s) will be progressively balanced according to needs (probably you have seen that 2000 Mbit/s have been added today in Toronto). Please consider that the available bandwidth is real, it's not like having a 10 Gbit/s line, sharing it with dozens of servers, and declaring each of those servers as "10 Gbit/s" servers, as some competitors do. @knighthawk The kernel of the servers balance the demand quite efficiently. For example, if a client is draining 1 Gbit/s (i.e. 2 Gbit/s on the server, 100%) while 20 other clients are idle, the first client may continue to do so. As soon as the idle clients start demanding bandwidth, the provided bandwidth will be re-distributed in a very short time, and the initial client will be no more able to use 2 Gbit/s. On top of that, we also take care (again thanks to kernel features) to distribute the incoming connections to different OpenVPN instances, so that a round robin distribution will contribute to keep balance. It's necessary only with OpenVPN, as a single OpenVPN process runs always in a single thread, while with WireGuard this is not necessary (and not applied). Kind regards

Hello! We offer WireGuard with per-client pre-shared key for post-quantum resistance, so we're ready, in the extremely unlikely event that a powerful quantum computer could work effectively during our life time. WireGuard pre-shared key is offered by default, you don't need any specific action. Kind regards

Hello! Your message is from 2019 and in the meantime new challenges and problems arose in quantum computing, but anyway we have an important update. We offer WireGuard with per-client pre-shared key for post-quantum resistance, so we're ready, in the extremely unlikely event that a powerful quantum computer could work effectively during our life time. WireGuard pre-shared key is offered by default, you don't need any specific action. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s full duplex server located in Vancouver (Canada) is available: Ginan. 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 connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637 and 47107 UDP for WireGuard. Ginan supports 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 and 4096 bit DH key not shared with any other VPN server. You can check the status as usual in our real time servers monitor: https://airvpn.org/servers/Ginan Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team 

Hello! The proper guide is this one: https://openwrt.org/docs/guide-user/services/vpn/wireguard/client Keep a profile generated by the Configuration Generator, according to your preferences, available (it's just a text file). From it, you can find the settings for the initial configuration: WG_IF="vpn" WG_SERV="SERVER_ADDRESS" <-- the VPN server address you see in the "Endpoint" entry WG_PORT="1637" <-- you can see it in the "Endpoint" entry WG_ADDR="..." <-- the IPv4 address you find in the profile "Address" entry WG_ADDR6="..." <-- the IPv6 address you find in the profile "Address" entry Skip the "Key management" section. In our system your WireGuard key is generated by our infrastructure. In the same file you also find the public key, the pre-shared key and the DNS server address that you will need to complete the configuration, respectively in the PublicKey entry, the PresharedKey entry and the DNS entry. Kind regards

@geno5 Hello! If the notice is authentic, you must have suffered a traffic leak outside the VPN tunnel, so you must have had "Network Lock" feature disabled.. Please make sure you have Network Lock enabled. It will prevent any possible traffic leak outside the VPN tunnel, even leaks caused by misconfiguration of any program and unexpected VPN disconnection. It will prevent leaks even in case Eddie or OpenVPN or WireGuard suffer a crash (it is as reliable as your system packet filtering tool is, nothing to share with obsolete and unreliable kill switches). Network Lock, as you know from the welcome e-mail, the guide for beginners, the FAQ answers, the general recommendations on the How-To forum, is a set of firewall rules, therefore it works properly regardless of the underlying VPN protocol (OpenVPN, WireGuard). It can be activated from Eddie's main window before you start a connection (and you can tell Eddie to activate it automatically when it starts). It is also active by default in the Eddie Android edition app and on the AirVPN Suite. To optimize your torrent software performance and make sure that it is not misconfigured you can follow this guide: https://airvpn.org/faq/p2p/ Kind regards

@Lee47 Hello! Just out of information, your requirements for 4K HDR are excessive! Netflix recommends 25 Mbit/s and Amazon 15 Mbit/s. https://nvidia.custhelp.com/app/answers/detail/a_id/4182/~/what-bandwidth-do-i-need-for-4k-hdr-streaming Kind regards

@SurprisedItWorks Hello, that's correct. According to recent reports, Netflix USA allows streaming through our servers only of those contents of Netflix exclusive property, even when the user who tries to access such content is a USA citizen.. The other contents are perhaps too problematic (because of the copyright mafia, one might argue) to allow access from dedicated servers (or IP addresses not assigned to USA residential ISPs), even when such access is performed by a citizen living in the USA. Kind regards

@nemoomen Hello! This is the fatal error which causes Eddie to exit: Routes, add 2607:ff48:aa81:200:7624:912a:38e8:a606/128 for interface "enp11s0" failed: Exception: exit:2; err:RTNETLINK answers: File exists It's unclear why that route (to Acamar entry-IP address 3) is already there on enp11s0 ("file exists") this is matter for developer's investigation. Try to delete (while Eddie is not running) the following file: /home/lillianr/.config/eddie/default.profile then reset your TCP/IP stack and interfaces, and check whether Eddie re-starts correctly (that default.profile file is Eddie's configuration file so you will need to re-enter your AirVPN account credentials and Eddie settings). Kind regards

Hello! Can you give us a list of VPN servers which you experience this IPv6 problem on? Kind regards

@DZ-015 Hello! Please test a connection via WireGuard as well as a connection on OpenVPN, protocol TCP, port 443, entry-IP address three, and check whether one of those connection modes resolves the issue. You can change connection mode in the following way: from Eddie's main window select "Preferences" > "Protocols" uncheck "Automatic" select the line describing one of the aforementioned modes. The line will be highlighted click "Save" and test again connections If the problem persists, please open a ticket and include a system report https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

@nan0tEch Hello! Try the following: enforce mssfix n directive (n is in bytes). This directive tells OpenVPN to split TCP packets (inside the UDP tunnel) larger than n bytes. This directive may resolve MTU size problems. Try for example with mssfix 1320 if your connection is via Ethernet or WiFi if you have an asymmetric line (ADSL etc.), make sure that the maximum allowed upload bandwidth of the torrent software does not "choke" the throughput. To stay on the safe side, limit (from its own settings) the torrent software to use at most 66% of your available upload bandwidth Check any combination of the above attempts (only 1, only 2 and both 1 and 2). Kind regards

@Cthulu_007 Hello and thank you for your great feedback and support! AirVPN Suite version 2.0 for Linux will implement traffic splitting on an application basis. The first alpha preview is due in a matter of weeks (the first addition is however WireGuard support and integration, so in the alpha 1 you might not see a full traffic splitting implementation yet). In the meantime, if you need a simplified approach, you can split traffic on an application basis through any means of virtualization. Please remember, as usual, that any traffic splitting poses risks of de-anonymization in specific circumstances. Splitting traffic, therefore, must be considered a sensitive action which should be performed only by those who perfectly understand what they are doing. Kind regards

Hello! Thank you for your great feedback. Try this procedure: - from the left pane select "Logout" - tap the big central button to login again - re-enter your credentials - check whether all the keys appear in the box "AirVPN key" (tap the key name and a full list should pop-up) Kind regards