Staff

Hello @ghostp ! 1) The Automatic mode in Eddie at the moment always picks protocol UDP, port 443 2) You can't get the mentioned logs entries when OpenVPN works in TCP because a first error correction is performed at TCP transport layer. See the already linked messages for more insights about that. Note that when over SSL or SSH, OpenVPN must work in TCP (stunnel and ssh do not and can not support UDP) 3) The fact that you don't experience packet loss without VPN is interesting. Two possible explanations: either you are not detecting correctly packet loss (how did you verify that?) or you are really subjected to replay attacks - in which case OpenVPN is doing its job correctly, in UDP. In the latter case, the fact that you get packet authentication failures with every and each VPN server in several different datacenters would seem to imply that the replay attack is performed in some point inside your ISP network (it's possible: injecting forged packets is not rocket science once someone is in your same network). It would be an attack specifically aimed against you. In this case, when you don't use VPN and you don't use end-to-end encryption and authentication, the attack would succeed, but it could be hard (if not impossible) for you to recognize forged injected packets. Kind regards

Hello, changing NS implies to become authoritative, requires stable DNS with fail-over and load-balancing, manual reconfiguration of all the domain stuff (like DNSSEC) etc. It may be done in the future, but currently DANE is unsupported by major browsers on client-side and unused by an overwhelming majority of persons even when some add-on for their browser is available. Interesting stuff, but it does not justify the work of changing NS records at the moment, we're sorry. Kind regards

Hello! We enabled IPv6 on airvpn.org . We enabled DNSSEC on airvpn.org. Now https://en.internet.nl/domain/airvpn.org/results returns a 100% score. Unfortunately, our registrar GoDaddy does not support TLSA record required by DANE protocol. http://comments.gmane.org/gmane.ietf.dane/907 At the moment, we can't do anything, neither change GoDaddy. We will try to request this feature to GoDaddy. In the future, we will study about the option to add DNSSEC on airdns.org (DDNS domain linked to port-forwarding etc. which is on our authoritative DNS), but it seems a bit complex. TLSA will be added for sure when GoDaddy supports it. Please, push freely. We always read all the topics/posts, but we might forget something if we have other priorities. Pushing doesn't cost nothing. Kind regards

Hello! Apparently you have performed all the necessary steps. On the router, if you're forwarding with iptables you can compare with this guide (for Tomato and DD-WRT, maybe you can find it useful for your router too): https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables Maybe not related but you never know: you must access Plex from a different machine, not from the very same machine that's running it and that's connected to the VPN. Make sure that you access it on the VPN server exit-IP address, correct port (the port you have remotely forwarded in your port panel in our web site). Kind regards

Hello! Try with Eddie 2.9.2 Experimental for OS X Mavericks/Yosemite. In the usual OS X download page https://airvpn.org/macosx click "Other versions" then select "Experimental". In "AirVPN" -> "Preferences" -> "Network Lock" tick "Allow lan/private", click "Save" and test. According to our tests on Yosemite systems everything works fine, feel free to let us have your feedback. Kind regards

Hello! PiWick fully respects users' privacy (and our privacy as well!) and is open source. It is fully compliant to any EU directive on privacy and data protection and it goes even further. About performance, of course you can't normally expect more than what you already get without VPN. Feel free to open a ticket to try to improve performance. Kind regards

Nope, I did not change anything, even my modem/router is the same. What do you think, might it be something I should concern about? @ghostp Hello, at the moment it's difficult to say something. It could be just a momentary line problem, go on checking in the next hours or even days. As a generic suggestion, if your system is connected via WiFi, try to get the strongest signal. If it is connected via Ethernet, try to replace the cable. The following post talks about the log lines you get and replay attacks: https://airvpn.org/topic/3773-pls-help-strange-logs/?do=findComment&comment=3784 Kind regards

Hello, you're still running the old version, please make sure you launch the new one. Kind regards

Hello! If you connect via UDP 443 with other providers with the very same cipher (please check both of these) and you get higher performance then we have no rational explanation, we're sorry. Maybe it's a peering problem, try also other servers in different datacenters, because Heze and Persei are in the same datacenter with the same provider. Kind regards

Hello! We confirm all that written before. You have obtained triple throughput with OpenVPN over SSL than with direct UDP, instead of lower. Your calculations are wrong (because they do not take into account how a VPN works), but that's not important at all: even when the throughput is the same, this is a "smoking gun": traffic shaping. The point is that you got at least once higher throughput with OpenVPN over SSL than with direct UDP connection, and in all other cases approximately the very same throughput. If there was no traffic shaping (of course assuming that every other condition you reported stands), you would have always got a significantly lower throughput with OpenVPN over SSL. Tests to Persei are fine at the moment. Sometimes you can even see some user in the Top 10 Speed table (in the "Status" page) connected to Persei. Now, let's move on to find something more useful for you, we repeat: it would be relevant to compare the ports you connect to the VPN servers with PIA and with Air. The option that it is port shaping deserves to be verified. Also, what is your CPU and which cipher do you select when connected to PIA? Kind regards

@karn Of course, you can pick a specific server, or a country, or a specific set of servers... please read the instructions for Android: https://airvpn.org/android Kind regards AirVPN Support Team

Not true. Did you not see the 3rd speed test I posted? It was done using SSL 443. We also saw this: https://airvpn.org/topic/14078-slow-download-speed-hezepersei-fremontca-servers/?p=26937&do=findComment&comment=26937 where it is reported a performance that's almost triple than that you recorded with direct UDP connections. At the same time you are absolutely sure that there is no congestion in your ISP network, so we have momentarily ruled out this option. That's why we think it's traffic shaping, but of course it could be also bad peering. Let's try to verify the first option first. That fact is meaningless in many cases, for example if it is port shaping. It would be relevant now to compare the ports you connect to the VPN servers with PIA and with Air. The option that it is a port shaping deserves to be verified. Also, what is your CPU, and which cipher do you use with PIA? Kind regards

@ddrnewb As you can see either your ISP or your system perform extreme traffic shaping because with OpenVPN over SSL, instead of getting lower performance, you get almost the triple throughput. This means that the remarkable overhead introduced by double tunneling added to the extremely significant loss of performance when OpenVPN is forced to work in TCP (because stunnel can't support UDP) added to all the problems related to TCP/UDP (your applications protocol) over TCP over TCP, are LESS than the traffic shaping against pure UDP and/or OpenVPN by your ISP or by your system. If you don't have anything in your system that slows down UDP and/or direct OpenVPN (we have seen cases of customers throttling their own systems without even being aware of that...) your ISP is the culprit. Another clue that points to your ISP and not to your system is that in different hours you have got significantly different performance. Even if we assume that it was the Persei datacenter congested (which should not be the case because we are careful about infrastructure of our ISPs), then you should have recorded higher performance on some other location. Kind regards

Hello, how can you know whether the other provider provides connections to the same ports with the same ciphers and same protocol tried on our servers by ddrnewb or not? And even if it did, you can't assume that ddrnewb tested exactly under the same conditions both services. Actually ddrnewb did not specify anything about that, so it's not correct to make such an assumption. And as you can see from the results he/she posted, we were right, either his/her ISP is performing traffic shaping or it's his/her system to do that. Kind regards

@CriticalRabbit Hello, according to your description no leak was possible. Network Lock in Linux operates with iptables which is a frontend to modify kernel tables. When the VM crashed, either the kernel of the guest OS did not work anymore, so the whole machine was dead even at the most basic level - a TCP/IP stack did not even exist anymore probably - or it did still work, in which case outgoing packets outside the tunnel would have been dropped. Kind regards

Hello! We don't see how it would increase security. HMAC is secure, it does not really matter if the lower layer hash is SHA1 or SHA256. SHA1 attempted hash collisions by an attacker are meaningless, because before trying that the attacker should have found the HMAC keys. HMAC SHA256 is not planned at the moment. We are hesitant with ECC for the problem with NIST parameters based curves. These have been created by NSA (by Jerry Solinas) and there are some doubts that must be taken into consideration about "cooked" constants, although unlikely. So the real paranoid person might stay away from elliptic curves based on NIST recommended constants. Please see also: https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters Ideally, OpenSSL etc. should not use NIST curves, there's no reason to do that because there are better alternatives. By the way, in a more general vision, it does appear inappropriate to think about even stronger encryption in our service, either for the Data Channel or the Control Channel. Kind regards

Hello! This topic is dated 2011... now the gift voucher process is fully automated. Kind regards

Hello! How can you say that your ISP does not perform overselling and/or that traffic shaping is not applied? Please try a connection with OpenVPN over SSL to support or deny this claim. In client menu "AirVPN" -> "Preferences" -> "Protocols" select "SSL Tunnel - Port 443", click "Save" and start a new connection. Kind regards

Hello! We just tried sndbuf 8192 rcvbuf 8192 verb 5in Preferences->Advanced->OVPN directives->Custom, with OS X, and everything works fine. Maybe you have a simple typo issue, directives "sendbuf" and "recvbuf" do not exist, but "sndbuf" and "rcvbuf" do. "Opening utun (connect(AF_SYS_CONTROL)): No buffer space available" is a bug that sometimes appears on some systems. It's not related to Eddie (our client), it's related to OS X / BSD and OpenVPN. Unfortunately, we are unable to reproduce it in our labs for investigation. Does your sndbuf/rcvbuf solution resolve the issue, or does it limit it? Do you have ALWAYS the above error? Can you post a full log? Eddie doesn't have in bundle a TUN driver, because Maverick and above already have it (utun). One of the Tunnelblick solution for the 'No buffer space available' is adding a custom directive dev-node tunso that OpenVPN falls back to the older TUN driver. Maybe it could work for you if you have the older driver. Sorry but we can't reproduce this issue, so we can only speculate. Kind regards

Hello! Problem was fixed on April the 13th. Kind regards

Hello! You can use an Air account on as many devices as you wish. Up to three devices can connect simultaneously to different VPN servers using the same account. Kind regards

Hello! Warning: if nameservers are set manually in OS X, Tunnelblick will IGNORE the DNS push from OpenVPN servers. Kind regards

Hello! Performance has nothing to do with Eddie, it's OpenVPN to handle everything in this case. Which OpenVPN version were you running before and which version are you running now? Kind regards

Hello! Because client series 1 is obsolete and nowadays it poses security concerns. We recommended to stop to use client series 1 almost a year ago. Yes, you must do that if you wish to use our client. Otherwise you can run any other client, but not our client series 1. We beg your pardon but it's exactly the opposite. We started to recommend upgrade to client series 2 one year ago. Now a message tells you to upgrade. We repute that one year is enough for everyone. There is no such thing as a special compile. It's the opposite, clients series 2 Eddie are FOSS, client series 1 was closed source software. And frankly we don't see your point anywhere for an upgrade that takes 20 seconds and gives you a much more reliable software, not to mention that it's open source software and with tons of additional commodities. Kind regards

Hello! We're sorry, it's not our duty to fix OS bugs, not to mention the huge work it would require. And then it would be useless unless you have a rooted device and know how to patch Android. However, we can't see the problem, since the bug has been resolved in Android 5.0.1 and later versions, which are available since a long ago, isn't it right? Kind regards