Jump to content
Not connected, Your IP: 13.59.182.74

Staff

Staff
  • Content Count

    10932
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1843

Everything posted by Staff

  1. Only persons who have contributed to our forums with at least 5 posts are allowed to vote. Anyone can vote with a single or multiple choice. Who votes for what is NOT a public information. We can change this if the community prefers so.
  2. 05/06/2014, Funded with 1000€ (1355 USD). https://airvpn.org/mission/
  3. Hello! We're glad to inform you that a donation of 1000 EUR has just been delivered to OpenBSD Foundation. Kind regards AirVPN Staff
  4. Hello! Thanks, but that's undeserved, we did not do anything. The system was working just like it is working now. Under our point of view and according to our status/health monitoring systems, there's absolutely no difference. Kind regards
  5. Hello @ghostp, please open a ticket at your convenience and send us the Eddie logs taken after the problem occurs (click "Logs" tab, click "Copy to clipboard" and paste into your ticket). Kind regards
  6. If you run the older client 1.92, does this problem disappear or is it the same? Kind regards
  7. Hello! The ETA is 20 Jun. It will run under Mavericks only (upgrade from previous versions of OS X is free). Kind regards
  8. Hello! The winner is: OpenBSD Foundation - LibreSSL We will provide details of the donation in the next days. Thank you for your votes and for your commitment! Kind regards
  9. Hello! The problem in those configuration files is that the OpenVPN "fingerprint" is always visible in the headers, so the connection can be disrupted. We solved the problem by encrypting the OpenVPN header, tunneling OpenVPN in SSL or SSH (OpenVPN over SSL/SSH, a tunnel inside a tunnel). This solution works in China and Iran, the two countries in which OpenVPN connections are actively disrupted, but as far as we know (we will investigate further anyway) it can't be implemented on Android or iOS because openvpn-connect client does not support connections of OpenVPN over SSH or SSL. Kind regards
  10. Hello! No flames please. Especially no flames for nothing. Under a technical point of view, having 4096 bit RSA keys instead of 2048 RSA bit keys does not worsen or improve performance of the Data Channel. The Data Channel cipher was and remains AES-256-CBC. 4096 bit sized RSA keys, in comparison to 2048 bit ones, slow down the first handshake of about 1-5 seconds (according to the CPU power), which is totally negligible. The additional security provided by RSA-4096 is well worth this barely noticeable difference. Even the TLS re-keying, which occurs every hour, will take some seconds more, but you can't notice that, because OpenVPN TLS re-keying occurs with overlapping windows (until the new key pair is negotiated, the previous one is used). After the TLS Auth (2048 bit) and the initial negotiation with RSA 4096, your system never uses RSA to encrypt or decrypt or authenticate packets: the ciphers to be taken into consideration for performance are those of the Data Channel (in our case AES-256-CBC, unchanged) and those of the Control Channel (in our case HMAC, again unchanged, and probably negligible if compared to AES-256-CBC and the volume of data of the Data Channel). The fact that the CPU is 5 degrees hotter should not depend on RSA keys size. Although the temperature difference does not seem worrying, if an investigation is led it should consider different causes. Kind regards
  11. Hello! Any packet with destination our server exit-IP:port is forwarded to your system VPN IP:port. In IPv4 MAC addresses are NOT included in packets, your computer network card MAC address never gets out of your local network. Kind regards
  12. Hi, this is some other problem, it's not related to DNS: from your logs the resolution is correct. At the moment we can only confirm you that there are no problems at all to connect to port 443, in UDP, to the NL servers (including Grafias, whose entry-IP is showed in your logs). Might it be a block by your ISP or by some system firewall to port 443 UDP? Kind regards It isn't a firewall issue as the problem is replicated across two devices running Linux and Mac OS X Mavericks respectively. I can connect sometimes and not at other times (it just disconnects then refuses to reconnect for a while). Also two other users are suggesting the exact same issue today, so it's not just me. I find it highly unlikely Virgin Media would be blocking access to some AirVPN servers, only some times. Plus I have now experienced a disconnection and failure to reconnect over port 80 also. Strange. EDIT: I have now managed to reconnect to NL over port 443 UDP. It would seem that an ISP block is very unlikely. Remember I didn't start this thread, I only replied to it. Currently the top two threads listed in the applet at the side of the forum are both about this issue, from two other different users. Hello! There are around 800 clients currently connected to port 443 UDP of some NL server, globally. We have performed connections to 443 UDP from different ISPs (from Italy) to all the NL servers. No problem on our side has been detected. Maybe it's just a routing problem or some other problem between Virgin and Leaseweb (and optionally from the Solex1's ISP). Hopefully momentary. It must be said that this problem may overlap with the DNS issue. They might be two different problems that sometimes overlap, giving the feeling of erratic behavior. Kind regards
  13. Hi, this is some other problem, it's not related to DNS: from your logs the resolution is correct. At the moment we can only confirm you that there are no problems at all to connect to port 443, in UDP, to the NL servers (including Grafias, whose entry-IP is showed in your logs). Might it be a block by your ISP or by some system firewall to port 443 UDP? Kind regards
  14. Hello! The problem with Google DNS has suddenly disappeared now, without any intervention from our side. We'll keep an eye on it. Kind regards
  15. Staff

    OpenSSL

    Sadly true... Anyway, OpenSSL should be getting soon enough money from the CII (currently made of Google, Microsoft, IBM, Facebook, Amazon, The Linux Foundation, Bloomberg, HP, Huawei and Salesforce). Funds to hire permanently two additional developers have been already delivered and many more should be arriving soon.According to some online articles CII should be funding soon OpenSSH (by OpenBSD Foundation) and NTP. See for example http://threatpost.com/openssl-receives-funding-for-developers-will-undergo-security-audit/106349 Kind regards
  16. Hello! Eddie for OS X is not available at the moment. We're running internally an alpha version which is not ready to be released. Eddie for Linux is available here: https://airvpn.org/linux_ex (if you run different distros, other than your current Ubuntu, make sure to read the platforms/environments notes here: https://airvpn.org/forum/35-client-software-platforms-environments ). About your case with OS X: Tunnelblick takes care about the VPN server DNS push, EXCEPT when "ServerAddresses" is set manually (as it was in your case, according to the logs). Kind regards
  17. Hello! Do you have resolvconf installed? If so, there are several ways to force Ubuntu to use one and only one (or two, three...) nameserver, regardless of DHCP and anything else, and without having to uninstall resolvconf, have a look here: http://askubuntu.com/a/310407 Ignore other messages in the thread marked with bad ratings (0, -1, -2), they offer incorrect solutions. Kind regards
  18. Hello! Can you open a command line in your system, issue the following commands and send us the output? traceroute airvpn.org (in Windows: "tracert airvpn.org") ping airvpn.org Kind regards
  19. Hello! In OS X 10.9.x, each network card has it own DNS. This is a DNS implementation that causes exactly the bad problems Windows is affected and that you're experiencing. In Eddie 2.2 for OS X a "forced VPN DNS" option is planned. In the meantime, in order to prevent DNS leaks you should make sure that no network card DNS is set to query the router. The VPN DNS server IP address, reachable regardless of the port you connect to, is 10.4.0.1. Kind regards
  20. Hello! The instructions are the same, just like for 2.0beta, at the usual announced link https://airvpn.org/software (only direct link, not available in web site menus at the moment). Kind regards
  21. Hello! DNS leaks are impossible on Linux. Your system is explicitly configured to send DNS queries to your ISP DNS servers, and that's not a DNS leak: Linux just does what it is ordered to do. In order to use VPN DNS with OpenVPN (resolvconf required): https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf Alternatively, run Eddie 2.1beta (resolvconf required again): https://airvpn.org/linux_ex As another option, in case you don't want resolvconf, just set yourself the appropriate nameservers in /etc/resolv.conf Kind regards
  22. Those services are supported by our system as means to perform payments. If you do not have Bitcoins and you want to exchange them with a government currency, that's a totally different subject that has nothing to do with this argument, and we don't see how you can purchase Bitcoins via a bank transfer without using your bank account coordinates. Additionally, as we already wrote, all the older methods to pay with Bitcoin are still available as usual. Kind regards
  23. Hello, the "dilemma" will be no more when Eddie will have total leaks prevention as built-in function which can be activated with a click. This is planned and will probably be added in the next release, during the 1st week of June. About your other considerations, it's sufficient to say that we don't force any usage of proprietary software and that Eddie is open source, which is very important for peer-reviews. Kind regards
  24. Hello! Yes, we have problems with them both. About Zaurak, we lost every contact with the datacenter in Kiev about 48 hours ago. We can't do much more than waiting for them to re-appear... About Sador, we are looking for another datacenter in Spain. The current datacenter does not meet anymore our requirements. Kind regards
  25. Hello! If we understand them correctly it's ok that Eddie can't work, because you block all traffic except traffic to some VPN servers. In these cases Eddie could work only if it had already stored information on how to reach those VPN servers and had already stored keys and certificates. Kind regards
×
×
  • Create New...