Staff

Absolutely nothing changed under this respect between 2.10.1 and 2.10.2. Printing under Linux (via CUPS or direct TCP/IP access to a network printer in the local network) has always worked just fine for us. Kind regards

Hello, we have identified the problem for gamespot.com Can you try again and confirm that it works now ? Kind regards

Hello! Hulu explicitly blocks connections from non-residential lines. ABC performs an additional HTML5 geo-location. If you disable HTML5, ABC will refuse to stream. A possible workaround (untested) with Firefox could be: http://www.instantfundas.com/2011/03/fake-your-location-in-firefox-with.html With Chrome (again, untested by us): http://www.labnol.org/internet/geo-location/27878 Kind regards

Hello, this error: . 2015.08.02 10:49:01 - OpenVPN > All TAP-Windows adapters on this system are currently in use. is usually caused by a disabled tun/tap adapter. Try to re-enable it, or re-install OpenVPN. Kind regards

Hello, by default connections to an Air VPN server go to port 443 and this may cause the problem. Maybe the program you cite blocks outbound ports to prevent leaks, and blocks outbound port 443 unconditionally, unless you allow HTTPS. Try to connect to port 2018. In order to see all the possible connection modes in the Configuration Generator tick "Advanced Mode". Then, you should tell that program that is should not block traffic to port 2018. Kind regards

Sorry, please ignore that message, it needed to be edited and was published by mistake. Kind regards

Hello! A new experimental version 2.10.2 is available. It addresses some issues of our customers. @altae and @bigbrosbitch: German Umlaute and your issue about printer is still under investigation. Sorry. @lamictal and @tlc: Please retest with this new version. Please report the logs if the problem persist. Kind regards

Hello, we have identified the problem. Can you try again and confirm that it works now ? Kind regards

Hello, you're wrong. Kind regards

Hello! Usually this problem arises in Windows when the Air client Eddie is not shut down properly. While Eddie is NOT running, please check DNS settings and reset firewall rules. These operations will probably fix the problem. How to restore Windows Firewall settings in Windows 7 (procedure is almost identical in other Windows versions): http://www.digitalcitizen.life/restore-windows-firewall-defaults How to change DNS: https://www.opennicproject.org/configure-your-dns/how-to-change-dns-servers-in-windows-7 About which DNS servers to pick, we would recommend OpenNIC (see https://www.opennicproject.org ) but of course you can select any public DNS you prefer. Always make sure to shut the Air client down properly, from its own menu. Never kill Eddie without grace, unless that's absolutely unavoidable. Kind regards

Hello, out of thousands working systems, there are always very particular cases. Eddie in Ubuntu 14.04 works well with every DNS Switch method and in more than one year has never been reported as having problems. Ubuntu 14.04, after Debian wheezy, was our main testing Linux box between 2014 and 2015 and we never detected any problem. We suspect that the problem you report is completely unrelated to this thread. Kind regards

Hello, it's important to understand that with a browser extension you will prevent such leaks from that browser ONLY. With Network Lock you will prevent such leaks from any application and (more importantly) from any application that tries to bind to your physical interface(s). Please see also here to understand what the matter is, there's much more into play. http://www.clodo.it/blog/an-alternative-approach-to-so-called-webrtc-leaks Kind regards

Hello! It is a problem of all systems with resolvconf installed but not configured in Dynamic Mode. However, at least one of our customers did manage to reproduce the issue with Ubuntu 15.04 even with resolvconf configured in Dynamic Mode. This is just one case but maybe we're still missing something about it. The problem remains unclear because in our brand new Ubuntu 15.04 testing machines, the problem has never been reproduced. So it could be something related to systems which have been brought to version 15 via a dist-upgrade, instead of a plain, new installation (like our testing systems). Anyway, "renaming" method solves the problem at its roots. Kind regards

Hello! In all the cases we know that error is caused by Avast. Kind regards

Hello! Oh, yes, the problem is with www.elephanttube.com, not with elephanttube.com. They might have problems with their authoritative server, or maybe there's something else (see below), we'll look into the issue in the near future. In the meantime enter the following line in your hosts file to access the web site: 64.188.63.185 www.elephanttube.com $ dig @10.4.0.1 www.elephanttube.com ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @10.4.0.1 www.elephanttube.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53240 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.elephanttube.com. IN A ;; Query time: 262 msec ;; SERVER: 10.4.0.1#53(10.4.0.1) ;; WHEN: Wed Jul 29 14 :27:27 2015 ;; MSG SIZE rcvd: 38 Kind regards

LOL, they're zeriouz hackars

Hello, we don't think so, please elaborate: $ dig @10.4.0.1 elephanttube.com ; > DiG 9.8.4-rpz2+rl005.12-P1 > @10.4.0.1 elephanttube.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;elephanttube.com. IN A ;; ANSWER SECTION: elephanttube.com. 14 IN A 64.188.63.185 ;; Query time: 102 msec ;; SERVER: 10.4.0.1#53(10.4.0.1) ;; WHEN: Wed Jul 29 13:55:03 2015 ;; MSG SIZE rcvd: 50 Kind regards

Hello, Eddie 2.10.1 Experimental is available, not yet "Stable". In the usual download page click "Other versions" and select "Experimental". We think that Eddie 2.10 will be promoted to "Stable" in a few days, if nothing goes wrong. Kind regards

Hello, we have identified the problem. Can you try again and confirm that it works now ? Kind regards

Hello, we have identified the problem. Can you try again and confirm that it works now ? Kind regards

Ok, done. Enjoy AirVPN! Kind regards

Hello! You can maybe discard those claims because: However it must be clarified which service was reachable in the system that was in the VPN and how you performed tests with that utility. Occasionally you may encounter a host which has somehow assigned itself an IP address in the 169.254.0.0/16 range. This is a particularly common symptom ofWindows machines which have been configured for DHCP but for whatever reason are unable to contact a DHCP server. When a host fails to dynamically acquire an address, it can optionally assign itself a link-local IPv4 address in accordance with RFC 3927. Microsoft's term for this is Automatic Private Internet Protocol Addressing (APIPA). http://packetlife.net/blog/2008/sep/24/169-254-0-0-addresses-explained/ Probably not meaningful in your case, you can ignore it, it should be just some "unconfigured" tunneling interface. 10.4.0.0/16 is in the range of the VPN IP addresses when you connect to our service to port 443 in UDP, see also https://airvpn.org/specs So, if that interface which is assigned an address in the range 10.4.0.0/16 is a physical interface, a conflict will arise when the tun adapter IP address is DHCP-pushed by our servers. In this case change connection port (for example, connect to port 80 in UDP). On the contrary, if that's the tun/tap interface, then it's all right. After that, an additional problem must be considered. If your system has multiple interfaces for multiple ISPs, it will have multiple gateways. This can become a major problem for OpenVPN and can also pose the question about how Plex binds to what. However, feel free to clarify, because that's not totally clear from your message: According to all of the above, it seems that the problem pertains only to Plex: traffic is tunneled and remote port forwarding appears to be working. OpenVPN logs and output of commands "ipconfig /all" and "route print" (while the system is allegedly connected to the VPN) can help. Kind regards

Hello, if your ISP does not shape OpenVPN traffic, then direct UDP connections are the most efficient. An additional SSL/SSH tunnel adds packets, protocol and encryption overheads. On top of that OpenVPN is forced to work in TCP mode, which is significantly less efficient for how OpenVPN works. So, under a performance point of view only, OpenVPN over SSL/SSH should be used only when strictly necessary. Eddie usage is optional and we will never force our customers to use our software to connect to our service. That said, unless you have some very specific requirement that our client can't meet (in which case, we would be glad to know them), we don't see a good reason for which you should drop it. Eddie developer has made every effort to keep maximum flexibility, freedom and comfort with Eddie. It is very much configurable in every aspect. You can define your own custom directives and routes, you can run your own scripts or programs when various events occur (App Start, App End, Session Start, Session End, VPN Pre, VPN Up, VPN Down) and you can run it either with its GUI or in command line mode. You have also total control on DNS. Eddie adds a remarkable set of commodities that are specific to our service, features an exclusive "OpenVPN over Tor" mode and checks all VPN servers to provide you with meaningful ratings which help you pick the best VPN server for your node. Kind regards

Hello, please click "Enter" from the upper menu of our web site then click the icon matching your system to access instructions and download page for that system. Please read the courtesy e-mail for an executive summary of our service. We also recommend that you read answers to FAQ. To hide Tor usage to your ISP connect to a VPN server. Once the connection is established use Tor. Kind regards

Maybe. We'll check the AAAA record. EDIT: yes. The problem has now been fixed. Within the TTL at the latest everything should be all right. Kind regards