Staff

Hello! Thank you for your nice words, they are much appreciated. You don't need to configure your torrent client, just make sure to launch it after your computer has connected to the VPN. Additionally, you might like to secure your connection against leaks in case of unexpected VPN disconnection. Please refer to the guides that are permanently linked on the announcements section of the forum, according to your system. Kind regards

Hello! It's a problem on your browser. SSL/TLS supports AES-256 and very many other ciphers. Just check your browser security settings and force it to use AES, or at least disable RC4. Our web servers fully support all the most important and secure ciphers including AES (128, 192, 256...). Kind regards

@Mistergigahertz Can you please make sure that ipfw is running and applying the correct rules? Kind regards

@Miramis Hello! The logs appear just fine. Can you please send us the output of the commands (issued from a command prompt) "ipconfig /all" and "route print" after the connection to a VPN server is established? Kind regards

Hello! For the thread readers, please keep in mind that with the above solution you will not be able to tunnel transparently everything over TOR so you will have to specifically configure applications to be tunneled over TOR. On top of that and more importantly remember that as usual you will not be able to tunnel UDP over TOR, while with OpenVPN over TOR you obviously can transparently tunnel everything, including UDP, over OpenVPN over TOR. Finally and perhaps MOST importantly, with the above solution you can be trapped and tracked by a malicious TOR exit node. Therefore just plan carefully which partition of trust best suits your needs. Kind regards

Hello! Unfortunately we can't read your new global rules, can you please send a bigger image? You can safely do that, file size limit is 1024 KB. Kind regards

Hello! That's very strange. Probably we're missing something here. Unfortunately none of us is in the UK. Is there any TalkTalk customer with an average/high technical knowledge here who would like to perform tests? Kind regards

Hello! From the client logs, apparently you did not follow step 12 of the guide: 12) In order to allow "airvpn.org" resolution even when disconnected (and any other hostname you wish to be resolved even when VPN is disconnected), add to your hosts file the line 85.17.207.151 airvpn.org Kind regards

Hello! Please perform this test: http://checkmytorrentip.com/ If successful (i.e. you can't see your real IP address), it's easy to saturate your download bandwidth with an http or ftp download of very large file. ftp will allow you to set bw limits, so that you can progressively share more bandwidth to the p2p client. However, it is not very likely that TalkTalk is applying this desperate and old method (it is dangerous because it is subject to so many false positives that customers could get throttled regardless of what they do - actually we can see that TalkTalk has the highest rate per customers of complaints to Ofcom in the UK for packet shaping reasons...), so there might be different reasons for such p2p bad performance. Kind regards

Hello! Welcome aboard! Assuming that your p2p client is effectively tunneled (please make sure it is) the only way your ISP can guess p2p traffic is analyzing your traffic pattern trying to guess from it whether it's p2p or not. The p2p traffic pattern on a device that uses only a p2p client are typical. This system is quite ineffective and normally was used many years ago only by desperate ISPs which had performed such a massive overselling that they didn't know anymore how to handle congestion (we don't know how far in overselling TalkTalk went). We have studied extensively this system about 10 years ago with a couple of providers, when AirVPN was not even born. The system can be easily fooled by saturating the bandwidth at the beginning of your p2p-ing. Once your p2p client reaches a fairly high bw usage, you should not need anymore to saturate your bandwidth. Kind regards

Hello! No, he/she isn't. You can recognize in the forum messages written by those working for AirVPN because their account is marked in red and (apart from "admin") they sign as "AirVPN" or use the "admin" account. Kind regards

Hello! It's important to secure the connection against leaks in case of unexpected VPN disconnections. Please follow the permanently linked guides in our announcements forum section according to your OS. Kind regards

Hello! We don't keep such logs. Can you please elaborate? Kind regards

Hello! Thank you for your subscription. We have fixed the issue (it appears that you picked a plan that did not match the coupon code plan), can you please try again? Kind regards

Hello! The problem has been fixed, we apologize for the inconvenience. Kind regards

Hello! The upload file size limit is 1024 KB. Your [Home #1] Network Zone is wrongly defined and/or overlaps with AirVPN Network Zone for port 443 UDP. If your home zone is really 10.4.0.0/24 or similar, please let us know and we'll send you a simple solution which will require you to renounce to use port 443 UDP (not a problem). Otherwise, please determine your real home network zone, if you're in doubt please send us the output of the command "ipconfig /all" from a command prompt while you are not connected to the VPN. Kind regards

Hello! Wrong In our post we described how to perform real partition of trust in order to prevent us to track you even if we were "malignant": https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 The key is preventing us to know who you are in every and each case. Of course this is required only if you need to transmit "extremely critical" information. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Romania is available: Phoenicis. 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 "Member Area"->"Access without our client"). The server accepts connections on ports 53, 80 and 443 UDP and TCP. 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 admins

Hello! Yes, definitely. Currently our 2012 downtimes have reached almost 2 hours and 30 minutes (which is anyway fairly good), which are included in our 24 hours grace period. A downtime is considered when a client can't access any VPN server. Kind regards

Hello! They didn't, BUT the server monitor could not show the correct stats. Additionally, new client connections could not be authorized. This problem was already solved in the past. We will let you know whether this has been a new type of incident, in which case we'll take the necessary steps to avoid its recurrence. Kind regards

We have had a major problem on backend servers between 05.09 UTC and 06:12 UTC. We're investigating. We apologize. Kind regards

Hello! It's not a hunting game! The port you have remotely forwarded must match the port your service listens to. After you have started the client, begin the tests. Which client is it? Kind regards

Hello! The forwarded packets to your ports are tunneled like all the rest, so it's not relevant which ports on the router you open or not (but it's important that on the router you do NOT open the same ports that you have remotely forwarded in order to prevent correlation attacks). Once you have remotely forwarded a port or multiple ports, please make sure that the related service is running and listening to the same port(s). Just a question, why did you publish the speedtest? It has nothing to do with the forwarded ports tests. Kind regards

Hello! Can you please make sure that while the test is running your services are running as well and listening to the correct ports? Kind regards

@Anonymous Writer Hello! Thank you for your considerations. We follow closely OpenVPN evolution in available ciphers. ECC is currently not available in stable releases. On the other hand, as you stated RSA-2048 is unbreakable, and we still have the option to evolve certificates toward RSA-4096 for authentication purposes, while standing on AES-256 for the data channel as we do now. Therefore, it might be a mistake to rush toward ECC with a patch. In the best scenario, it would not add significant security in the authentication during these years. In the worst scenario, it may lead to a catastrophe. The wisest choice in our opinion is waiting for ECC full suppport in official OpenVPN releases (2.3, hopefully?), which will allow independent peer-reviews, essential for security. You might like to read this thread: https://forums.openvpn.net/topic8404-45.html Kind regards