Staff

Hello! For Windows and Comodo, please follow this guide: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards

Hello! Please: - forward a TCP & UDP port - do not remap it to any local port - configure uTorrent to listen to the above port number - make sure to start uTorrent AFTER you have connected to the VPN Kind regards

Hello! No problems are detected on any UDP port on any server. Kind regards

Hello! Please ask them through the "Contact us" form (or find them with the configuration generator). Kind regards

Hello! Can you please send us your client logs? Kind regards

Hello! The problem is that you remapped a remotely forwarded port to a different local port. This is a special case where a local port remapping can not work, because the swarm will try to reach the p2p client on the local port instead of the remotely forwarded "public" port. Please forward a port and do not remap it to a local port. Then set your uTorrent to listen to the same remotely forwarded port. Finally make sure that the option to randomize the listening port every time uTorrent runs is not active. Kind regards

Hello! It does not disappear, on the contrary thank you very much for the very nice guide! It can be read by anyone here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=2&id=6652&Itemid=142#6652 Each time you edit it a moderator must approve it again, this may be the reason for which after an editing you can't see it for a little while. Some delay for the approval was due to the advertising of the image hoster reported in the screenshots (ads are forbidden in the forum) but it was decided to publish it anyway. We will also evaluate to put it in the "Enter" pages for Tomato. Also, apparently Tomato works better than DD-WRT. Thank you again. Kind regards

Hello! Despite the reports you cite, perhaps your firmware version is bugged. The following version has been reported as working for Linksys E4200: dd-wrt.v24-18774_NEWD-2_K2.6_openvpn.bin Before re-flashing, please make sure that your second router is working in bridge mode (only if the DD-WRT router is behind your second router and the second router connects to your ISP). Kind regards

Hello! We're glad to inform you that a new feature aimed to locate easily a sequential range of free ports has been added on the port forwarding panel. Now you can ask the system to locate for you a range of contiguous ports if you need them. You can also watch a graph which reports free (in green color) and allocated ports (in red). Furthermore, the port random allocation algorithm has been improved in order to rationalize the forwarded ports assignments. Please remember that if your account subscription is kept expired for more than 10 days, the reserved ports for it will be released. Kind regards

Hello! Please set correctly the date and time of your DD-WRT router. In 1970 the certificates were not valid. Unfortunately, while the above needs to be fixed (otherwise TLS negotiation will always fail), it does not seem to be the real root of your problem. If the problem persists, you have a bugged firmware, please see here: http://svn.dd-wrt.com/ticket/2536 Kind regards

Hello! If you wish to make the ssh daemon reachable from the Internet outside the tunnel, you need to bind it to the physical server interface (for example eth0). On the contrary, if you wish to run the ssh daemon behind the VPN, just forward remotely a port on our system and make sshd listen to that port on your tun interface. Your sshd will be reachable from the Internet on : Kind regards

Hello! Unfortunately the symptoms strongly suggest that your computer is compromised. First of all, please check thoroughly for malware. It's also absolutely necessary that you determine which task(s)/process(es) are causing the bandwidth spikes and cause your loss of control of your own system: it's likely that there you will find the malignant program(s). To monitor your packets try with Wireshark: http://www.wireshark.org Kind regards

Hello! Thank you for your subscription! The pushed routing table and default gateway by our OpenVPN servers force all the client traffic to be tunneled. The only way to escape this behavior are programs that take control of the system with administrator (root) privileges and bind to the "wrong" interface. Does your MMO game client pretends to run with high privileges? You can check the traffic flowing in your machine with programs like Wireshark (very powerful) or the network activity monitor (a limited tool, but good for your purpose) of the Comodo firewall. If you find that your game client takes control of your system and overrides your system routing table you might try to force it to bind to the TUN adapter (in Windows TAP-Win32 Adapter V9...) with this code/DLL injector: http://www.r1ch.net/stuff/forcebindip In general, programs which behave in that way should be considered near to malware (overriding a system routing table without the system owner explicit authorization may be a very dangerous operation in a lot of countries and anyway it is an unacceptable violation of the system security) and customers of such programs, in our opinion, should contact the software house and pretend that the problem is solved. Kind regards

Hello! Thank you, glad to know the problem is solved. Currently OpenVPN 2.3 is just in a "Release Candidate" state, so we recommend it only when OpenVPN 2.2.2 (latest stable release) fails. We have some reports according to which OpenVPN 2.2.2 has (rare) issues with Windows 8 64 bit, so Win 8 users may consider seriously OpenVPN 2.3 even if it is just a RC. Just for the records, can you please publish what your exact Windows OS version is? Kind regards

Hello! The problem is that the tun interface (TAP-Win32 Adapter) does not come up. Please make sure that the DHCP service is enabled in your system for the TAP-Win32 interface. If the problem persists please try to reboot. If the problem persists after a reboot please: - uninstall completely OpenVPN - install OpenVPN 2.3_rc2 making sure that you authorize the installer to install all the drivers You can download OpenVPN 2.3_rc2 here: http://openvpn.net/index.php/open-source/downloads.html Kind regards

Hello! Thank you for your subscription! Can you please send us your Air client logs? After a connection attempt, please right-click on the dock icon (a white cloud on a blue sky), select "Logs" and click on "Copy to clipboard", then paste in the forum. Kind regards

Hello! You can use pf which is included by default in Mac OS X 10.7.x. Thanks to jessez the guide is available here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=36&Itemid=142#2532 Kind regards

Hello! We're sorry, we can't read anything on the image. Can you please re-send at higher resolution? Kind regards

Hello! Can you please check for malware in your system? Also, can you please send us the connection logs? Kind regards

Hello! If you don't have the resolvconf package installed you can just add the line: nameserver 10.4.0.1 at the top of your /etc/resolv.conf file (if you wish to use the Air DNS). That's because your OpenVPN client can't handle the DNS push from the OpenVPN server. You just need to modify it once and for all. Kind regards

Hello! Apparently the SOCKS proxy OpenVPN is trying to connect to does not answer properly. Can you please make sure that the proxy type set in the Air client (socks or http) matches the type of the proxy you're running and that you have selected a TCP port? Also, can you connect successfully to a VPN server without connecting over your proxy? Kind regards

Hello! It's very difficult to explain the above. The first thing that comes to mind is that there are some routing problems between your ISP and Pavonis. Do you see any packet loss with Pavonis (check your client logs after you have been connected to Pavonis for several minutes and check whether there are "Replay-window backtrack occurred" entries)? Does that bad p2p performance occur with some other US server? Do you run programs like PeerGuardian and PeerBlock? Kind regards

Hello! 46.105.19.36 was dismissed several months ago. Now everything is back to normal, both frontend1 and frontend2 (85.17.207.151) are working just fine. The main frontend (currently 212.117.180.25) is the airvpn.org "official" DNS resolution. In case of emergency we can switch DNS. The problem with the secondary frontend occurred in a very unfavorable time frame (exactly 13 minutes before the midnight between 31 Dec 2012 and 01 Jan 2013 in our and datacenter local time) and although we warned immediately the datacenter technicians it took several hours to be solved. Happy New Year to everybody! Kind regards

Hello! We apologize for the inconvenience, it's a problem on our side: our secondary frontend 85.17.207.151 went down for datacenter problems during the new year's day night. Technicians in the datacenter have been warned immediately, just a few minutes after the down, and are currently working to solve the issue. In the meantime, you can use our primary frontend, just modify the line in your hosts file in this way: 212.117.180.25 airvpn.org Thank you for your patience. Kind regards

Hello! Apparently something is blocking openvpn.exe packets (but not airvpn.exe, otherwise you would not even see the servers list). Do you have any antivirus or any other program running which might interfere? Is your system able to ping the servers IP addresses you're trying to connect to? Kind regards