Staff

Hello! Since TCP is "slower" than UDP for some reasons you will find explained in the FAQ, the above results are a strong indication that your ISP is heavily shaping your UDP traffic. Anyway, another option is that you have, either in your computer or your router, some packet filtering/inspection/security tool that's shaping UDP traffic. Kind regards

Hello! Actually the average performance on NL servers has slightly improved after the four 1 Gbit/s NL servers addition, because clients have "re-distributed themselves" on all the servers, relieving load on most populated servers such as Corvi and Leporis. As a first attempt, please try connections to different port, in particular test port 53 UDP, just in case your ISP has suddenly started to shape your traffic to port 443 UDP. Given your available bandwidth, also avoid connections to the 3 NL servers with a 100 Mbit/s port, please pick only servers with 1 Gbit/s availability. You can anytime look at the servers status here: https://airvpn.org/status Feel free to keep us informed. Kind regards

Hello, please re-format the message properly and re-post it. The current text formatting makes the message very hard to be read. Kind regards

Hello, your network card MAC address never gets out of your internal network, so Google (or any other entity) can't detect it. Remember that a MAC address is simply not included in IP packets. Kind regards

Hello! Of course, once the tunnel is established the provider can't selectively discern traffic. Either it blocks everything (disrupting OpenVPN connection) or nothing. If your system resolves correctly names (with nslookup, ping etc.) the problem is in the browser. What happens if you type an IP address directly on the browser bar, for example https://95.211.138.143 (it's airvpn.org main frontend IP address). You should get a certificate warning because the browser expects "airvpn.org" according to the certificate. If you get no connection at all, then it's not that your browser is unable to resolve names, it's probably something that blocks browsers packets INSIDE your system. Can you confirm that, while connected to the VPN, commands such as "ping google.com", "traceroute airvpn.org" are successful? Also, can you please check that the system can reach 10.4.0.1? "ping 10.4.0.1" FInally, according to your description chances are that this provider filters UDP packets. Try a connection in TCP mode to 80 and 443, and in UDP mode to the DNS queries outbound port (test ports 80 TCP and 443 TCP, but also 53 UDP). Kind regards

Hello! Ok, so ignore the previous answer. Tunnelblick 3.2.8 can't be used on OS X Mountain Lion and Mavericks. Kind regards

Hello! It's probable that it's the hotel line that regularly drops. When you're not connected to a VPN this causes short black outs which might be more or less tolerable, but when tunneling these drops will cause a longer data flow interruption. Kind regards

Hello! Yes. It's correct and insignificant since any outbound packet would be blocked if the system is not connected to the VPN, so it does not matter (for leaks purpose) whether incoming packets are dropped or not. Kind regards

Hello, if/when that law is definitively approved we will read it. Useless to do it repeatedly now as long as it can be amended and/or radically changed. Please consider that we can't read hundreds or thousands of draft laws every month in 15-16 countries. Kind regards

Hello! OpenVPN over SSL connections will be probably supported in the final Eddie release (the next client version). Remember that you should never use OpenVPN over SSL except for extreme cases. This is an additional, free of charge service originally designed for China only. In order to easily switch servers over SSL, first prepare all the files you need for all the servers you wish to connect to, so that you can switch them in a matter of seconds. The Configuration Generator accepts multiple choices so you will need just 30 seconds for the initial generation (once and for all), we fail to see why it should be such a pain for you. About your problem, it might be a DNS issue, since the logs look just fine. While your system is connected to a VPN server, please open a command prompt (with administrator privileges), issue the following commands and send us the output: ipconfig /flushdns tracert google.com ping 10.4.0.1 ping 8.8.8.8 Kind regards

Hello! Can you please test whether there's any improvement by watching Hulu from a UK server? Kind regards

Hello! If your firewall has "IPv6 filtering" enabled and drops outgoing IPv6 packets you don't need to worry. Otherwise, in case you run Windows and your ISP supports IPv6, it's safer to disable IPv6 in order to prevent DNS leaks. Kind regards

Hello! We see that your account is connected since more than 1 day ago and successfully exchanging data. Please remember that you can't establish multiple connections with the same account. Kind regards

Hello! Yes, you are right, and your exposition is correct. This is related to the identity-mixing issue (discussed in the forum about since 2-3 years ago). Identity mixing must be avoided. Remember that a VPN protects your line, not your behavior, and can't prevent the information that you willingly send out to be actually sent out. Kind regards

Hello! No, not at all. The answer is "no" to both questions. Kind regards

Hello! Your firmware build is very old and you might probably need to upgrade. Also, can you please send us the (attempted) connection logs? Kind regards

Hello! Done, enjoy AirVPN! Kind regards

Hello! Please refer to your ticket. Kind regards

SSL/TLS UDP or TCP according to your choice. TUN It depends on your router setup. Surely not local host. Ok. 53, 80 or 443. Uncheck. The ca.crt file that you must download from the configuration generator. The user.crt file that you must download form the configuration generator. Ok. Kind regards

Hello! Absolutely not, there's no overselling as usual. You can easily check that on the servers monitor. As we already explained to you in your ticket, it's a problem on your end, it's not possible that suddenly 2 days ago 5 different datacenters with different tier1 providers have all started simultaneously to have the same identical problem. Additionally we do not record any issue neither with the old nor with the new USA servers. Kind regards

Hello! You just need to: - remotely forward a port from your control panel (do not remap it to a different local port) - set that port in your torrent client - make sure you do not forward that port on your router (exception: if OpenVPN runs in the router itself) Kind regards

Hello! First of all, it's important to note that the sentence in bold is totally wrong, and it's strange that a VPN provider claims that (maybe it's just a misunderstanding with TorrentFreak). It would be GREAT if it was true, but it isn't. OpenVPN traffic to port 443 TCP is profoundly different from "standard http over SSL" traffic. One of the differences is that OpenVPN performs a packet wrapping with some important additional data (for packets re-ordering etc.) which makes the OpenVPN traffic discriminable from https or pure SSL/TLS through Stateful or Deep Packet Inspection. That's why it's possible to easily discern the typical OpenVPN traffic "fingerprint" and block it, like they do in China, and that's why we offer OpenVPN over SSL. We wish to underline that, because otherwise you could think that we're "stupid" to provide OpenVPN over SSL or SSH with the purpose to bypass OpenVPN disruptions in China and Iran. Encapsulating OpenVPN traffic into http by default would be a major breakthrough (at the expense of an important performance hit, probably) which is being discussed for possible implementation in the next paramount release, OpenVPN 3, which might see the light in 2015. However, there are important problems to be considered for this implementation, so it is uncertain whether it will be supported in OpenVPN 3 or not. We provide to option to connect to ports 53, 80, 443 and 2018, all of which with protocols TCP and UDP, according to your preferences. We also provide the option to connect OpenVPN over SSH to ports 22, 80 and 53 (only TCP, obviously) and OpenVPN over SSL to port 443 TCP. PPTP has been discarded even before the official birth of AirVPN. We have never supported it and we will most probably never support it. IPsec has been discarded as well, although for very different reasons. Kind regards

Hello! Communication logs are not written at all. Until the disconnection, what is kept (in RAM) is the VPN IP address, your node IP address (obviously, otherwise there would be no communication at all with your node!). Additionally, the amount of exchanged data in that session and the duration time of the session itself. Finally, the average up and down "speed" of the last 60 seconds are calculated. All of these data do not affect privacy but at the same time help us to verify that a server is functioning properly. All of these data are lost forever when the client disconnects. Only for troubleshooting purposes you can force the system (from your control panel) to keep logs of the total amount of exchanged data and duration time of each session for your user (if you decide to do so, you can anyway disable this function, which will cause deletion of those data). You can't anyway force the system to store your session IP addresses. Kind regards

Hello! After an attempted connection please right-click on the Air dock icon, select "Logs", click "Copy to clipboard" and paste into your message. Kind regards

Hello! Yes: packets to several trackers are re-routed through the node you observed (thank you for not having published the IP), which is operated by us and properly forwards those packet to the correct destinations. We will soon publish in the web site a menu that will allow you to see "re-routed" destinations for transparency purposes (although the IP addresses of the nodes through which the re-routing occurs will not be publicly revealed). We have implemented this system to bypass trackers IP blacklists, avoid (at least for the re-routed trackers) IP harvesting of our VPN servers exit-IP addresses by hostile entities through torrent trackers querying, and to encrypt torrent trackers queries and replies from the VPN server to the micro-routing node. For consistency, the tracker of checkmytorrentip is "re-routed" as well. Kind regards