Staff

Hello! Correct, you don't need to worry. Check yourself with ipleak.net for ultimate test. Kind regards

About Hola, it is very important that you read this: http://adios-hola.org/ http://www.dailydot.com/technology/hola-vpn-security Kind regards

We're very glad to say that the "problem has been solved", or maybe, even better, that the problem never existed Enjoy AirVPN! Kind regards

Hello! We would like to have the help of our fantastic community to determine the optimal value of OpenVPN buffers size in various Operating System on different lines. We have already an opinion and we are aware of some issues with all version of OpenVPN in setting the correct buffer size, which usually result in a too small buffer which causes performance hit on high throughput lines, but your help would be invaluable, because it would allow us to collect measurements from a much wider testing systems. All of the above will help us determine the best approach to treat the matter both in the Configuration Generator and in Eddie, and perhaps even in our VPN servers OpenVPN daemons setup. If you wish to take a role in the testings, you can measure performance with various buffer sizes when all other conditions are the same (try to take measurements with the very same speed tests, same machine load, same VPN servers and same configuration - vary only the buffers sizes for each test). In order to test buffer sizes, add the following directives either to your configuration (.ovpn/.conf) OpenVPN file or in the client Custom directive field you can find in "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN directives. After that, make sure to re-start the VPN connection. The syntax is: sndbuf size_in_bytes rcvbuf size_in_bytes We ask you to test first without any sndbuf and rcvbuf directive, and then with the following values for size_in_bytes: 65536 131072 262144 524288 For example: sndbuf 131072 rcvbuf 131072 In your report, please specify your Operating System exact version, the VPN server(s) you tested with and the nominal peak bandwidth of your line. For the purposes of our test, a test in UDP is enough, but if you wish to add a test also in TCP you're of course welcome. Please test only with 1 Gbit/s servers, do not test with 100 Mbit/s servers. Thanks so much in advance to all who will spend their time to perform the tests! Kind regards AirVPN Staff

Hello, the private IP address is not a leak. The second IP address (the one you blacked out) should not be your public IP address, that field is not used by ipleak.net for that. It must be your VPN IP address. Can you tell us the left-most octet of this IP address? Kind regards

Hello, everything seems fine, the detected IP address is the VPN server exit-IP address. No leaks. Kind regards

Hello, access to other devices in the LAN should be available (and not routed in the tunnel) as long as "Allow lan" is ticked and Network Lock enabled after that option has been ticked and saved. We'll investigate the issue. Kind regards

Hello! Keep the large buffers size anyway and try OpenVPN over SSL connection. Assuming that you run our client Eddie, in "AirVPN" -> "Preferences" -> "Protocols" select "SSL Tunnel - Port 443" and re-start a new VPN connection. Test different servers in different countries, including UK. Do you see any performance improvement or not? Kind regards

Hello! As a first attempt please try to enlarge OpenVPN send and receive buffers. In "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN Directives" menu add the following lines in the "Custom" field: sndbuf 524288 rcvbuf 524288 Click "Save", try a new VPN connection (test different servers) and check whether there's any improvement in performance or not. Please feel free to keep us posted at your convenience. Kind regards

Hello! It's not a vulnerability. The whole "WebRTC leak" case has been fabricated, probably in good faith, by people who did not understand what they were seeing. It's just an application that binds to a physical network interface, to say it quickly. For a more detailed analysis please see the link in the first message of this thread. We confirm that we can't reproduce what you say after weeks of tests on a bunch of different Linux systems (thanks to the community for dozens of reports on this!). iptables and ip6tables rules block outgoing packets from physical interface except to VPN servers entry-IP addresses, so theoretically that's totally impossible, but let's investigate, there must be something we're missing or something that's peculiar to your system. Let's see the iptables and ip6tables rules while your system is connected to some VPN server, with Network Lock enabled, listed just after you have managed to get your real IP address via ipleak.net WebRTC test. Please open a terminal as root, issue the following commands and copy and paste everything in your message: iptables-save ip6tables-save Attach also a screenshot of ipleak.net (taking care to delete your real IP address!). Yes, we can't reproduce the issue you report and it could be important. Please help us by providing the above requested data, thanks! Kind regards

Hello, another way to obtain BTC easily is to sell something (goods, services...) and accept Bitcoin as payment. To maintain an anonymity layer it is necessary that you always, without any exception, run your Bitcoin client behind Tor (or at least when you use the wallets whose transactions you want to keep "anonymous"). Bitcoin adds good privacy to transactions but it's not anonymous by itself (the blockchain will remain "forever" and can be used to correlate transactions to IP addresses and between persons). We also accept very many different cryptocurrencies, if that can help you. Kind regards

Hello! Please go to "AirVPN" -> "Preferences" -> "Advanced" -> "Network Lock", tick "Allow lan/private", click "Save". Disable and re-enable Network Lock (you need to be not connected to a server to do that) to apply the change. Kind regards

Hello! You're probably near to the maximum Raspberry Pi CPU processing power to encrypt/decrypt AES-256-CBC flow (the cipher we use for the Data Channel). Kind regards

But isn't that what network lock is supposed to do? Hello! Exactly, Network Lock must prevent so called "WebRTC leak". If it occurs anyway maybe you have modified iptables rules after you enabled Network Lock. Which Eddie version are you running? Note that 2.8.8 and older versions did not set properly ip6tables. Kind regards

Hello! Open your hosts file (with a text editor launched with administrator privileges). You should find the following line: 85.17.207.151 airvpn.org that you maybe inserted in the past for some reason. Delete it, make sure that no other entries pertaining to airvpn.org are there, save the hosts file and try again. airvpn.org should resolve into 95.211.138.143 How to edit the hosts file in Windows 7: http://helpdeskgeek.com/windows-7/windows-7-hosts-file Kind regards

EDIT: OBSOLETE THREAD. WINDOWS 10 GOT OUT OF THE BETA STAGE A LONG AGO. EDDIE VERSION 2.9.2 IS ALSO OBSOLETE. Hello! The tun/tap interface does not come up. Currently, as far as we know, tun/tap driver does not work in Windows 10 preview and any OpenVPN usage is not possible. We don't know if things have changed in the last couple of weeks (last time we updated on that). In general, to remain on the safe side, you should expect that nothing works on a preview version of an OS. Kind regards

Hello! This is just a clarification that could be useful for some casual Linux user reading this thread: Linux does not suffer any WebRTC leak so no intervention at all is necessary. Kind regards Sorry but I cannot confirm that. I did the test using Firefox 38. something running in a VM (Vmware Workstation 11) on top of Windows 8.1 (64 bit). The Linux distribution I use is Linux Mint KDE 17.1. It showed my real IP using WebRTC, media.peerconnection.enabled = false fixed it though. The network interface of the VM is set to bridged so the WM gets it's (internal) IP directly from the DHCP server (Fritzbox 7390 router). I did the test more than once and it always showed me my real IP. I don't know if it is kernel and or distribution dependant but at least with my setup Linux is also concerned. Thanks! Please see also the following article. It contains information unavailable to us when we first wrote the article. The whole WebRTC approach appears to have been profoundly wrong by many people in the world community. http://www.clodo.it/blog/an-alternative-approach-to-so-called-webrtc-leaks Kind regards

Hello! Health status, reason, and entry IP added. Look at the bottom of the answer to the faq: https://airvpn.org/faq/api/ Any feedback improvement is greatly appreciated. @mblue: We understand you fetch our API with a custom script and generate OVPN config files. Maybe it can be interesting for our community if you explain your needs or reasons. Maybe we can improve our API or our config generator. Thanks. Kind regards

Hello, it seems that only airvpn.org is blocked in your system, but only through DNS hi-jacking, because you can ping the IP address. Can you please post the FULL output of commands: ping -c 4 airvpn.org nslookup airvpn.org Kind regards

Hello! The problem is here: . 2015.06.01 14:10:26 - OpenVPN > [uNDEF] Inactivity timeout (--ping-exit), exiting Please make sure that your router firewall does not block UDP packets (system firewall should be fine because you have Network Lock activated). In case it's your ISP to block UDP (rare but not impossible), try a connection in TCP. You can change connection protocol in client menu/tab "AirVPN" -> "Preferences" -> "Protocols". Kind regards

Hello, your local proxy is either not running, refusing connections or not listening to 127.0.0.1:9150. Which proxy is it? Is it Tor? If you did not mean to use a proxy please make sure that the proxy "Type" combo box is set to "None". You can find it in "AirVPN" -> "Preferences" -> "Proxy". Also make sure that in "AirVPN" -> "Preferences" -> "Protocols" you have not selected "Tor". Kind regards

Hello! Can you please tell us whether you get that error even while the client is NOT connected to a VPN server? As a side note (not related to the problem), we would recommend that you upgrade your client software. Kind regards

Hello! That's correct, in that case the OpenVPN daemon sees the connection from the local stunnel or sshd. Kind regards

Hello, we have finally added the answer to this FAQ: https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses We apologize for the delay. Kind regards

How can I get VPN servers entry-IP addresses? AirVPN servers have at least 4 entry-IP addresses (4 IPv4 and equivalent 4 IPv6 addresses). Different entry-IP addresses provide different tunnel protocols or abilities, please see https://airvpn.org/specs We have Fully Qualified Domain Names that resolve into one of the recommended server entry-IP addresses or ALL entry-IP addresses, in both cases according to geographical location. Such FQDNs are used automatically by our Configuration Generator. The recommended server is updated every 5 minutes, to balance users between servers. Available FQDNs which resolve into the entry-IP address you need are explained below: {name [entry-IP address number]}.vpn.airdns.org - to obtain the best entry-IPv4 address for specified name. {name [entry-IP address number]}.ipv6.vpn.airdns.org - to obtain the best entry-IPv6 address for specified name. {name [entry-IP address number]}.all.vpn.airdns.org - to obtain all IPv4 and IPv6 entry addresses for the specified name which can be an ISO two-letters country code (ISO-3166), a continent ('europe', 'america',' asia', 'oceania', 'africa'), or 'earth' {server name}.airservers.org for entry-IPv4 address 1 of a specific server. Note that resolution by server name is limited, so use the Configuration Generator or contact us if you need specific addresses you can't obtain via DNS. You can see server names in the real time servers monitor in our web site page https://airvpn.org/status [entry-IP number] is the entry-IP address number (2, 3 4), and it is optional. Don't valorize it in order to obtain the first entry-IP address, otherwise suffix the country code with the proper digit (e.g. 'be' for Belgium recommended/best rated server first entry-IP address, 'be3' for Belgium recommended server third entry-IP address). Examples nl.vpn.airdns.org resolves into the recommended server first entry-IPv4 for country NL (the Netherlands) nl.ipv6.vpn.airdns.org resolves into the recommended server entry-IPv6 address for country NL (the Netherlands) ca3.vpn.airdns.org resolves into the recommended server third entry-IPv4 address (tls-crypt connection) for country CA (Canada) europe.all.vpn.airdns.org resolves into all the first entry addresses of all VPN servers in continent Europe. alshat.airservers.org resolves into the first entry address of server whose name is "Alshat". Command line examples Obtain every first entry address (both IPv4 and IPv6) for all servers in Switzerland, asking directly our authoritative DNS server. Windows: nslookup ch.all.vpn.airdns.org dns1.airvpn.org Linux: dig ANY ch.all.vpn.airdns.org @dns1.airvpn.org +short