Staff

Hello! If you have any problem, please submit a help request with the "Contact us" form, attaching the following data: - your network zones - your global rules - your application rules - Comodo Firewall events logs - your client logs Kind regards

Hello! There's been some problem with the editing of the original message. Here it is: Hello! The main reason is that our servers (and any other OpenVPN server, if properly configured) rewrite the packets header before sending them out. The real-IP address of the client is nowhere in the packet. The peers and the tracker (if any) will see the VPN server exit-IP address. Please note that one of the problems underlined in the linked article refers to the fact that torrent clients ignore, when they wish, proxy configuration (therefore TOR proxy too). A proxy is completely different from OpenVPN: it does not modify the kernel routing table, it does not use a separate network card, it does not let you enter a virtual private network. So the first issue underlined in the linked article is irrelevant for OpenVPN. The second issue underlined in the article regards the alleged "announce" to other peers of the IP address seen by the torrent client. In this case the IP address is inside the packets. If a proxy is used, the torrent client will read the real IP address of the user. With OpenVPN, it will read the VPN IP address. So, even the second issue is not a problem for OpenVPN. Some torrent clients (for example rtorrent) allow to set the IP address to be "announced" to the DHT. Of course if you type in the field your real IP address, OpenVPN can't protect you. However, it remains to be seen how this data can be a "proof" if gathered by some copyright troll/clown. What if users put in that field the RIAA IP addresses? This problem, as well as many others, have been thoroughly investigated by the University of Washington, in the amazing paper "Tracking the Trackers: Why My Printer Received A DMCA Takedown Notice". It is a huge problem for deranged copyright fundamentalists and similar dregs, because a technically aware (and not corrupted) court will immediately see that those data are not a proof and not even a hint, because they can be fabricated by anyone and under all the cases described in the paper. Of course nowadays there are less, but much more expensive and therefore not viable for most copyright clowns, rudimentary p2p swarm monitoring techniques. The third issue ("the second attack" according to the TOR project article) refers to a type of correlation attack which is impossible on our VPN, for the above considerations. But there are more elaborated correlation attack techniques that the article fails to explain. These techniques cannot be successful because AirVPN servers, contrarily to all the other VPNs, as far as we know, have different entry-IP and exit-IP addresses. It's important, however, that you don't forward on your router the same ports used by your services, in order to prevent correlation attacks EVEN to an adversary who has the ability to monitor your line. The fourth issue ("the third attack") underlined in the article is irrelevant for OpenVPN, it refers to a TOR "vulnerability" when a torrent client and a browser, both over TOR, are used simultaneously. This issue does not affect OpenVPN (for trivial reasons) or OpenVPN over TOR (simply because the TOR exit node sees encrypted by OpenVPN traffic and does not know anything about ports, protocols, contents, real origin and real destinations of the packets - it just sees all the encrypted traffic to/from one of our shared entry-IP addresses, rendering impossible to build any user snapshot). A more serious problem is whether an application can bypass the routing table and send out packets from your physical interface, therefore exposing the real IP address even with OpenVPN client connected and running properly. In order to do that, applications must run with root/administrator privileges or be specifically configured by root to bind to the physical interface. Every computer user should be well aware of any application which can run with root/administrator privileges: as you know, a VPN does not secure your computer and should not be meant as an antimalware tool. ANYWAY, a firewall that is configured to secure the connection against leaks in case of unexpected VPN disconnection will also prevent such applications to leak data. This is another reason for which we recommend to set firewall rules in order to secure the connection and not to rely on programs which "kill" the connection or a list of applications if they detect a VPN disconnection. These kind of programs can give a totally false sense of security. ======= Some digressions: An even more serious problem is caused by malignant software (spyware) which reads all kind of data (the list of your network cards, the files you have on the HDD and send out those data to a remote server, via a browser or a program which is not blocked by the firewall, for future human analysis. Such malware does exist and it is used to steal data of any kind or disclose the identity of someone suspected of serious crimes by competent authorities. It is also used by human rights hostile countries to monitor "suspect" people. The first defense against these threats is renouncing to use Windows. If a person in hostile environments is compelled to use Windows, for lack of knowledge for example, it is highly recommended that he/she uses a series of precautions that are viable with a relatively low degree of information: - use Comodo with Defense+ set to "Paranoid Mode" - encrypt the whole HDD and keep the computer OFF when it is unattended. This will prevent spyware injection from strangers even if they boot from an external device (USB, CD, DVD). TrueCrypt allows to encrypt entire volumes (including boot partition) easily - keep sensitive data in Linux or *BSD Virtual Machines with encrypted virtual HDD. VirtualBox enables to create Virtual Machines even to "not skilled" people. - when access to data is necessary, their decryption is performed only in a safe environment: in a VM with carefully monitored connections, plain text displayed with anti-Tempest fonts and on low emissions monitors (or, for those who have access to it, on TEMPEST-certified equipment) in order to prevent Tempest attacks, no network connection until necessary, data first heavily encrypted (gpg, AES-256, AES over TwoFish or Serpent with 768-bit keys size, etc.) then sent out via a VPN (exclusively based on OpenVPN or IPsec, never PPTP) over TOR, or TOR over a VPN, or any other chaining which allows partition of trust - if a browser has to be used, no scripts must be allowed to run (no javascript, no Flash, no Java, no plugins). Aurora in the TOR browser bundle does that by default The potential Windows victim should also use common-sense precautions, for example never insert on a Windows system an unknown USB key. A very old and common method for a first-stage attack: the attacker leaves an attractive 32/64 GB USB key (20 years ago it was done with floppy disks, although a ZDNet journalist writes as if she never heard about it before) where she is sure the victim will find it and hopefully will insert it in his/her or company's computer. If the computer's victim has AutoRun enabled and Defense+ not set in "Paranoid Mode", the first stage attack is successful. Foreseeing that the victim might have AutoRun disabled (in line with Windows total-insecurity-style, the AutoRun is on by default) or some program like Defense+ blocking it, the attacker also stores a lot of fascinating "infected" files in the key (from porn movies to attractive applications, from Flash programs to Java applets) in the hope that the victim will not resist to the temptation to run one of them. Some readings: http://www.zdnet.com/criminals-push-malware-by-losing-usb-sticks-in-parking-lots-7000000729 http://en.wikipedia.org/wiki/Tempest_attack http://blogs.computerworld.com/security/20816/gauss-malware-nation-state-cyber-espionage-banking-trojan-related-flame-stuxnet The sublime paper "Tracking the Trackers": https://dmca.cs.washington.edu Enough for the digressions... Kind regards

Hello! The previous message might have been misunderstood and a clarification is due. A judge with proper jurisdiction who serves us a valid warrant/subpoena is surely a competent authority. A USA federal agent who tells us that [aid to] a violation of human rights is performed via our servers is not, but we reserve the right to investigate further anyway, according to our ToS. In case we decide to investigate, that the results of our investigation will be handed over to him/her is a completely different matter. Being bound to our contract with you and to EU acquis, this will not happen, instead the proper EU authorities can be warned by ourselves, even in order to identify the person committing the act (we can't do that) in the cases reported in our ToS: [aid to] violations of the ECHR or usage of our systems with the aim of copyright enforcement through direct or indirect privacy violations. Kind regards

Hello! The main reason is that our servers (and any other OpenVPN server, if properly configured) rewrite the packets header before sending them out. The real-IP address of the client is nowhere in the packet. The peers and the tracker (if any) will see the VPN server exit-IP address. Please note that one of the problems underlined in the linked article refers to the fact that torrent clients ignore, when they wish, proxy configuration (therefore TOR proxy too). A proxy is completely different from OpenVPN: it does not modify the kernel routing table, it does not use a separate network card, it does not let you enter a virtual private network. A more serious problem is whether an application can bypass the routing table and send out packets from your physical interface, therefore exposing the real IP address even with OpenVPN client connected and running properly. In order to do that, applications must run with root/administrator privileges or be specifically configured by root to bind to the physical interface. Every computer user should be well aware of any application which can run with root/administrator privileges: as you know, a VPN does not secure your computer and should not be meant as an antimalware tool. ANYWAY, a firewall that is configured to secure the connection against leaks in case of unexpected VPN disconnection will also prevent such applications to leak data. This is another reason for which we recommend to set firewall rules in order to secure the connection and not to rely on programs which "kill" the connection or a list of applications if they detect a VPN disconnection. These kind of programs can give a totally false sense of security. ======= Some digressions: An even more serious problem is caused by malignant software (spyware) which reads all kind of data (the list of your network cards, the files you have on the HDD, screenshots of your monitor...) and send out those data to a remote server, via a browser or a program which is not blocked by the firewall, for future human analysis. Such malware does exist and it is used to steal data of any kind or disclose the identity of someone suspected of serious crimes by competent authorities. It is also used by human rights hostile countries to monitor "suspect" people. The first defense against these threats is renouncing to use Windows and Mac. If a person in hostile environments is compelled to use Windows, for lack of knowledge for example, it is highly recommended that he/she uses a series of precautions that are viable with a relatively low degree of information: - use Comodo with Defense+ set to "Paranoid Mode" - encrypt the whole HDD and keep the computer OFF when it is unattended. This will prevent spyware injection from strangers even if they boot from an external device (USB, CD, DVD). TrueCrypt allows to encrypt entire volumes (including boot partition) easily - keep sensitive data in Linux or *BSD Virtual Machines with encrypted virtual HDD. VirtualBox enables to create Virtual Machines even to "not skilled" people. -when access to data is necessary, their decryption is performed only in a safe environment: in a VM with carefully monitored connections, plain text displayed with anti-Tempest fonts and on low emissions monitors in order to prevent Tempest attacks, no network connection until necessary, data first heavily encrypted (gpg, AES-256, AES over TwoFish or Serpent with 768-bit keys size, etc.) then sent out via a VPN (exclusively based on OpenVPN or IPsec, never PPTP) over TOR, or TOR over a VPN, or any other chaining which allows partition of trust - if a browser has to be used, no scripts must be allowed to run (no javascript, no Flash, no Java, no plugins). Aurora in the TOR browser bundle does that by default The potential Windows victim should also use common-sense precautions, for example never insert on a Windows system an unknown USB key. A very old and common method for a first-stage attack: the attacker leaves an attractive 32/64 GB USB key (20 years ago it was done with floppy disks, although a ZDNet journalist writes as if she never heard about it before) where she is sure the victim will find it and hopefully will insert it in his/her or company's computer. If the computer's victim has AutoRun enabled and Defense+ not set in "Paranoid Mode", the first stage attack is successful. Foreseeing that the victim might have AutoRun disabled (in line with Windows total-insecurity-style, the AutoRun is on by default) or some program like Defense+ blocking it, the attacker also stores a lot of fascinating "infected" files in the key (from porn movies to attractive applications, from Flash programs to Java applets) in the hope that the victim will not resist to the temptation to run one of them. Some non-technical readings: http://www.zdnet.com/criminals-push-malware-by-losing-usb-sticks-in-parking-lots-7000000729/ http://en.wikipedia.org/wiki/Tempest_attack http://blogs.computerworld.com/security/20816/gauss-malware-nation-state-cyber-espionage-banking-trojan-related-flame-stuxnet Enough for the digressions... Kind regards

Hello! Of course, in this case there's nothing to be worried about when using OpenVPN. We provide VPN services, not a proxy service or a junk PPTP VPN service. OpenVPN is also immune to the infamous PPTP IPv6 vulnerability discovered some time ago with torrent clients. If you read carefully the beautiful article you linked, you'll see why uTorrent, Vuze or any other torrent client can't stamp your real IP address on the packets sent to other peers and trackers (unless they run with root privileges and act like a malware, of course, or you, as root, deliberately bind them to your physical card, but that's another story completely). Keep in mind that OpenVPN uses a TUN/TAP network card, that our servers push routes accordingly and that our system NEVER forwards a port that you did not explicitly instructed it to do. It's important to note that the article hints also to some potential correlation attacks that we decided to take into consideration a long time ago. That's one of the reasons for which in Air servers, contrarily to what happens on any other VPN as far as we know, you have separate entry and exit-IP addresses, and for which we repeatedly recommended that you never forward on your routers the same ports used by your applications when you're connected to the VPN. Kind regards

Hello! 1. The pushed DNS is inside our VPN, in order to bypass ICE censorship. Only after a first resolution attempt (necessary to bypass ICE censorship, which of course propagates to all DNS in the world) the DNS query is anonymized and goes out from our servers to Google DNS, which is one of the few DNS systems in the world without censorship. Usage of OpenDNS is not viable for us because we don't accept the censorship perpetrated by OpenDNS and its NN violations. In the past we used our own DNS, but this new system provides significant advantages. 2. If you don't want to install a firewall to prevent DNS leaks, you might either renounce to use Windows or, alternatively, set your favorite DNS servers (as primary and secondary) and apply the manual method reported here: http://www.dnsleaktest.com/how-to-fix-a-dns-leak.php Kind regards

Hello! Castor will undergo a major maintenance starting on 2012 August 22nd 11:30 AM (CET+1). We will need to disconnect all the clients during the maintenance. Castor users are advised to change server before the maintenance start in order to avoid forced disconnections. We currently provide the following servers in the Netherlands, in addition to Castor: Leonis, Leporis (1 Gbit/s), Lyra, Orionis. At the end of the maintenance Castor will come back online and will be visible again on the servers list. Kind regards

Uhm... thank you for the information, it's a problem on our side, Kunena does not show those buttons anymore, we did not see the issue (probably because of browsers cache), we'll look into this asap. Kind regards

Hello! First of all, try a connection to a TCP port, just in case you're connecting to UDP ports and your ISP caps some or all UDP ports (several ISPs do that). Please see our FAQ in order to optimize p2p performance as well: https://airvpn.org/faq Kind regards

Hello! You can switch servers (and ports) as many times as you wish and whenever you want. Yes. Please read the FAQ available here: https://airvpn.org/faq DNS queries are encrypted and tunneled by OpenVPN (see DNS leaks, though, if you use Windows, and how to fix them). Our OpenVPN servers perform a DNS push, however you'll remain free to force your system to use any other DNS. Please see here: https://airvpn.org/specs Kind regards

Hello! Draconis is up and running again. The problem was caused by a flood attack from some adversary with good resources. Kind regards

Hello! At the time of your writing and at the time of this writing the account "geeknurse" is REALLY connected and is exchanging data successfully. Did you give your personal key to anyone? Kind regards

Hello! In order to display and copy the logs in the Air client, please right-click on its dock icon and select "Logs". A window will open showing the logs. Click on "Copy to clipboard" then paste in the message. Since you have no problems with Viscosity, perhaps the "Failed to start" error is caused by a corrupt configuration file, in which case you can safely delete it after you close the client (you can find the path and the name of the .xml configuration file in the logs). The Air client will re-create the configuration at the next run. Kind regards

Hello! "Failed to start" and "Already connected" show two different conditions. Can you please send us the logs? Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the Netherlands is available: Leporis. 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/certificate/key generator (menu "Member Area"->"Access without our client"). The server accepts connections on port 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! The testing will end on August 19th, Sunday night (Central European Time). After that, we'll schedule the upgrade for all servers. Some servers will require disconnection of all users (restarting OpenVPN) so in that case you will be warned at least 48 hours in advance. Kind regards

Hello! It's in the path specified in the logs. Assuming (this is just an example, your path will be different of course) it is C:\Users\johndoe\AppData\Roaming\AirVPN\Air\1.0.0.0\, just browse with the window manager or cd with the command prompt to that directory and delete AirVPN.xml. Kind regards

Hello! We're very sorry, we still don't know. We need a cold reboot (ssh access is ineffective again). We don't have option to cold reboot the machine from remote. We hope it's not some hardware fault which periodically (2 times this week...) causes a complete crash of the machine. The apparent randomness of the crash events have, at the moment, prevented us to discover the real causes. Syslogs are not helpful. We have already contacted the technicians and we hope in a speedy intervention. We will try to speed up our agreements to put online another Sweden server. Kind regards

Hello! We can't do that "ex-ante" (just like any true mere conduit of data), but we reserve the right to do that "ex-post". If a competent authority with competent jurisdiction warns us in any way about usage of our systems in order to perform or aid or abet a violation of ECHR (we are particularly sensitive to human trafficking, human exploitation and privacy violations) we will cooperate "ex-post" with the competent authorities. No. The real IP addresses of those users who are connected at that moment not over TOR would be exposed. The users who are connected over Air over TOR would not be exposed. You might like to look for "partition of trust" in the forum, the following post may give you useful information: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 Kind regards

Hello! You're looking in the right place. The line you wish to find is something similar to: Reading options from [...]\Users\[...]\AppData\Roaming\AirVPN\Air\1.0.0.0\AirVPN.xml It appears on the top, just after the initialization. When you have located it, close the Air client and delete the file "AirVPN.xml". When you launch the client again, it will re-create the XML (you will have to re-insert your login name). Kind regards

Hello! In order to determine whether it's a client or a server side problem, can you please try to connect to Orionis or Leonis or Bootis, and try frequent disconnections and re-connections? Those three servers implement a new system which is designed to fix your kind of problem. We're looking forward to hearing from you. Kind regards

Hello! Unfortunately we experienced a down on the backend servers for approximately 1 hour which prevented authorizations and front end access. Already connected users were not disconnected. The problem has been detected and fixed, we apologize for any inconvenience. Kind regards

Hello! Very glad to know that you managed to solve the problem. EDIT: it was not meant that you should run uTorrent with administrator privileges, quite the contrary. Excellent! Although we could never observe uTP to cause leaks with OpenVPN, keep in mind that it is designed (also) to pass through NATs and firewalls. As a (maybe excessive) precaution, it's better to keep it off when connected to a VPN. We allow port forwarding and we don't shape traffic, so you should not need uTP at all. Thank you very much for the feedback. The new system is implemented in Orionis and Bootis as well. Just a few more testing days and we'll proceed to install it on every server. Moreover, stay tuned for some very good news in the next days and in the next weeks! Kind regards

Hello! We can't say for sure, there are very many problems with Virgo left unsolved and we are not willing to cooperate with the provider. It's up to the provider to solve those problems, if they can't do it then we will transfer Virgo. In the meantime 2 Gbit/s for UK are 10 times the average bandwidth request. Kind regards

Hello! Ok, uTorrent 2.2.1 is just fine and we are testing the very same version. Currently we can't reproduce the problem in any way. Does it happen on every server or only on some servers? Is uTP disabled? Can you give us the uTorrent configuration so that we can mimic it for our tests? What is your exact Windows version? Kind regards