Jump to content
Not connected, Your IP: 3.138.69.101

Staff

Staff
  • Content Count

    11046
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1867

Everything posted by Staff

  1. Quite the opposite, in this very peculiar situation. There are some efficient ways to add an anonymity layer to BTC transactions, regardless of any intermediary. However, when the intermediary makes some precise choices of verification and so on, the anonymity layer gets thinner (not to mention the annoyance of any unnecessary step) and by the way any additional layer and intermediary does not make you use the full potential of Bitcoin. Kind regards
  2. Hello! We have not ruled out this option, although at the moment we can't promise anything for sure. Kind regards
  3. Hello. it's not an issue, there's nothing to fix. We're sorry, it's beyond our scope to explain what Internet Protocol version 4 and 6 are, and which layer OpenVPN works at, so we'll leave it to any person of good will, or maybe you had better consult Wikipedia and all the resources available on the Internet. Suffice to say: stop worrying. Side note: moving this topic to Off Topic forum. Kind regards
  4. Hello! We're very glad and proud to announce that from now on we are able to accept Bitcoin directly. Any intermediary acting as a payment processor is no more required. We feel that this is an important step, since some payment processors have taken or are taking steps which are not totally privacy friendly. Moreover, cutting out any intermediary is very coherent with Bitcoin spirit and unleashes the potential of the cryptocurrency. Kind regards and datalove AirVPN Staff
  5. Most plausible explanation according to all the gathered information is that your ISP shapes the whole line as soon as it detects an OpenVPN connection. If this were confirmed, your ISP would be really an ISP to carefully avoid. Kind regards
  6. Hello! It depends on the complexity of the question and the problem. A key factor is when some testing to try to reproduce some issue is necessary on our side. Normally 1-12 hours when such reproducibility search is not necessary. More on special days (Christmas, New Year's Day, Easter, mid-August etc.). Kind regards
  7. Network Lock, not block. Nothing else, that's all. Locking. Kind regards
  8. It means that they have not implemented PFS with OpenVPN because IKE has nothing to do with OpenVPN, it's a protocol for the SA in IPsec. Sloppy, wrong OpenVPN implementation if the transiting data integrity and security is a priority. The fact that they kept fueling your confusion with even more confusing answers shows a worrying lack of competence. Maybe you should just stay away from them and move on. Kind regards
  9. Hello, remember to activate Network Lock, this option will prevent any possible leak, including leaks caused by programs binding to the physical network interface (which is not an OpenVPN problem, it's how routing works). It will also block IPv6 when the system is not connected to IPv6-supporting servers. The screenshot shows that you had Network Lock disabled. Also remember (for other cases you might assume as suspicious) that the TCP and UDP traffic in the system connected to the VPN is not encrypted and wrapped when passing through that system tun/tap interface (and this is correct too, of course). Kind regards
  10. Hello! That's caused by how a torrent client works. It announces directly inside the packets the port you configure in it. More details in the answers to the FAQ: https://airvpn.org/topic/9170-do-you-allow-p2p-how-can-i-optimize-performance-of-emule-and-bittorrent-with-airvpn/ Kind regards
  11. Hello! block-outside-dns is a Windows-only directive (rightly so, since Windows is the only system with endemic DNS leaks caused by incomplete DNS implementation) and is fully effective to prevent DNS leaks. Please check the OpenVPN manual here: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage Warning, this directive is unsupported in OpenVPN versions older than 2.3. Windows DNS leaks, anyway, have always been prevented in the Air client software "Eddie". If you run Eddie in Windows, adding this directive is superfluous. Kind regards
  12. Hello! Check the directive: reneg-sec n where n is in seconds in the OpenVPN manual: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage OpenVPN uses the previous key as long as the new key is not fully re-negotiated. Such "smart overlapping time window" ensures no communications break. Just make sure to not set extremely low values, because a re-keying adds anyway a moderate overhead in bytes, in computation power and you probably don't want that your side is willing to ask for a re-keying immediately after the previous one is over. Kind regards
  13. Eddie is free and open source software released under GPLv3. At the moment we release under GPLv3 only the stable versions of Eddie. The various experimental versions (internal alpha, internal beta, public beta) are not released under GPLv3 and you should avoid them if you don't feel adventurous. Just stick to what you find on GitHub and do not take into consideration experimental / beta versions. This is not immutable and can change in the near future. Kind regards
  14. Hello! Please make sure that no QoS / packet filtering tools, both on your router and system, interfere with traffic, and also test (with the connection mode that could provide you with the highest throughput) different servers in various locations around you (prefer servers with lowest round trip time). We don't see any bad packet / packet error in the log entries, so we tend to rule out MTU size problems. Some users reported in the past interesting performance boost (in Windows) after having fine tuned the TCP/IP stack with TCPOptimizer. If all else fails, you could give it a try, please see here: https://airvpn.org/topic/24126-tcp-optimizer-for-windows It looks like that with some TCP/IP stack optimization Windows can partially fill the gap with the other systems in the tun/tap interface "performance". It is not easy in Windows to match the throughput you get in the tun/tap interface when compared to other systems (you don't have fast-io, you don't have any native tun/tap support and some other problems due to bad architecture), but with TCP Optimizer and the latest tun/tap driver throughput can be improved (of course, it is assumed that your system has a powerful enough CPU). 120 Mbit/s is not bad anyway if you make a comparison with just 5-6 years ago, when beating 100 Mbit/s on the tun/tap interface with the old tun/tap driver in Windows was deemed as impossible. Kind regards
  15. Hello, please post Eddie system report ("Logs" > life belt icon > copy all > paste), it will tell us your Operating System exact version and many other settings that might help in tuning. Kind regards
  16. Hello, the log is fine but shows that you don't take care of DNS push, Under GNU/Linux OpenVPN does not handle the DNS push from the server, so an option to consider is that your system queries DNS servers that are inaccessible from the VPN (typically ISP DNS which accept queries only from inside the ISP network). Please check your /etc/resolv.conf file. Also consider that you can run Eddie, the free and open source Air software: it will take care of the DNS push. Without Eddie, some methods to accept the DNS push under GNU/Linux are described here: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf Kind regards
  17. This makes no sense (or worse, it makes a sinister sense ), but maybe you have just talked with someone who did not even know what you were talking about. Please note that this is not the forum to talk about competitors, not even when doing so exposes our competitors flaws. This is the correct forum to continue with comparison etc.: https://airvpn.org/forum/39-other-vpn-competitors-or-features/ Kind regards
  18. Hello! Yes, of course. Since its birth, AirVPN always configured OpenVPN to work in TLS mode with PFS. And there's more: AirVPN uses 4096 bit DH keys and unique DH keys on each VPN server. Kind regards
  19. @VectorXYZ Hello and thank you very much for the information. It would be nice to know why this ISP likes to block IP addresses of VPNs, although we can imagine why. Entry-IP 3 and 4 will be added to most (if not all) servers soon, probably during April. The deployment is ongoing (almost over now) and we think to activate all of them simultaneously with IPv6 support. Kind regards
  20. No, it's not equivalent. In most OpenVPN versions. omitting "comp-lzo no" when comp-lzo is specified (even when excluded) on server side will cause connection failure. This is an OpenVPN questionable implementation but that's the way it is. We confirm anyway that we will keep into account all the problems raised in this thread to maximize retro-compatibility whenever possible. Kind regards
  21. Hello! OpenVPN over SSL works just fine and you don't need anything else. However, we're also interested in trying to bypass some blocks in UDP, where UDP is not blocked globally, or in TCP without the aid of an additional TLS tunnel. For such purpose tls-crypt might help. It is now available in Chara and Castor, and will be deployed onto most or all servers in a month or so. We would be glad to receive feedbacks (not here, only in private tickets) from China or Iran. Please run Eddie 2.14 to support the new feature or re-generate properly the configuration files to test. UPDATE: tls-crypt is now available on all servers, please see next messages in this thread. Kind regards
  22. Hello! Closing Eddie before shutting down the system is any case the best option to make sure that Eddie has enough time to restore the system settings. That said, you can just un-tick "Exit confirmation prompt" in "AirVPN" > "Preferences" > "General" to let Windows shut down even when you don't close Eddie first. Kind regards
  23. Can you please keep in mind that "its" has NOTHING to do with "it's"? Fixing the topic subject.
  24. Hello! It has been fixed, thanks. Sorry about that. Kind regards
×
×
  • Create New...