Staff

Hello! Unknown. Possible explanations: - momentary congestion/packet loss/high latency between your and our ISPs - bad WiFi connection (to rule out if you are cable-connected to your router) - crash/misbehavior of some network card driver (including the TUN/TAP adapter) - misbehavior/crash of your router - a replay attack (https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3773&Itemid=142#3784) If it occurs again please notify us and at the same time try a connection to the same server but on a TCP port, and also to UDP ports of different servers. Kind regards

Hello! We haven't tested the program you cite. Generally speaking, the problems with this approach are: - the time between disconnection detection and program forced kill might allow anyway a leak; about this, you should test carefully the program in order to determine whether it's the case or not - a forced program kill may potentially cause lost or corrupted data, so please be aware of that - contrarily to firewall rules, this approach might not protect you against correlation attacks Kind regards

Hello! Can you please tell us, at your convenience, how the "Authenticate/Decrypt packet error: bad packet ID" problem was solved on your system? Did it disappear by itself or did you do something? Kind regards

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

Hello! Can you please try to connect again and send us the beginning of the logs, before all the packet authentication/decryption errors? For comments about the part of the logs you already sent us, please see here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3773&Itemid=142#3775 and here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3773&Itemid=142#3784 (replay attacks explained) Kind regards

Hello! We're glad to inform you that a string encryption tool is now available to all Air website visitors. The tool allows to exchange encrypted messages on the Air website without letting anyone on the network (not even AirVPN website administrators) see the message, eventually not even the encrypted message. All the encryptions and decryptions are performed by the browsers without sending out any data. On the tool web page you will find all the instructions to use it and an explanation on how it works. The tool is accessible through menu "More"->"String Encryption Tool", direct link https://airvpn.org/encrypt Kind regards and datalove AirVPN admins

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

Hello! We're glad to know that the problem is solved. However the behavior you report is odd. Can you please send us the content of your hosts file and how your system resolves airvpn.org? Thank you for your nice word, they are much appreciated. Kind regards

Hello! A possible explanation is that you were browsing the Air website before you established a VPN connection. Even if you establish a connection while the browser is browsing websites, already established connections to those websites will remain open (that's perfectly normal). Try to run your browser after you have connected to an Air server. Kind regards

Hello! Please feel free to report here any website not accessible from Vega. We're already aware about yahoo.com. Kind regards

Hello! We confirm the issue. There is no block from Vega or from Vega datacenter and the routing is correct. The packets are rejected or dropped somewhere in the piratpartiet network, or by The Pirate Bay itself (perhaps TPB blacklisted Vega exit-IP for some abuse). We will be working to circumvent the block. In the meantime, we kindly ask you to connect to any other server in order to have access to TPB. Kind regards

Hello! You can achieve your purpose with DNATting. Make sure that you have remotely forwarded the ports you wish. Then please add the following iptables rules for each TCP/UDP port you wish to forward: iptables -t nat -I PREROUTING -i -p tcp --dport -j DNAT --to-destination iptables -t nat -I PREROUTING -i -p udp --dport -j DNAT --to-destination where: - is the port number of the port you want to forward to a device - is the IP address (for example 192.168.x.y) of the device you wish to forward packets on that port to - is the TUN/TAP adapter name (for example tun1) Kind regards

Hello! It's the TLS rekeying, an OpenVPN smart feature. You can't increase that time (it should be done on the server side) but you don't need to. It is a nice security feature which does not add any practical overhead. During SSL/TLS rekeying, there is a transition-window parameter that permits overlap between old and new key usage, so there is no time pressure or latency bottleneck during SSL/TLS renegotiations. The main load on the CPU is the encryption/decryption on the data channel, currently AES-256-CBC. We're sorry, we have no plans to lower encryption strength on the data channel. On the contrary, we are evaluating whether to raise it up in the future. A dual core Atom can handle at least 35 Mbit/s throughput with AES-256-CBC, while even old processors (from Athlon64 and newer) should have no problems to handle at least 100 Mbit/s. Low-consumption old CPU on DD-WRT routers can handle up to 7 Mbit/s. Kind regards

Hello! The rules you published are blocking any packet from and to 95.211.169.3, the server you're trying to connect to. In order to allow access to 95.211.169.3 please add the following rules and put them higher than the block rule: Allow IP In/Out From IP 95.211.169.3 To MAC Any Where Protocol Is Any Allow IP In/Out From MAC Any To IP 95.211.169.3 Where Protocol Is Any Also, the airvpn.org IP has changed to 85.17.207.151, please modify it. The Network Zones look fine except perhaps the [Home Network]. Just make sure that in your Home Network the IP range is the one you specified, just in case you need [192.168.0.0 - 192.168.255.255] instead of [192.168.1.1 - 192.168.255.255] (if everything is fine, then you don't need this change). Kind regards

Hello! You need to change firmware and find one which has all the options, otherwise you'll be forced to create scripts in order to connect. For Linksys E2000 the following firmware has been reported by our customers as fully functional and OpenVPN bug-free: dd-wrt.v24-16785_NEWD-2_K2.6_big-e2k-e3k Kind regards

Hello! The 10 Mbit/s is just a bogus number, nothing to be worried about. Anyway, there are actually some limits on Windows, it looks like the TAP-Win32 adapter can't handle more than 160 Mbit/s while on Linux there is no such limitation. Kind regards

Hello! Of course. Please do not hesitate to send us a report which includes all the required data as described here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142#3512 All the data are necessary in order to provide you with proper support. Kind regards

Hello! Clarification: it is meant as the service which should listen to port 22074. It may be a web server, a torrent client, an ftp server, an ssh daemon or any other service which needs to be reached from the Internet on that port. Kind regards

Hello! Not necessarily, it might be that your service is not responding or that some firewall is blocking packets to your service. Can you please check? Kind regards

Hello! You're currently connected to a server which is properly forwarding packets to your account VPN IP address. Actually, your services ARE responding on all the ports you have remotely forwarded except 22076 (which is anyway properly forwarded) and another port remapped to a different local port (which is anyway properly forwarded). Please make sure that the service which should listen to port 22076 is running and really listening to the correct port. Kind regards

Hello! The rules do not appear to be complete in order to prevent any leak AND allow DHCP and communications within your home network and with our servers. Please follow the guidelines in this thread: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 If you have any issue please do not hesitate to send us a report which includes all the required data as described here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142#3512 Kind regards

Hello! Thank you for your choice. Unfortunately Google Checkout for vendors is not available to companies operating in the European Union (with a single exception). We don't process directly credit cards, so we're afraid that if your card is not accepted by PayPal, you'll need to find a different funding method for your PayPal account. Anyway, please make sure that you don't use any proxy or VPN while trying the transaction: PayPal may block any transaction if it detects an IP address geo-located in a country different of your own. Please do not hesitate to contact us for any further information. Kind regards

Hello! So it's a Giganews problem. We will not comment on that at the moment. On our side, connect to one of the following non-Leaseweb servers: Aquarii (Switzerland) [EDIT: NO LONGER AVAILABLE, please use Virginis instead] Geminorum (Switzerland) Herculis (Luxembourg) Serpentis (Sweden) Bootis (United Kingdom) Cassiopeia (United Kingdom) Arietis (USA) Vega (USA) Please feel free to let us know if this fixed the "problem". Kind regards

Hello! Unison is an NNTP client, so it works over a VPN without any particular configuration. Maybe the Unison logs can help shed light on the issue, can you please send them to us? Does any other application connect to the Internet without problems when you're connected to an Air server? Kind regards

Hello! You can find all the relevant information (especially for an FTP server behind a VPN server) here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1700&Itemid=142#1702 Kind regards