Staff

Hello! Before a thousand users ask : no, OpenVPN does NOT support SSLv2 / v3, so this attack is inessential for OpenVPN. Kind regards

Hello, we are investigating the issue, please hold on. Kind regards

Situation is very fluid, please check here regularly, there are important news since when we wrote our previous message: https://airvpn.org/topic/9223-netflix/

Chromium is not Chrome. "Chromium is the open-source web browser project from which Google Chrome draws its source code." Differences: https://en.wikipedia.org/wiki/Chromium_%28web_browser%29#Differences_from_Google_Chrome Kind regards

Hello, to inform correctly our readers we wish to correct false information you persist on providing in your messages. Your request for Absolute Radio was taken in charge a few minutes after you wrote it. It was fulfilled after a few hours, in August 2015. When we asked for a confirmation from you you didn't even bother to check or even reply to our communications. Your request for ABC Australia was never filed on a ticket but ABC Australia is accessible from all of our VPN servers since June 2015. Kind regards

Hello! We're currently experiencing issues in the calculation of stats in our real time servers monitor. The issues affect the data pertaining to users top speed and time. No issue is currently affecting servers stats. We're working to fix the issues and we kindly ask you to ignore the aforementioned tables in the meantime. EDIT: the problem has been solved. Kind regards

Hello, AirVPN is in that 2.94% of VPNs put in "A" (best) grade and PCI DSS compliant (according to their own tool at least). Kind regards

Hello! It could, but anyway you can reproduce the mentioned situation right now. Keep Network Lock enabled, and before hibernation disconnect the system from the VPN, but do NOT shut down the Air client. Only after the VPN disconnection has been completed hibernate the machine, In this way, when you wake up the machine, firewall rules are always the same (Network Lock) but Eddie will not try to reconnect to any VPN server. WiFi or Ethernet connection will be established as usual without interference from Eddie, but no data can go out to the Internet. At that point, you can decide whether conneting to a VPN server, or just shut Eddie down to restore connectivity (Network Lock will be disabled, therefore firewall rules restored). Kind regards

Hello, we're sorry but access to all other regional Netflix is blocked by Netflix itself. For each server you can have Netflix USA or no Netflix at all. We fully understand you and we agree with you but that's how it is. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Vancouver, Canada is available: Gemma. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The servers accept connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Gemma supports OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

https://airvpn.org/topic/9223-netflix Kind regards

Hello! We're very glad to inform you that four new 1 Gbit/s server located in Vancouver, Canada are available: Cynosura, Homam, Kleeia and Mimosa. The AirVPN client will show automatically the new servers, while if you use the OpenVPN 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, 2018 UDP and TCP. Just like every other Air server, Cynosura, Homam, Kleeia and Mimosa support OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

No, that's very dangerous, do not perform such checks: just do not use Network Lock or remove the third party firewall. You must NOT run two firewalls simultaneously. Even if a preliminary check shows no problems, at any moment unpredictable behavior can arise. Kind regards

@Justin as well That's exactly what we understood since the beginning. And Justin just confirmed that that's what actually happens. So far so good. Now, it would be very interesting to understand how you achieve 40 Mbit/s of AES-256 encryption/decryption with the very same hardware. In addition to the precious suggestion below, could there be some particular process that's loading Justin's router CPU and not yours, perhaps? Kind regards

@karaznie as well Hello, what does this have to do with the issue? Your measurements do not imply that the original poster router has not reached the maximum processing power on the core running OpenVPN. Look at the load of the CPU of the original poster in a dual core processor. Kind regards

Hello, on the other hand this is excessive. Check the OpenVPN sockets buffers sizes in the router (you can see them in OpenVPN logs). If they are smaller than about 260000 bytes, set them to 262144 bytes with directives: sndbuf 262144 rcvbuf 262144 Kind regards

OpenVPN does not scale (no multithreading etc.) on multicore processors. That 50% load may well mean that, in a dual core processor, one core has near-to-0 idle time for example. But that also depends on other tasks of the CPU. It's not ascertained that your routers are having the exactly identical tasks. Anyway, if you can get more than 20 Mbit/s from your router, let us know. You can quickly discern whether the bottleneck is in the router CPU or not by connecting your computer directly to the same VPN server (disable OpenVPN on the router) and comparing performance under similar conditions. Kind regards

Hello, you have reached the limit due to the processing power of your router CPU to encrypt/decrypt an AES-256 flow. Kind regards

Important note: ipleak.net only receives IPv4 packets and only supports IPv4 (not IPv6). MAC addresses are treated by ARP to map a local IP address to a physical node/device, so you will not see MAC addresses anyway in ipleak.net or outside your local network (if you rely on IPv4), they are simply not included in IPv4 packets. WIth IPv4, your machine MAC address is not transmitted outside your local network segment (in which ARP comes into play, for example). Things are quite different in IPv6 (for this argument, just consider that ARPv6 does not exist and that ARP is not usable) that's why it's important to consider that ipleak.net does not support IPv6. Kind regards

Hello! Due to the following vulnerability: https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html and having seen that patches are now available for all of our systems, we inform you that we are upgrading ALL of our servers. The maintenance will have an impact on connected clients which will be disconnected by the VPN servers. Each upgraded server will remain unavailable for a couple of minutes. Web site can remain unavailable for two minutes during the maintenance. Upgrade is starting at 13.10 CET. EDIT: maintenance completed successfully. Kind regards AirVPN Staff

Hello, from the symptoms it might be a router bug, perhaps related to UDP. Try to upgrade the router firmware. Kind regards

does Eddie by default use HMAC SHA384 ? or it should be added manually ? if yes , then how to do it ? Hello! It does not depend on Eddie, it's on OpenVPN. Eddie comes packaged with an OpenVPN version that supports it and will pick it by default. Otherwise make sure that OpenVPN in your system is up to date. Kind regards

Hello, OpenVPN does not use SHA-1 as packets authentication cipher. It uses HMAC SHA1, so you just don't care about collisions. In the Control Channel you can also have HMAC SHA384. See also https://airvpn.org/specs For a more thorough discussion see https://airvpn.org/topic/14837-control-channel-cipher-satisfactory/page-2?do=findComment&comment=33173 Kind regards

Hello, as you can see it does not look like it's on Antares.Maybe traceroute from those five ISPs could provide some hint but again we could do nothing, Antares and datacenter look perfect from all the major transit providers we use in 17 countries. Kind regards

Hello, from inside Antares there are no packet loss to Google, so the problem is somewhere between Antares and your ISP(s). Compare also with the Ping Matrix and Antares history: https://airvpn.org/pingmatrix https://airvpn.org/servers/Antares which show sporadic and minimal packet loss in Antares. Totally irrelevant. Kind regards