Staff

Hello! Yes, p2p is allowed, as well as any other protocol. Currently p2p is a set of the most efficient protocols to share and access information on the Internet. We do not discriminate against any protocol. In general, we kindly ask you to read the FAQ and their answers before writing in the forum or opening a ticket. Thank you in advance. Please see here: https://airvpn.org/topic/9170-do-you-allow-p2p-how-can-i-optimize-performance-of-emule-and-bittorrent-with-airvpn/ 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, please upgrade to version 2.13.6 (latest stable release at the moment). Your version (2.10.3) is three or so years old and is not fully compatible with macOS Sierra, Windows 8 and Windows 10. Additionally, DNS handling under Windows has been improved dramatically. Kind regards

That's totally correct (except for the fact that the remote servers are four in different countries). Eddie developers are aware of it and the next version of Eddie will address this weakness. The problem is not in updating the information (Eddie can very well use the old ones on the HDD when it can't download new ones) but to log the account in the service the first time, download servers information the first time and so on. EDIT: remember that you can configure Eddie to connect over Tor or some SOCKS or HTTP proxy. This could be useful to download info the first time you run Eddie in those networks where the "bootstrap" Eddie servers are blocked but Tor or some third-party proxy is not. Kind regards

Hello, it looks like your system is querying a poisoned DNS (specifically, a DNS that's been poisoned by order of the AU Federal Court). Please run Eddie (the Air client software) to make sure that your system queries VPN DNS, or anyway open a ticket to receive proper support. Kind regards

Please upgrade to Eddie 2.13.6 (latest stable release). What you describe is a bug affecting Eddie 2.12.4, we're sorry. Kind regards

Hello, what happens if you disable DNS check? Select "AirVPN" > "Preferences" > "DNS", untick "Check Air VPN DNS" and click "Save". Enable Network Lock as well. That's expected, the VPN DNS is not reachable from the Internet, as you might have seen the address is in a private subnet. Kind regards

Please upgrade to Eddie 2.13.6 (latest stable release), reboot both the router and the system and test again. Kind regards

Good or bad this is how things work. If you bind a program to an interface different than the tun/tap interface you can't expect in general that the traffic of this program is tunneled or blocked, unless the previous default gateway is completely removed obviously. This is not an optimal solution for a couple of good reasons and Network Lock should be preferred. That's the basic of how WebRTC works, and that's why with Network Lock you don't only prevent WebRTC leak, but any leak caused by any "wrong" or "unintended" binding. For more clarifications please see https://www.clodo.it/blog/an-alternative-approach-to-so-called-webrtc-leaks/ Therefore, once again and hopefully for the last time: if you experienced a "WebRTC" leak either Network Lock was not on, or the firewall rules were modified after Network Lock had been enabled. When/if you manage to reproduce the issue make sure to print and store all the firewall rules. That's the first step to start troubleshooting. All the other speculations at this time are just time wasting chattering. Kind regards

This is contradictory. If you had a "WebRTC leak" then either Network Lock was NOT on, or the firewall rules had been modified after Network Lock was turned on. When/if you manage to reproduce the issue make sure to print and store all the firewall rules. That's the first step to start troubleshooting. Kind regards

The server is physically in Romania and geo-restricted to Romania services are accessible so it's some database error you can safely ignore in any case. Kind regards

Hello, "Connection refused" (error 111) in several cases means that the packets have been properly delivered to the final destination and actively rejected/dropped. Please check the firewall rules in the machine connecting to the VPN. Furthermore, if the device connecting to the VPN is not the same device running the torrent client, then you need forward packets from the tun interface of the connected device to the proper port of the IP address of the device running the torrent client. For example: https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables/ Kind regards

Hello, please try https://airvpn.org Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Romania is available: Canes. 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 server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other Air server, Canes 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. Please note that Canes replaces Phoenicis. Phoenicis has been taken down by the provider without any prior warning. We were informed with a posthumous message which provided an unsatisfactory explanation and the steps to re-activate the server. Needless to say that we're done with anybody keeping this behavior. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

We have found a comparison chart that takes into consideration some very important technical and non-technical aspects which are missing in the quoted list. https://www.comparitech.com/blog/vpn-privacy/best-vpns-privacy-and-anonymity/ There are some minor mistakes but overall it looks just fine. The aforementioned comparison chart should compensate the embarrassingly insufficient technical knowledge and the blatant lies of the person compiling the quoted list: https://airvpn.org/topic/19586-a-review-on-another-site/?do=findComment&comment=48971 Kind regards

Hello, upgrade to Eddie 2.13.6 (latest stable version). Eddie 2.10.3 is years old and is not fully compatible with macOS Sierra and High Sierra. It was programmed when Sierra did not even exist in beta version. Kind regards

It's the same. Unfortunately the user quit Eddie, so the behavior is not only expected, but also explicitly planned to avoid big issues with "netlocked" devices of noobs. The user can blame only himself/herself for the unfortunate, reported circumstances: he/she broke the law (for his/her own admission) AND he/she didn't care to get informed about how Network Lock works, AND he/she let his/her subscription expire beyond the grace period. Kind regards

Network Lock is a set of iptables rules. When you shut down Eddie, Eddie restores the previous iptables rules. This is clearly specified in the guide and in the FAQ and it's very important that you're aware of that. Note: if Eddie crashes the iptables rules will not be changed and your system will remain under Network Lock. Apparently the only one to blame here is yourself. Kind regards

Hello, we don't monitor and/or inspect (with or without logging) the traffic of any OpenVPN client. The information that you report shows that PureVPN did. If you can't afford to trust our words please apply partition of trust. The fact that we don't block OpenVPN connections over Tor node or any socks or http proxy should say something about our honesty. Furthermore, the fact the you don't have any official statement after seven years of AirVPN activity and hundreds of thousands rotating customers about any compromised customers identity (and you have such information about HideMyAss, PureVPN and other services) should be also taken into serious consideration. Kind regards

Hello, except for this which sounds obscure to say the least: Dynamic: The algorithm learns and reacts if routing changes this is a procedure we implemented for geo-routing years ago. We strictly apply this feature only to services which would be otherwise unreachable, because this procedure adds a forced hop, so it's a good way to slow the clients performance down. Apparently that's a terrible feature: probably their users will like to keep it always off. Kind regards

Hello! What Eddie version are you running? Can you also test Eddie 2.13.6, if you haven't already done so, and report at your convenience? Kind regards

Hello! You need to activate "Network Lock". In this way you don't need to disable IPv6 manually. Network Lock will prevent "IPv6 leaks" through ip6tables rules (as well as any other possible leak through iptables). IPv6 support in our infrastructure is planned within the end of 2017. Kind regards

It's not a rule, it's a Law of Technology By connecting to the same server with the same protocol and to the same port your internal IP address is the same. There can't be two devices with the same IP address on any network. Hello! It's a quite different technical limitation in our setup, not a big deal anyway. By the way: if you don't need remote port forwarding you can connect multiple devices, from the very same account, to the same server, but on different ports. In this way you will connect to different OpenVPN daemons working on different VP subnets bypassing the limitation. There is also another finesse which will bypass this limitation and will allow multiple connections to the same server and the same port and subnet with the same account on multiple devices, but it will not be implemented in 2017 (plans for this feature, which will require an important change, have not yet a definite deadline). Important: in order to connect to different daemons for sure, consider that different daemons listen to port 53, 80 and 443. If you pick different ports like 28439, you risk to connect to the very same daemon which listens even to other ports. Kind regards

Hello! Currently not, we're sorry. We might have great news in the future, anyway. Nowadays, a good workaround is accessing our real time servers monitor in our web site "Home" > "Status" page, direct link https://airvpn.org/status Kind regards

Hello! That's a very generic sentence. In general that's not necessarily possible. Just think about our service: OpenVPN works in routing mode, not in bridging mode, and ICMP is a protocol at Internet layer, not a transport layer protocol. So VPN configuration and topology should be analyzed first to avoid potentially wrong or even crazy assumptions. Anyway the scenario seems to assume that the adversary already knows your "real" IP address (we mean the IP address assigned to one of your devices by your ISP) so the discussion shifts to correlation attacks (aimed to show that some activity behind the VPN is indeed YOUR activity) which have been treated over-abundantly in our and other forums. For the purpose of this discussion: 1) make sure to keep Network Lock enabled in our software Eddie and 2) maintain a definite identity separation. In this way you can be confident to defeat even complex correlation attacks. If your friend wants to clarify, he/she is welcome. However, more accuracy is strictly necessary. Kind regards