Staff

Hello! Please see also here: https://airvpn.org/faq/udp_vs_tcp/ Kind regards

Hello! Can you please publish the original Kaspersky reply (or send it to us privately in a ticket) where they declare what you reported here? It might help us. Kind regards

Hello! Can you post (or send it to us privately in a ticket) the original reply from Kaspersky stating that the bug will be fixed within 2019? It might help us. Kind regards

Hello! Using the Tor Browser sounds like an excellent solution for your purposes, because you just need to separate identity with certain web sites. On VM performance, you might test a very light Operating System with some guest integration by the virtualization software, before considering the purchase of new hardware. About light systems, check out DragonFly BSD (a FreeBSD fork) or something like "Damn Small Linux". https://www.dragonflybsd.org http://www.damnsmalllinux.org Avoid Windows at all costs. Kind regards

Hello! On your Android or iOS device you need to re-generate a configuration file and import it as a profile in your application (openvpn-connect, OpenVPN for Android...). Try the following settings: - click "Advanced Mode" in the Configuration Generator - select protocol TCP, port 443, entry-IP address 3 - proceed as usual to download / import the profile On entry-IP addresses 3 and 4 of our VPN servers you have OpenVPN working with "tls-crypt". It means that the whole Control Channel of OpenVPN is encrypted. This connection mode has showed great abilities to bypass a wide variety of blocks. In this case we also suggest TCP because, according to the reports we have been receiving from China in the last years, it is not uncommon that UDP gets entirely blocked on mobile lines. UPDATE: with our software Eddie Android edition, you will not need the Configuration Generator anymore in Android. Eddie will try by itself anti-blocking connection modes. If you don't wish to wait (Eddie may need up to 1 minute to find the proper way to circumvent China blocks). go to the "Settings" view and please set: Custom protocol option to TCPCustom port to 443Custom TLS mode to tls-cryptQuick connection mode to Use custom settingsEddie will connect to port 443, with protocol TCP, using tls-crypt. Kind regards

Hello! Please make sure that the router firmware is up to date. The condition you report might be caused by a router bug which is triggered by sustained UDP throughput. In spite of the fact that only some torrent software causes the issue (which does not fit in the explanation), it's worth anyway a try. Kind regards

Hello! "Probably" is not "surely" (but we wrote "apparently"). Anyway, it doesn't matter: you have no leaks, and this is the important point. Note how you can have IPv6 connectivity over our service even if your ISP does not support IPv6. Kind regards

Hello! No, you don't. The IP addresses of any new server are added automatically in the rating system, so the qualified name of each country may resolve (if the server reaches the best rating) into those IP addresses. The configuration file, when the needed settings are the same, remains the same. Kind regards

Hello! Thank you. Yes, it's planned for all the servers. Kind regards

Hello! We're very glad to inform you that five new 1 Gbit/s servers located in Atlanta (Georgia, USA) are available: Hercules, Libra, Musca, Sculptor and Ursa. 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, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, they support OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. 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. Please note that these new servers will replace five servers in Atlanta, and precisely Antlia, Octans, Pavo, Sagittarius and Scorpius which will be withdrawn soon because the company operating in the datacenter they are located is ceasing operations, unfortunately. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! 2. In this case you could rely on VMs. For example, you have a host connecting over OpenVPN over Tor, and a VM (attached to the host via NAT) which connects to another VPN server. The traffic to/from the VM would be tunneled according to your description, if we understand it correctly. 3. Exactly, this is an important factor to consider. A different setup, again with the aid of a VM, would be more secure under this respect. For example, connecting the host to a VPN server with Network Lock enabled, and then using OpenVPN over Tor in a VM attached to the host via NAT. In this way, if the connection established by the VM fails, you can still rely on the host connection "locked". Yes, once you know the Tor guard entry-IP address you can enter the rule allowing traffic only to that IP address, but complications arise when the circuit changes.A safer solution appears as the one described in point 3 (with a VM). This is also a matter for developers to see whether something similar can be implemented in a safe way in Eddie, we will make them aware of this thread. Kind regards

Hello! About the changes from 2.15.2, please check the changelog here: https://eddie.website/changelog/?software=client&format=html And yes, you're right, now it works properly for a new feature. There are some cases for which IPv6 seems available but in reality it does not work properly. Now Eddie tries to understand these issues, which have a definite pattern. If it detects them, it switches IPv6 tunneling to "Block". 1. Yes. 2. No: you have a local Tor proxy, you can connect to it different OpenVPN instances (provided that you take care to define multiple routing tables, a feature that's unsupported on Windows systems), but then you have to decide which route a packet must follow. A simpler solution would be adding another VPN service not between Tor and AirVPN, but before them or after them. 3. Unfortunately not. It is not possible to ensure a proper Network Lock because Eddie can not know in advance the Tor guard IP address. So you might lock the traffic only after the circuit is established, a thing that Eddie currently does not do, and anyway might be deceptive. Kind regards

Hello! Thank you, send them to us too, and enable logging on file (then send us the generated log, taken after the crash). Kind regards

@hugomueller Please see here: https://airvpn.org/topic/28153-ipv6-support-and-new-smart-features/page-3?do=findComment&comment=75733 The same thread can be taken as a reference. Simply, tls-crypt is supported and mandatory on entry-IP addresses 3 and 4. OpenVPN 2.4 or higher is required. https://airvpn.org/topic/28153-ipv6-support-and-new-smart-features tls-crypt encrypts the whole Control Channel and has been reported as effective in bypassing blocks in China and Iran at the moment (to port 443 preferably, otherwise you could experience a generic, not OpenVPN related, outbound port blocking). Kind regards

You were lucky you did not need anti-blocking techniques earlier. They have been enforced since many years ago in wide areas of China. Do not hesitate to open a ticket if you have still troubles after you have applied the recommendations in this thread. Kind regards

Hello! Can you please upgrade to Eddie 2.16.1 and test again? To download this version, in the usual download page for your system please click "Other versions", then select "Experimental". You will be brought back to the download page, where you can proceed to download and install as usual. Please feel free to let us know whether this new version fixes the problems you experience. Kind regards

Hello! Which is not much: routing table and pf rules. When this happens just re-run Eddie and it will detect the previous crash and put everything back in order. This is of course not an excuse for the crashes, but we don't have reports about such crashes, so please post the complete crash dump when possible (and if available) or enable logging on file (in "Preferences" > "Logging") and send it to us after the crash. It could provide the developers with some useful clue. Eddie does not create or configure tun adapters. Normally you don't need to worry about them, since they are handled by Mac kernel, while OpenVPN (and not Eddie) configures them. Older Mac systems had various bugs about tun but after the implementation of utun the system issues have been progressively solved by Apple. Kind regards

Hello and thank you very much for having tested Eddie and for your suggestions! This feature was planned and now it works properly. Forget the old "com" application, try the new Eddie 1.0 RC1 RC2. Please see here: https://airvpn.org/topic/26549-eddie-android-edition You can define black and white lists of applications whose traffic must be included in or excluded from the VPN tunnel in "Settings" > "Application filters". This is caused by the elephantine dimensions of Mono. Eddie Android upper layer is written in C# so a hundred or more additional megabytes are required for Mono libraries etc. We might change this in the future (it was not an easy choice) and renounce to Mono pachyderm in some future, but not before we reach 1.0 stable version. We are aware that a difference in footprint of 120 MB is a problem in some mobile devices. Very true. However, while Eddie progresses toward integration with AirVPN and therefore making the usage of ovpn profiles not required, this point will be overcome and Eddie will be more comfortable than OpenVPN for Android (at least with AirVPN). Thanks, keep testing and don't miss the future RC2 which should be released soon! Kind regards

Hello! In OS X or macOS (and in any other Operating System) Eddie does not create or remove tun/tap adapters. The utun cards are handled by the operating system with its own kernel modules, while OpenVPN just brings a utun up or down and configures it with the proper settings. Can you please clarify? Also, the amount of utun cards has nothing to do with other cards, so we don't see how that could be linked to the other problem you mention, about which we would recommend that you check your system DNS and firewall settings. Kind regards

Hello! Nothing new, same situation since 2012 at least. From China you need "OpenVPN over SSL" to port 443 (you can configure it with a few clicks in Eddie) or connect over tls-crypt to entry-IP addresses 3 and 4 in TCP (preferably to port 443 to avoid some outbound port block which could be sometimes enforced), when you find a line that's blocking OpenVPN and UDP. Connecting with "tls-crypt" saves you the pain to configure "OpenVPN over SSL" in Android. Currently about 80 Air VPN servers support tls-crypt The fact that you could connect successfully in UDP is a lucky event according to the reports we have. In most cases that's not possible at all from residential, fixed lines, and from mobile lines. Restrictions anyway seem less stringent in tourist and business towns. This looks like a bug, it's under investigation, thanks. Thank you for the report. Kind regards

Hello! You're wrong in this case. The screenshots show NO WebRTC leaks. Note how the addresses showed in the "WebRTC" section of ipleak.net web site are your private, non "publicly routable" addresses, as clearly specified by the web site itself. A note for the readers: WebRTC functions (and any similar function) can be prevented by Eddie only through firewall rules so make sure to enable Network Lock in Eddie. Some more thoughts about WebRTC can be found here: https://www.clodo.it/blog/an-alternative-approach-to-so-called-webrtc-leaks Since you have, apparently, pure IPv6 connectivity, please keep testing Eddie beta version and make sure that no IPv6 public address of yours appears in ipleak.net when Network Lock is enabled. To avoid confusion in this case to the casual readers we have renamed the thread with [FUD] prefix. Kind regards

Hello! Yes, with "OpenVPN over Tor" that's expected, for the reasons mentioned in our previous post in this thread (to put it in simpler terms, "that's how routing works"), when you generate traffic from an application (different than OpenVPN) configured to connect to Tor, while traffic of all applications NOT configured to connect to Tor will be tunneled over OpenVPN over Tor. For an additional test to check whether your configuration is working properly, connect OpenVPN over Tor with Eddie, run a browser NOT configured to connect to Tor and browse ipleak.net . Verify whether the IP address is the exit-IP address of the AirVPN server your device is connected to. Kind regards

Hello! Thank you for your choice and for the trust you put in us. That warning is correct and can be extended to any node your traffic passes through. Each node has the potential to see your traffic content. In your case, you move your trust from your ISP and anybody wiretapping your ISP lines, to us and anybody wiretapping the datacenter lines. You get protection from your ISP and other entities willing to spy on you between your node, your ISP and any other node between you and our servers. Even if you trust us blindly, you can't be sure that someone else is monitoring our servers. So, in every situation for which you just can't afford to trust us or the datacenter, you MUST use end-to-end encryption. In this way our servers and any hostile entity monitoring the servers line can't see your traffic content. The huge difference is that the protection against your ISP is more valuable than anything else, because you get a first, strong protection layer against local entities which have higher likelihood to have you as a target (for marketing reasons or more sinister reasons). And that's not all, because you can add a second protection layer which will protect you against us and any malicious entity INSIDE the datacenter our servers are located: use end-to-end encryption, and add Tor over the OpenVPN connection, according to your threat model. Another important factor is the protection you get against the final destination of your communications: when they get out of the server, your packets do not contain your "real" IP address. There are a variety of common situations for which you want to hide your real IP address to the final destination of your communications. A more extensive analysis of this issue can be found in the post linked below. Please take some minutes to read it, it's important. In this way you can make the best decision according to the evaluation of the power of your adversary, in other words according to a reasonable threat model that only you can estimate. When you need to exchange extremely sensitive data, for example, simply using the VPN over Tor and using end-to-end encryption will make a huge difference by strengthening remarkably the anonymity layer. https://airvpn.org/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 Last but not least, remember that our service protects your data in transit, and NOT your computer, so the essential pre-requisite of everything is that your device is not compromised (by spyware or anything malicious). Some more food for mind can be found here: https://airvpn.org/topic/26206-rebuttal-of-article-dont-use-vpn-services/ Finally, an important remark about iOS. Many Apple services such as Push Notifications and FaceTime are never routed through the VPN tunnel, as per Apple policy. We have come to know this from the openvpn-connect FAQ here: https://docs.openvpn.net/connecting/connecting-to-access-server-with-apple-ios/faq-regarding-openvpn-connect-ios To stay on the safe side, when security and privacy are a priority, you should consider an iOS device a nice toy which is not suitable for certain purposes (check again your threat model). Kind regards

Been a week now. Is someone going to tell us if it was intentional or by accident? Hello! It was intentional, according to the consideration that it is more appropriate and fair to keep the original signature of the packaged binaries not programmed by Air, but as you correctly remarked this failure of communication is our failure and we will improve and learn from this mistake. Kind regards

And just to be sure: The exit-IP address is the one we see when we look at the list of servers and their addresses which are available to us, right? Hello! Nope, that's the entry-IP address, if what you write is understood correctly. For example, let's take server Chamaeleon. It has the fully qualified name chamaeleon.airservers.org which resolves into the entry-IP address of Chamaeleon. $ dig chamaeleon.airservers.org +short 199.249.230.41 See also here for further information about that: https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses Exit-IP address of Chamaeleon is different. Yes, that's the exit-IP address. Kind regards