Jump to content
Not connected, Your IP: 3.138.172.130

Staff

Staff
  • Content Count

    10933
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1843

Everything posted by Staff

  1. 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
  2. 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
  3. 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
  4. Hello, everything seems fine, the detected IP address is the VPN server exit-IP address. No leaks. Kind regards
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. Hello! That's correct, in that case the OpenVPN daemon sees the connection from the local stunnel or sshd. Kind regards
  22. 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
  23. 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
  24. Hello! Yes, you posted it in "General & Suggestions" and we moved it here to "Reviews", a more appropriate location since it compares AirVPN with PIA. It is more likely that it gets higher visibility here, not there, and you can see that actually the debate has become hot. We like and we reserve the right to move any thread in any forum section to make the forum more readable. At same time, we are pleased to see that this forum has become an attractive place for several PIA customers. Interestingly, this thread is showing some important information that PIA customers might like to consider carefully. We show it because we have it. It's a matter of transparency. It is not logged: it is showed in real time and stays in RAM until the client disconnects. Note that contrarily to some of our competitors, we don't keep keys, user data etc. on the VPN servers. All the data are kept in backend servers which never communicates directly with clients, frontends or VPN servers. However, it is obvious that the VPN server knows the IP address a client connection is coming from: how would it communicate with the client otherwise? This is how the Internet works. Additionally, you can hide your real IP address to our VPN servers, by connecting OpenVPN over a proxy (even Tor). And our client Eddie implements all of these options. It is the only free and open source VPN software that allows with a click a connection of OpenVPN over Tor even in OS X and Linux, with no requirements for any additional setup (except running Tor, of course), Virtual Machine etc. Not only these features are not implemented in our competitors software, but in most cases our competitors software, including PIA software, is closed source. Hiding to the user data (that any VPN service has) could be a trick to attract less technically skilled persons, or even gullible people. It can be a marketing strategy. We don't like it and it is not compliant with our mission. https://airvpn.org/mission If you share the connection with people you blindly trust, your concern is deeply illogical. But from your words it seems that you share your account with people you don't completely trust. In this case, with AirVPN you can share your account with other people and keep control of your account: you just need to provide keys and certificates to the other persons, and keep your password for yourself. Inviolability of your Data Channel encryption is guaranteed by Diffie-Hellman exchange. In this way other people can connect to VPN servers but can't access your user control panel, can't change the password to gain total control of your panel etc. If they occupy all of your slots, you can even force a disconnection to free the slots. They can't forward ports, only you can, so that you can keep under control the most dangerous situations (example: an illegal web site "hosted" behind a VPN server). This is not possible with PIA and this is important with our service, because we have implemented a dynamic remote port forwarding system (with DDNS if you need it) which is "light-years ahead" than PIA system. Anyway, it is important to underline that the account holder will be held responsible for any action of anyone using that account (assuming that PIA ToS allows this practice). Note: As of 2017 AirVPN now supports 5 connections per account. But this has NOT changed our commitment to minimum allocated bandwidth. About 5 connections instead of 3, this is also a consequence of our commitment to minimum allocated bandwidth, which PIA does not provide. When you provide a "best effort" service without any warranty on bandwidth allocation per client, things change radically. Since AirVPN birth we have never used VPS for our VPN servers. We have dedicated servers with redundant uplink ports and bandwidth (with the exception of Hong Kong, where we were forced to accept a sufficient compromise) and PoP with tier 1-2 transit providers. Compare our servers status page with any competitor servers status page https://airvpn.org/status/ Click on the servers name to access plenty of data about them. Please define properly and technically how "the security of the VPN" can be harmed by this: the point of hiding data that are anyway there, during the whole duration of a client session, is nonsensical. The client just shows you the information that the VPN server has got and which it already communicates with (incidentally, very useful for other purposes); the frontend does the same. On top of that, we remind you once again that our client Eddie is free and open source, that it is totally optional to use it, and that, contrarily to the setup of most our competitors, entry-IP address and exit-IP address of VPN servers are different. Kind regards
  25. Hello! You're right, without the option "All servers for area/region" (which we deleted for good reasons) getting all the entry-IP addresses through the CG has become a time consuming task. We need to insert the following information in the "How-To" forum. We apologize for the delay and for any inconvenience. You can resolve "server_name.airvpn.org" to get a specific server entry-IP address. Server names can be found in the "Status" page of our web site, or in the Configuration Generator. For example, from a command line interface: nslookup nihal.airvpn.orgto get entry-IP address of Nihal server. Please resolve country_code.airvpn.org to get all the entry-IP addresses of that country VPN servers. Example: dig @8.8.8.8 nl.airvpn.org +short(NL is the country code for the Netherlands) or nslookup nl.airvpn.orgYou can resolve "continent_name.airvpn.org" as well, to get the full list of entry-IP addresses of VPN servers in a continent. Finally, resolve "earth.airvpn.org" to get ALL the entry-IP addresses of all the VPN servers. Note: dig is not available by default on Windows, you need to install it. Alternatively, you can use nslookup, but the output of dig with the option "+short" could be easier to parse in some cases. Kind regards
×
×
  • Create New...