Staff

Hello htpc! 255.255.255.255 is already allowed by default (to let DHCP work). there must be something else needed by the protocol. Kind regards

Hello! Support to a system that's been abandoned by its own creator on 2009 and whose extended support ended on 2014 is a courtesy. It is not advertised anywhere that we support abandoned systems. "Support to Windows" means support to Windows x86 active systems, it can't be in any way meant as support to Windows 1, 2, 3, 3.1, 95, 98, ME, XP and any other bunch of Windows abandoned system. Additionally our free and open source software is not mandatory to connect to our service: you can connect with OpenVPN. Our software for example can not support Network Lock in XP, because of WIndows XP Firewall limitations. Route check and DNS check are an additional feature that we are trying to keep up even with the archaic XP system, but if it's not possible we will not compromise security and you will need to disable route check and DNS check in the software (or just use another software to connect). An abandoned system can't be updated to patch vulnerabilities and keep up with the normal development of security, encryption and a wide variety of subjects. Windows XP was already a security nightmare when it was regularly updated. Keeping using it in 2016 is unreasonable if security is a priority. And you can see one of the reasons right now, see our post about lack of AES cipher suites support at system level. You can't pretend that we solve problems that you create to yourself, but we'll try in any case. As we said, keeping RC4, even for checking route only, is no more acceptable. We will not sacrifice this in the name of an abandoned system. We can't and we must not be interested in what you assume most people think they need. We provide a state of the art service in its field and we will continue to do so. We will not compromise anything for the alleged needs of people who can't even realize the dangers of running an abandoned system. There are a lot of other services out there run by incompetent people who do not hesitate to compromise security just to target gullible people and earn a few more subscriptions and pretend to agree with you about how using XP nowadays does not pose any problem. Air is not and will not be one of such slimy services. Kind regards

Traffic shaping devices have reached a remarkable flexibility. They can shape traffic on a wide variety of factors and conditions. They can decide when shaping traffic on protocols, ports, patterns, times and according to pre-defined conditions when they are met. Traffic shaping on a user basis is also perfectly possible. What appears random to you could hide a very precise underlying pattern, for example reacting to congestions, demands etc. on some segments (this is just an example). Alternatively, it's only congestion, without shaping, which apparently occurs randomly. Of course all of the above can't rule out your legitimate suspect. Some specific occurrence in your system might make the behavior apparently erratic, in this case it's mainly up to you to try to find what's wrong in your system. A useful comparison could be testing a different computer with a different system on the same line, with the same router and the same conditions; and then testing with a different router. That's very interesting, so the old limit has been bypassed. Kind regards

Hello! The problem arose when RC4-SHA cipher was disabled for the route check. It comes out that Windows XP does not support any AES cipher suite in TLS: https://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=vs.85%29.aspx At the moment we fixed the problem by allowing RSA-3DES-EDE-CBC-SHA (we deemed RC4 not acceptable): TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA However this event once more shows that Windows XP should no more be used when security is a priority. It is an abandoned system. It seems somehow contradictory to use AirVPN services while at the same time running Windows XP... Kind regards EDIT: the problem does not seem resolved. We are investigating. Problem solved.

Hello! We're sorry, it appears that it is currently not possible to connect to our service with Eddie and Windows XP SP3. We are investigating. Kind regards

Strong clues hinting to congestion or traffic shaping. OpenVPN over SSL, in a totally agnostic network and on equal terms, must be slower, it can't provide same or better performance. Performance fluctuation hints to traffic shaping and/or congestion as well. We once again underline that we are not informed about a precise limit of the tun interface on Windows with the driver 9.21.2. Kind regards

Download the experimental, it does not require Mono. It does require Mono. However, unlike Eddie 2.10 and older versions, it is compatible with Mono 4. Kind regards

Just allow the IP addresses required by a particular protocol you need in Eddie. Also consider that sometimes the problem comes from the inability to resolve local names when local DNS is no more used (when you are in the VPN, your system queries the VPN DNS by default), so act accordingly. Kind regards

Amazingly good for a TCP connection from a Windows machine. Test OpenVPN over SSL as well. Kind regards

Hello! Please make sure to run Eddie 2.11.x beta, because Eddie 2.10.3 is not compatible with Mono 4 and will pose a variety of issues on Ubuntu 16.04. https://airvpn.org/topic/18625-eddie-211beta-available/ Kind regards

Connection modes with destination port 1194 are available only in 2.11.x, not in 2.10.3 or older versions. Re-upgrade to 2.11.3 and anyway keep driver 9.21.2. Maybe a combination of bad peering, congestion and traffic shaping enforced only on certain peak times. Of all the modes you tested, you missed the "OpenVPN over SSL/TLS", test it as well. The fact that you don't see any difference between UDP and TCP, however, hints to traffic shaping. because if the network was really agnostic, and any other condition is the same, there would be no way to reach the same performance of UDP with TCP. Note: it remains to be seen what performance the new tun/tap drivers can handle with the tun interface. The old 9.9 ones could not beat 100-110 Mbit/s on Windows (this peculiar limitation affected only Windows, of course), while 9.21.0 and 9.21.1 are bugged, so we recommend that you rely only on 9.21.2. Anyway 170 Mbit/s on the tun/tap interface looks like a very good performance in Windows. Kind regards

"Allowing" does not mean "no shaping". Anyway please test port 1194 (the "officially reserved to" OpenVPN port) to check whether there's any performance improvement. Also test with sockets buffers forced to 256 KB and 512 KB (verify on the client logs what your system currently sets). In Windows, the sockets buffers sizes should not be set to "Automatic" by default: which Eddie beta version are you running? Did you manually set them to "Automatic" (even in some past version of Eddie)? Finally post all the logs of a single connection, just in case there's some useful clue. Kind regards

What MTU do you refer to? tun MTU is 1500 bytes and can't be modified unilaterally, of course. Ethernet MTU is 1500 bytes as well, are you in a jumbo-frames supporting network? See also https://en.wikipedia.org/wiki/Maximum_transmission_unit Kind regards

Hello! For practical purposes, Windows tun/tap driver versions "9.0.0.x.y" are defined as "9.x.y" (i.e. the ".0.0" is stripped out). Driver 9.21.0 and 9.21.1 are problematic and should not be used anymore. However, driver 9.21.1 is still included in Eddie 2.10.3 package. Driver 9.21.2 fixes a lot of issues and is included in Eddie 2.11.x package (currently in public beta testing). Driver 9.9.2_3 appears to perform very well on every Windows version, except Windows 10, for which we have reports of compatibility problems. Kind regards

Hello! In your case the problem appears different: route check and DNS check do not even start because the connection can not be established. Something is blocking UDP and/or OpenVPN packets, according to the logs. Before anything else please check any packet filtering tool, both on your system and router. Kind regards

Hello! Either that's not the hosts file used by the system or you didn't save it after the edit (we see it's "Locked" according to the editor). Kind regards

Hello, please add the line: 127.0.0.1 localhost anywhere in the hosts file. Kind regards

If content providers made an effort to make content available everywhere there'd be fewer people stealing it. Copyright infringement has nothing to do with stealing, because copyright is not a property but an enforced monopoly that grants exploitation and rights (with limitations and exceptions) of an original intellectual work. In most legal frameworks, stealing and copyright infringements with profit purposes are completely different criminal infringements, while copyright infringement without profit purposes is a civil offense, not a criminal infringement at all. Maybe your demented definition has been encouraged or influenced by the campaign of some copyright enforcement agencies which preferred to make confusion in advertising campaigns clearly targeted to ignorant people. Kind regards

Hello! There an inconsistency between your claims and your system claims. Both can't be true at the same time: Kind regards

Unfortunately it's not possible for anyone to provide you with proper help. At least, logs taken after the problems occurred are strictly necessary. Since you all have in common Windows usage, first of all do the following, and then let's start over troubleshooting with logs and relevant information on your systems. Also we must underline that your description of the problems is confused, contradictory and seems to be mixing different, overlapping problems. make sure that your network interface driver as well as your router firmware are up to dateupgrade to Eddie 2.11.3 beta, which will automatically upgrade tun/tap driver to version 9.21.2 (older versions can cause various problems, including those which you describe)make sure that you do not run any third party network managermake sure that you do not run antimalware tools, "security suites" and all that jazz (disable them momentarily for your tests)Note: release of Eddie 2.11.4 beta is imminent: upgrade to Eddie 2.11.4 when available. Kind regards

Hello, from what we can see in the screenshot your system can't resolve the name "localhost". Your hosts file has been somehow modified incorrectly. Please fix by inserting the line: 127.0.0.1 localhost as first line of the hosts in your hosts file. Instructions on how to edit the hosts file in your Operating System can be found by using any web search engine (if in doubt, tell us your exact OS version). Side note: please never send logs in pics, send text instead. Kind regards

Thanks - but I dont understand exactly; what should I look for in resolv.conf? The name servers. Set the first nameserver to 10.4.0.1, with the line: nameserver 10.4.0.1 when connected to the VPN. You might also like to answer to zhang requests for additional investigations. Accepting DNS push on systemd based systems poses different issues than in initd based systems. Alternatively just run Eddie 2.11.3 beta, it directly and automatically manipulates resolv.conf Kind regards

Hello, please explain the meaning of this sentence. What directives did you enforce? If it has something to do with mssfix, note that unless you have fragmentation you must NOT limit TCP sessions packets sizes inside UDP. If you have no fragmentation, that will only harm performance, not improve it. Try larger OpenVPN buffers sizes, alternative connection modes, different servers in various locations and if you run Windows take care to use tun/tap driver 9..21.2, latest available driver for your physical network interface and no third-party packet filtering tools and network managers. If your problem persists include connection logs and system report, without them it's hard to say anything else. Kind regards

Hello, yes, it's obvious that if you want maximum performance you must disable uTP. uTP purpose is to cap/limit/throttle in various refined ways the bandwidth your system reserves to p2p. In the VPN the shaping effects can be amplified. Kind regards

Hello! @Milou13 You are probably running a Kali version with Mono 4 package. Eddie 2.10 is not compatible with Mono 4. Run Eddie 2.11.3 beta, which is fully compatible. @highchilled There are no DNS leaks in Linux. Check resolv.conf https://airvpn.org/topic/18625-eddie-211beta-available/ Kind regards