Staff

Hello! It means that your system is reachable on your real IP address:port. If you're 100% sure that port 12352 is closed on the router, we'll verify the port checking system, it might be a false positive. You can also check with PortListener: put it to listen to port 12352 on your real IP address, perform a port check from the web site panel, and look whether any incoming packet is detected. https://airvpn.org/topic/9315-port-forwarding-tester/ We're looking forward to hearing from you. Kind regards

Hello, you can safely discard the TLS re-keying as a potential cause because it is performed with over-lapping windows, there's no time pressure and performance difference is not humanly detectable. At the moment we can't reproduce the issue with Chrome. Does it happen to you on some particular server, or on all servers? Does it occur with Chrome or with all browsers? Is it the same if you disable all Chrome add-ons/plug-ins (if you have any)? Kind regards

Hello! In the last 6 months we have been able to provide even more bandwidth per client with the addition of many servers, so the problem is not in our infrastructure. As a first test, you should try connections to different ports to verify whether your ISP has started port shaping. Kind regards

Hello! So it must be something specific in that computer. Do you notice, on this computer, any problem with SSL certificates/keys (https sites not connecting, SMTP over SSL/TLS...)? Kind regards

Hello! Apparently there's some new trick from BBC. Investigation goes on. Please connect to UK servers in the meantime. Kind regards

Hello, something (it might seem Verizon itself from the traceroute, but that "General Failure" leaves room to doubts) is blocking TCP packets to 85.17.207.151 (our third frontend server), but not ICMP. Try to delete in your hosts file the line: 85.17.207.151 airvpn.org and replace it with the lines: 212.117.180.25 airvpn.org 95.211.138.143 airvpn.org If you're running a firewall that is configured to secure your connection to the VPN, make sure you adjust its rules according to the aforementioned IP addresses. Kind regards

Hello! About screenshots, please see the instructions. About the error message, make sure that you don't run multiple services listening to the same port. Kind regards

Hello! Thank you for your report, we're investigating. Kind regards

Hello! On the non-working laptop, please re-try with both firewall and antivirus disabled, just in case one of the two (or both) are blocking airvpn.exe. Also, from the same laptop, please open a command prompt and send us the output of the following commands: tracert airvpn.org ping airvpn.org Kind regards

Hello, that's the ultimate proof that port forwarding works just fine and that you don't have firewall problems. When you turn off PortListener and you re-perform the check, either you don't run the service meant to listen to the same port, or this service is not listening to the correct port, please check. Kind regards

Hello, if the speedtest reports 10 Mbit/s, how do you infer 300 kbit/s? Kind regards

Hello! That's totally correct. Yes, you're right, setting anyway the rules for Vuze is a much better suggestion. Kind regards

Hello, we can't confirm what PayPal told you, we have already tried to pay with different credit cards (VISA and MasterCard) and the payments go through fine. Kind regards

Hello! Start the PortListener while your system is connected to the VPN and make it listen to your TUN/TAP interface IP address (it will be something beginning with 10...), port . Then log in the web site and start the port check on that port. Look at the PortListener and check whether any packet comes in. If not, disable your firewall and repeat the test. Feel free to let us know the results. Kind regards

Hello! Port forwarding is working just fine. Is your service running AND listening to the correct port while you perform the test? If in doubt, use our PortListener tool to perform test: https://airvpn.org/topic/9315-port-forwarding-tester Kind regards

Hello, it's normal that you get higher performance over UDP. Try also different servers and different ports (in particular 53 UDP, just in case your ISP shapes outbound port 443 UDP) in order to determine the server that can give you the best performance. Since you get 3-5 Mbit/s with internal speedtest (which is performed on the server itself) the alleged 300 kbit/s bandwidth does not seem a problem between your ISP and the server. Kind regards

Hello! Please send us at your convenience the client logs after the problem occurs. Please right-click on the Air client dock icon, select "Logs", click "Copy to clipboard" and paste in your message. Kind regards

Hello! Can you please send us the Tunnelblick logs after the problem occurs? TCP and UDP are both supported and there's no significant difference between them under a security point of view. Please see also the FAQ https://airvpn.org/topic/9162-what-is-the-difference-between-tcp-and-udp-ports-which-port-should-i-choose Kind regards

This is what I do. And I thought I indicated this in the guide. Is it not clear? I will try to emphasize this when I next look at it. Hi, no problems, it's very clear! It was just re-stressed to suggest (not that it must be a good suggestion, it's just brainstorming) that maybe an ultra-quick solution (for Vuze inexperienced users only) that does not imply firewall settings and scripts could be welcome by someone who wishes to split traffic and secure the tunnel exclusively on a "torrent and non-torrent traffic" basis.However, the issue of tracker names resolution via DNS was overlooked, it was silently assumed that Vuze would work with DHT[+PEX], in a "trackerless mode". At a first glance and according to this writer, it is not a privacy/security concern. It is anyway to be considered, under a general point of view, that not using Air DNS servers will prevent usage of our anti-geo-location block system (for example to access Hulu from non-USA servers), which might be an inconvenience for those who rely on that, so it is good that the issue, for any possible case in which Air DNS servers are not used, is explicitly cited. Kind regards

Hello! Impressively detailed guide, rich of information on related topics, thank you! You might also like to include an alternative solution in part 2, much quicker, specific to Vuze (uTorrent lacks the bind to an interface option): insert "route-nopull" directive in the .ovpn configuration file (insert the line anywhere before the certificates and key)bind Vuze to the tun/tap adapter (menu "Tools"->"Options"->"Mode"->"Advanced"->"Connection->"Advanced connection settings" as showed in your screenshot) route-nopull tells the OpenVPN client to reject the routing table pushed by the OpenVPN server, while preserving the DHCP-push for the TUN/TAP adapter, making it ready to be "used" by applications bound to it. This solution has the advantage to take just a few seconds once and for all, it does not require scripts and firewall rules, but it has the disadvantage that it is applicable only with Vuze and that can't currently be achieved with the Air client for Windows. You'll need to use OpenVPN GUI or OpenVPN directly to connect to a VPN server with the "route-nopull" directive. The Configuration Generator has the ability to generate such configuration files. Kind regards

Hello! Please see also here: https://airvpn.org/topic/9487-the-underlying-connection-was-closed/ Kind regards

@g4life666 Hello, please send us at your convenience the commands you enter and their output. Kind regards

Hello! Run a command prompt with administrator privileges and type the command: notepad C:\Windows\system32\drivers\etc\hosts Edit the file, then save it. In case of any doubt, stop and send us the content of the hosts file (just copy from the notepad and paste here). Kind regards

Hello! Please check your hosts file. The entries of airvpn.org resolution must be either missing, or the following two: 95.211.138.143 airvpn.org 212.117.180.25 airvpn.org Make sure that no reference to 85.17.207.151 is there. Kind regards

Hello, first of all you should take note that the first three trackers you cite are no more working in http since a long ago, they only work in udp (for a very good reason). Actually, apart from the fact that using a tracker does not make any sense except for very special needs, there is not much sense in running an http tracker, due to efficiency reasons. We have checked the three trackers you reported as non-working in your first message right now (BUT in udp, of course) and we confirm they are perfectly reachable and working from Virginis. About "fr33dom" we don't know if it's still available in http, anyway an udp check was fully successful. It might be that the tracker is temporarily unavailable in http, or maybe it does not support http anymore, we don't know. The problem is therefore non-existent, we mark this thread solved but do not hesitate to contact us for any further information or issue. Kind regards