Staff

http://michael.stapelberg.de/Artikel/mtu_openvpn Kind regards

Hello, this is a Windows bug that must be fixed by Microsoft. You can use your firewall in the meantime. Our client software can help but of course we can't be charged with the duty to fix any possible Windows or other systems vulnerability. We will never insert anti-malware functions in an OpenVPN wrapper and for the same reason it would be questionable to insert code to patch extremely specific OS vulnerabilities. Modularity is important. And apparently one should be quite idiot to be effectively exploited with this: you should use weak system password (otherwise the attacker can't rebuild your password from the hash), and use the same weak credentials on a variety of services around. Agreed that the average Windows user is not so smart, but in this case ValdikSS presumption (apparently) is that this user is unrealistically stupid. You mean leak of HASH of your Windows system account password, right? Kind regards

Different problem then. This thread will not help you, feel free to open a ticket at your convenience. Kind regards

Hello, can you please try again now (restart the Air client Eddie if the problem persists)? Kind regards

Hello, can you please try again now (restart Eddie if the problem persists) and report back? Kind regards

Hello, with "OpenVPN over SSL" we have managed to cause WITCH to fail with "mssfix 1275" and lower values. Don't ask us why (we know, it doesn't make much sense in a TCP connection), it was just a quick test out of curiosity, maybe in the future we perform more research. Kind regards

Hello, can you please try again now and report back? Kind regards

Hello, can you please try again now and report back? Kind regards

@drummer45 OS X 10.11.6 is available since July the 18th but it's possible that upgrade from 10.11.5 has been applied only recently on several systems. Thank you for the report. Can you please now test with Network Lock on and route check off? To disable route check please untick "Check if the tunnel works" in "AirVPN" > "Preferences" > "Advanced" (in Eddie 2.11.3). Kind regards

Hello, can you specify your exact OS X version and also tell us whether the problem occurs with Network Lock enabled, disabled or in both cases (with route check enabled, of course)? It has nothing to do with any problem on our side you cite. Instead, we start to suspect it could be a problem of Eddie under specific settings in a specific OS X version. Kind regards

zhang888 is a moderator, so you can consider him as part of forum staff. AirVPN staff is another thing and in the forum only messages from "Staff" can be considered as coming from AirVPN staff. Back to the topic, the question was ill-posed and anyway the reply from zhang888 is precise. Locking thread to prevent further discussions on nothing. EDIT: thread moved to off-topic and unlocked.

Aware of that. The "next build" Clodo talks about has not yet been released at this date. Useless to write multiple times the same thing, please cease, dupe deleted. Kind regards

Did you every sort this problem? It has been dogging me for months. The most common reasons of such issue are antimalware interfering with network settings, problems to DHCP settings of the interface, DHCP client service stuck, tun/tap driver, obsolete physical network interface driver (especially in Windows 10). Before anything else, you might like to make sure that your network card driver is up to date, that no anti-malware software interferes and then test with new driver 9.21.2 (included in Eddie 2.11.3 beta). Also check here for some important addition that could be relevant in your case: https://airvpn.org/topic/16573-tap-driver-9210-causing-a-myriad-of-issues/page-3?do=findComment&comment=46207 Kind regards

Eddie for GNU/Linux main development platform is Debian jessie. Arch Linux is tested as well and Eddie 2.11.3 beta runs fine in it, up to current rolling release. WIth Manjaro we never had specific problems, except that the PORTABLE version was needed. However, latest Manjaro release is not currently in our testing machines. https://airvpn.org/topic/18625-eddie-211beta-available/ We do have a wide variety of testing distributions. It's important that you consider that Eddie 2.10.3 is not compatible with Mono 4. However, Eddie 2.11.3 beta is. For GNU/Linux, we would recommend that you test it. https://airvpn.org/topic/18625-eddie-211beta-available/ If you prefer to not use our client, your symptoms hint to the fact that you did not take care of DNS push. There is no universal method in GNU/Linux to take care of DNS push, but in all those distros in which resolvconf is available and working properly (with initd) we would recommend that you use it. See our guide about it in the "How-To" sub-forum. https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/ If systemd prevents correct usage of the script based on resolvconf, please see here: https://wiki.archlinux.org/index.php/OpenVPN#DNS Kind regards

The software has no code to alter the system proxy settings. You were probably working on the wrong assumed cause. Don't jump to early conclusions about the causes of the problem and send a complete report ("Logs", then click the life belt icon and paste into your message) to the support team (open a ticket). Kind regards

Eddie 2.11 final edition will have the 'hidden' feature to run any VPN OpenVPN configuration, not just AirVPN. 'Hidden feature' because the UI will not include it yet. It will remain usable in manual configuration, mainly for beta-testing and skilled users. We will post a guide about that soon. Eddie 3 will feature a full UI interface for that. Kind regards

Yes, that's the Eddie sources repository. Alternatively you might like to upgrade to Eddie 2.11.3 beta which is compatible with Mono 4 and runs very swiftly, even on Ubuntu 16.04. It features tons of bug fixes on the UI and much more: https://airvpn.org/topic/18625-eddie-211beta-available/ https://airvpn.org/services/changelog.php?software=client&format=html Kind regards

Not on 2.11.3 beta which by default has "Force all network interfaces...." de-selected, because we expected (and tested) that a new approach to prevent DNS leaks worked properly. However, according to various reports, this might not be the case. We're investigating to try to understand the source of the issue. Maybe you had a previous AirVPN.xml which has that option enabled. Kind regards

Hello! This is a bug in Eddie 2.10.3 with Tor in Tor Browser 6, which has been fixed in Eddie 2.11.x beta, can you test? Please see here: https://airvpn.org/topic/18625-eddie-211beta-available/ Kind regards

Please upgrade to 2.11.3 beta. Kind regards

Hello! Option added in the latest experimental. Can you reproduce the crash every time? OS version? Thanks. Kind regards

If you really want to try and find a solution check your ISP. Since we work with dozens of different datacenters, assuming that they all have the same problem at the same time and your ISP is perfect will not help you fix the issue. We could name several reasons, for example dynamic traffic shaping based on time, destination ports and protocol. Try to make a comparison, when the problem occurs with any datacenter you try, between a direct UDP connection, a TCP connection and an OpenVPN over SSL ("SSL Tunnel - Port 443" in Eddie) connection. Additionally, test your ISP directly (no VPN) with different destinations in HTTP, HTTPS and BitTorrent for example (this is in many cases very revelatory about traffic shaping). Just in case you live in the European Union: ISPs are obliged to tell you in a clear and understandable way any limitation of any sort they enforce on protocols and applications, so if they perform traffic shaping you will find the description in the contract (although they can play with words by calling it "fair usage", "traffic management", "better experience" and similar bullshits). Kind regards

This is fixed in the latest beta edition. Topic closed, any issue with beta edition must be posted in its topic.

Thats why i was asking ;-) Hello! A bad mistake, we did not edit this. That was a momentary behavior that needed a fix. Now it has been fixed but we did not edit the message, we apologize for the inconvenience. Kind regards

Hello! Note that when the client is not running there is NO Network Lock. The client restores WFP or firewall rules when it is shut down. Additionally, the rules do not survive a reboot. Both these features are intentional. If you wish a permanent Network Lock the solution is trivial, just block all the traffic with pemanent firewall rules and keep Network Lock enabled. Then, you have a particular case. If Eddie crashes, or when it is killed without grace, the Network Lock remains "active" (this is of course essential), but as usual will not survive a reboot. Kind regards