Staff

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

Hello, this is possible only if your system is not tunneling traffic (for example if your system is not connected to the VPN). Another option is that your torrent client is forced to bind to your physical network interface, in which case it can bypass the tunnel. If your system were tunneling properly, it would not matter which inbound ports your system administrator blocks, they are NOT your college/corporate/office/ISP network IP address ports. In this case a port is an abstraction to designate with two bytes in a packet header an end-point of a process or task in a system. When you remotely forward a port, it means that you instruct our servers to forward packets from the server exit-IP:port to your VPN IP:port. Your physical network card IP ports are never involved in the process, they are totally different end-points (with some approximation, imagine them as a completely separate "set of ports"). On your physical network card IP address, there's only one random port used as an end-point of OpenVPN. All the traffic in your physical network card flows from/to one single port to/from one single port. Only after the incoming packets are inside your system, the underlying packets headers and payloads are decrypted, and that's when the "real end-points" (i.e. the "set of ports" of the tun adapter, the physical network card used by OpenVPN) are revealed so that they can uniquely identify a process in your system. Analogously outgoing packets are encrypted BEFORE they transit through your physical network cards and encapsulated by OpenVPN (in UDP or TCP according to the mode you have picked). Again, please make sure that your system is tunneling properly. If in doubt please feel free to send us your OpenVPN logs, your routing table (printed after a connection to a VPN server has been allegedly established) and also perform the following test: http://checkmytorrentip.com Kind regards

Hello, it's unclear, can you please elaborate? Real origin and destination ports are not visible to your system administrators and above all not blockable: since the ports are forwarded remotely on our servers, your network administrators are impotent to interfere with them. All they can see is traffic to/from one single port (the VPN server port your OpenVPN connects to: 53, 80, 443 or 2018) and one single IP address (the entry-IP address of the VPN server your OpenVPN connects to). What they can try to do is study your bandwidth pattern. BitTorrent traffic can have an identifiable up/down pattern if your data exchange pertains exclusively to a torrent client (but it's not a proof of anything, of course). Also, please make sure that your computer is really connected to a VPN server and that you do NOT forward (this is very important) ports on your router (there's an exception to this: when OpenVPN runs on the router itself). Kind regards

Hello! We're very glad to inform you that a new 100 Mbit/s server located in India is available: Izar. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Izar supports OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Please note that the datacenter housing this server has one of the best alleged peering in India. However, during our tests the server seemed intermittently unable to meet AirVPN quality requirements on bandwidth. We have decided to make it available because we have been unable to find any better data center in India and because this server could be useful anyway for our customers from India and nearby countries. Should the server network be unable to meet the quality standards AirVPN customers are used to, we are ready to withdraw Izar. Therefore, please do not hesitate to send us your feedback. Kind regards and datalove AirVPN Team

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the USA is available: Alkaid. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Alkaid supports OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! We inform you that Netherlands server Corvi will be put offline on 1 AM GMT+1 Oct-22-2013 to perform ordinary maintenance and a range of tests. Please note that all the VPN clients connected to the server will be forcefully disconnected. Kind regards

Hello! Your setup list appears to be correct. Step 4 appears superfluous as Linux does not suffer DNS leaks (please see also the How-To guide https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf ). Kind regards

@retiredpilot Hello, the three IP addresses you cite are all valid and point to three different frontend servers. You can access whichever you prefer, they are on sync in real time. Kind regards

Hello! CBC Canada is NOT accessible from any of our servers at the moment. Kind regards

Hello! It's the network adapter whose name starts with label "TAP-Win32 ..." Please note: just in case you see that the adapter is already enabled, please right-click and select "Disable" anyway, then select "Enable" again. This will cause an adapter reset and should fix the problem. Kind regards

Hello! As we have already told you, this is not what we experience, not even with reboots of the device in different networks (assuming of course that openvpn-connect is never shut down or put on "Disconnect" status). Are you sure that you have leaks when you change network? If so, maybe you have discovered a previously undetected openvpn-connect bug that you might like to report. In this case, here's an immediate work-around: 1) set your device DNS to VPN DNS IP addresses (10.4.0.1 etc.) https://airvpn.org/specs 2) use only configuration files which include IP addresses and not names (tick "Advanced Options" in the Configuration Generator, then tick "Resolved hosts in .ovpn files" and "All servers for area or region"). In this way your device will not be able to resolve any name until it's in the private network, while maintaining the ability to connect to any VPN server, preventing therefore leaks to all services that need DNS resolution (all of the services which you cited). Kind regards