Staff

Depends. It would be difficult if Youtube streams everything encrypted and doesn't cooperate, but I believe streaming goes out over plain unencrypted http. (I could be wrong.) So you should be able to find out what video a certain stream is just by looking at it. Hello, as a side note: you should be right, while you can access YouTube web site over SSL/TLS, the videos download is not encrypted end-to-end (not to be confused with encryption of the content for DRM purposes, which is active on some videos and that can be "circumvented" by anyone), according to a quick research performed by Martin Sauber at the end of 2012: http://mobilesociety.typepad.com/mobile_life/2012/12/observation-youtube-is-now-https-but-the-streams-are-not.html Re-performing that test, now that 7 months have passed since the writing of the article, is easy with Wireshark. Kind regards

Hello, we wrote something last year about how to defeat an adversary with similar powers, or multiple adversaries that co-operate with each other (and also with some higher powers): https://airvpn.org/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 Kind regards

Hello, just a "curiosity" side note, technically "over" is the correct term of common usage, while "through" may be confusing in some contexts. It's not that packets headers and payload are "pasted through" other packets headers, see also here to understand why "over" is preferred to avoid confusion: http://en.wikipedia.org/wiki/Tunneling_protocol So, for example, "OpenVPN over SSH" is a clear definition, while "OpenVPN through SSH" might cause ambiguity, it could be unclear whether it means "SSH over OpenVPN" or "OpenVPN over SSH" or even something else. Kind regards

Hello, we don't know how Netflix operates, anyway as a first, preliminary attempt, try to delete cache and cookies (including LSO Flash cookies) from your browser and from your Flash environment (if Netlifx uses Flash). Thanks to a very kind Air user, we should be able to test Netflix in the nearest future. Kind regards

Hello, that's correct. SSH connects to our servers and OpenVPN connects to SSH (it's OpenVPN over SSH). Once OpenVPN packets are encrypted again (the previous unencrypted header becomes part of the new encrypted by ssh payload, the previous encrypted header and payload are again encrypted and become part of the new encrypted payload; the new cleartext header is by SSH) and encapsulated, your SSH "client" sends them to our servers. In your system outgoing/incoming traffic, OpenVPN fingerprint is therefore never visible. Kind regards

Hello, yes! Kind regards

Hello, background for the readers: http://blogs.cisco.com/security/hijacking-of-dns-records-from-network-solutions/ You are wrong in searching for a solution on your side or on VPN side. We mean that maybe you're looking at the problem from an incorrect point of view. The exploit (if we can call it exploit... technically it might be incorrect to name it so) works by obtaining unauthorized access to the DNS authoritative nameservers, or by fraudulent practices by the operators of the nameservers themselves against their own customers! About the case you cite, please see also here: http://en.wikipedia.org/wiki/Network_Solutions#Controversy_over_subdomain_hijacking We also strongly recommend that you read this: http://en.wikipedia.org/wiki/Network_Solutions#Controversy_over_domain_name_front_running Thank you for having brought into attention this important topic. We're moving the thread to "General & Suggestions", everyone interested in registering domain names should be aware of the aforementioned practices and should avoid searching for domain names availability from Network Solutions systems. Kind regards

Hello, https://en.wikipedia.org/wiki/Extended_Validation_Certificate#Criticism Anyway we'll keep this option open. Kind regards

Hello, the traffic on the physical interface is equal to the sum of the traffic on the tun interface plus the overhead plus the internal network traffic plus some more (for example ping to VPN server) - so it is always higher than the tun0 traffic. If it's reasonably higher, it's perfectly normal. Browse to our web site and check the central bottom box for additional security (it must be green), or browse to http://ipleak.net Kind regards

Hello, it's already so (dynamic assignment). However that should not increase (or lower) security. Kind regards

Hello, geographical location detection through IP address is a messy matter. It's very difficult to keep a database in good order. It's very common that geo-IP location errors happen. Kind regards

Hello, excellent. Well, it's there (both on the Linux instructions and on the Config Generator help page) since months, maybe you missed it... Kind regards

Hello, we don't keep any log that can be exploited to identify a customer or a VPN client IP address and there's no law (not even in the UK) which enforces that. In the countries we operate, either our service is not within the scope of 2006/24/EC transposition, if such transposition exists, the 2006/24/EC transposition has been declared unconstitutional, or the transposition does not exist. Additionally, we do not monitor or inspect OpenVPN clients traffic and we do not transmit any data to third parties while a client is connected to a server. Kind regards

Hello, can you please publish the OpenVPN and network-manager logs? Kind regards

Hello! You can download OpenVPN, configuration files (including certificates and key) and tun/tap package all at once in our Configuration Generator as usual (just like with Tunnelblick, but in this case tick "Bundle with executables"). For very important information about using OpenVPN directly on OS X, please see here: https://airvpn.org/topic/9325-development-of-os-x-airvpn-client/ Do not hesitate to contact us for any issue. Kind regards

Hello, Tunnelblick, OpenVPN and Viscosity are all ready to use. Kind regards

Hello, thank you for your efforts and thank you for sharing! It looks good and very comfortable, some of us will test it and after that if it's all right we'll move it to the how-to. Some specifications for the readers: in order to work properly, the script needs the Configuration Generator set to "Resolved hosts" (*) so that in the .ovpn files "remote" line(s) there will always be an IP address, not a name (would the Windows firewall work properly with domain names instead of IP addresses?). It's important to specify because the majority of Windows users run the Air client, so they probably have never used the Configuration Generator. (*) anyway "Resolved hosts" is forced if the Configuration Generator is set in Windows mode - problems may arise only if a Windows user runs the Configuration Generator in some other OS mode. EDIT: alternatively we might provide something like "fake.ovpn", a simple text file with all entry IP addresses preceded by the "remote" keyword (if the script scans all the "remote" lines, i.e. if it does not stop at the first found "remote" line). Kind regards

Hello! The LAN/WiFi card DNS. Kind regards

Hello, no: the 10 Mbit/s value is just hard coded as a bogus value, it means nothing. Kind regards

Hello, can you please open a command prompt, issue the following command and send us its output? tracert airvpn.org Kind regards

Hello, if you use network-manager, please make sure you follow the instructions, in particular when they say to tick "Advanced Mode" and tick "Separate certs/keys from .ovpn files", because nm does not support embedded OpenVPN configuration files. Kind regards

Hello! We detect high packet loss (see also the Ping Matrix from the Status page) at the moment. EDIT: the problem seems solved now. Kind regards

Hello, about how that's possible, probably you're running Windows. Windows lacks the concept of global DNS. When Windows needs to send out a DNS query, svchost.exe (a system process running with high privileges that does many things) takes care of it. However, svchost.exe does not always send out the DNS query to the DNS server of the correct network card according to routing table and gateway. Now and then, under certain conditions (some of which are probably unknown to us, while others have been empirically determined) svchost.exe decides to send out DNS queries to the DNS server specified in some other network card, following the routing outside the VPN and causing the DNS leak. About fixing the DNS leak, you have various options, the quickest is probably forcing 10.4.0.1 and 10.5.0.1 as primary and secondary DNS IP addresses in your system physical network card. But please search the forum or look at How-To section for more solutions. Kind regards

Hello! Something's wrong, probably during the connection, can you please send us the Air client logs after a connection is allegedly established? Please right-click on the Air dock icon, select "Logs", click "Copy to clipboard" and paste in your message. Kind regards

Hello and welcome aboard! You need to follow the guide linked at the bottom of the instructions for Windows, direct link: https://airvpn.org/windows_autostart Alternatively, you can disable UAC. Kind regards