Staff

@5o52xwmftthyuq2gmdy6 Hello! The resolv interfaces order is correct. The network-manager logs look fine, please just check that you are running OpenVPN in "client mode" (do you use the configuration file generated by our generator or did you modify it?) and that all the certificates are accessible. Our clients DO require server certificate verification and our servers verify client certificates (double-certificate verification with ca.crt and user.crt so that no MITM is possible). Does the problem occur on Sirius only or on every server? Kind regards

Hello! Can you please send us the total set of your Comodo rules on the machine that has issues? Does something change if you set Comodo firewall security to "Disabled"? Kind regards

Hello! Kernel routing table and network interfaces look ok. You can launch "sudo openvpn" with the --log-append directive to store the logs where you wish. Can you please also send us the content of your /etc/resolv.conf ? Kind regards

Hello! We don't detect this problem on Sirius. Which port do you connect to? Can you please send us the logs, the network cards DNS (if you're on Windows) and the routing table, and check whether there's any difference with other servers? Kind regards

Hello! Yes, the same thing. The difference between "downloading" and "viewing" YouTube video is a big lie, maybe prefabricated by deranged copyright fundamentalists OR, on the contrary, to please them. In order to support the lie, all kind of stuff is in place in an attempt to prevent videos downloads after you have downloaded them. In general it's not possible to discern that. The video file is sent anyway. Retrieving it from your cache or copying it while it's coming down are activities not related to the network. Kind regards

Hello! They have no legal value, nothing changes from what already written. The difference is that they are not take down notices in the strict sense, they are an attempt to steal money via a private settlement. According to how the data have been collected, those notices may also configure a criminal infringement performed by the data collector and eventually by the ISP, if it gave away the personal data of a customer to the claimant in the absence of a magistrate order. For their nature, those notices are aimed to private citizens, in the hope to scare them and make them pay, and are totally irrelevant for mere conduits. Kind regards

Hello! Absolutely normal. Comodo will not define new network zones if an IP address already belongs to a network zone. Ideally, you might have one single network zone for the VPN, with IP range [10.4.0.0 - 10.9.255.255] if you don't want Comodo defines a new network zone for each VPN IP address which is found outside previous network zones. In this way you can keep your Comodo network zones much cleaner, but pay attention if you connect to another network in the same network zone, you might not want the same behavior you have for AirVPN, especially if you are in a public hot-spot subnet. This happens and it's totally normal because our network zone, for each port, have a 255.255.0.0 mask, therefore allowing 65534 different possible IP addresses for clients on each port, while Comodo can't know it, and defines a new zone with a netmask 255.255.255.252. So if your device is DHCP-assigned an IP, say, 10.4.0.45, and the next time (on the same 443 UDP) port) the assigned IP is, for example, 10.4.1.100, Comodo will define a new zone for it, while if you are assigned, say, 10.4.0.46, Comodo has already that network zone defined, no need to create a new one. See also https://airvpn.org/specs Kind regards

Hello! Castor will come back for sure! Kind regards

Hello! Thank you. Just checked YouTube from Leporis and unfortunately you're right, while the access to the website works, the video download is inhibited. It may be an IP problem, yes. Leporis is very young, so chances are that it has been assigned an exit-IP address which caused abuses from the previous "owner". We'll look further into it and investigate YouTube policies to see whether it is possible to apply for IP-block removal. Kind regards

Hello! About EU servers, there is of course neither USA jurisdiction nor USA applicable law. About USA servers, this is a matter exclusively between us and our provider, or between us and the claimant, in no stage our customers are involved. DMCA notices with regard to p2p are allegations from private entities based on non-specified monitoring techniques, so in the worst case they will cause tension between us and our provider and in a worst-worst scenario cancellation of connectivity for our server. This may be not uncommon given the fear that trolls, clowns, fundamentalists and other copyright monstrous parasite creatures strike into some hosting/housing providers, but all in all it's a part of our job. You might like to read this if you are interested in USA DMCA procedures: http://dmca.cs.washington.edu/ Kind regards

Hello! Can you please send us the connection logs and your Comodo rules? It was fixed. If you still have issues they are most probably on the client side. The logs will help troubleshooting. Kind regards

Hello! The Windows client uses the very same Cygnus entry-IP address. 37.220.11.106 is the entry-IP, 107 is the exit-IP. So your configuration is correct. First of all, please check the client certificate field, just in case the initial blank line which is visible in the screenshot creates issues. Also, try to disable LZO compression and modify the MTU size. Start with 1560 then go down to 1500, 1400, 1300, 1200. For each value please re-test the connection with and without LZO compression. Finally please enable and send us the logs, they may be very useful for troubleshooting. Kind regards

Hello! No, there's no law forcing that. Not even for ISPs. Wikipedia is just right about it: http://en.wikipedia.org/wiki/Telecommunications_data_retention#United_States VPN services that retain users' connection logs or any other data in the USA do it for their own choice, not because they are obliged to. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in the USA is available: Librae. 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

UPDATE: the new software has now been installed on all servers. According to our tests performed during the past 3 weeks on selected servers, the AUTH_FAILED problem is totally fixed on the server side. Please do not hesitate to report any issue. Kind regards

Hello! We have had some issues with Sirius, we apologize for the inconvenience. We have managed to solve the problem and Sirius is again working fine. Please feel free to report any issue. Kind regards

Hello! Thank you for your choice. Please send the request through the "Contact us" form in the "Support" menu and you'll receive instructions in a very short time. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Sweden is available: Serpentis. 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. Please note that this server replaces Draconis https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3518&Itemid=142 Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN admins

Hello! In order to offer better performance and face the attacks periodically performed against our server in Sweden, Draconis will be dismissed and replaced by another 1 Gbit/s server (codename Serpentis) in the same datacenter. Serpentis will be protected so that possible new attacks can be effectively mitigated thanks to the invaluable assistance and setup of the datacenter technicians. Please note that IP addresses WILL change. You are advised to disconnect from Draconis as soon as possible. Currently Serpentis is already working and is undergoing the usual testing. If everything is fine, it will be up in few hours. Kind regards

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