Staff

Hello! You are right, we apologize for the bug. We have now set the correct subscription expiration date for your account. Kind regards

@Anonymous Writer Thank you very much for the explanation. Kind regards

Hello! Excellent. You made no mistake, it's the proposed method by Anonymous Writer that does not really prevent all the leaks. As you can see, packets to outbound ports 443 TCP and UDP are allowed from your physical interface. It means that when the VPN disconnects, Firefox (or any other browser) can still connect to https websites (in almost all cases, web servers listen to port 443 for https, and browsers by default send packets to port 443), and that's exactly what you report. DNS resolution is not possible (because packets to port 53 are dropped) but the system, before sending out a DNS query, will use the DNS resolver cache to resolve the domain name, making the DNS block totally useless in this case. This is dangerous, because if you're surfing an https website and you lose the connection, then refresh a page or access another page of the same website, you still have the same session cookies in your browser, thus that site will see you real IP address and will also be able (if the admins wish so) to correlate all your previous activity and account behind the VPN with your real IP address, potentially destroying your anonymity layer. In order to solve the problem: - if you always connect to our VPN to port 443 UDP, do not allow packets to port 443 TCP, i.e. delete the rule -user-output -p tcp --dport 443 -s 192.168.1.1 -j ACCEPT. If you wish to connect to port 443 TCP as well, you will have to rely on a different approach to solve the vulnerability, an approach not based on ports. See for example instructions for iptables, pf or ipfw to get an idea. Approaches not based on ports will also allow you to connect to other ports our OpenVPN servers listen to (53 TCP/UDP and 80 TCP/UDP) without risking leaks in case of unexpected VPN disconnection. Kind regards

Hello! Access the NetGear Smartwizard router manager (see your manual to do that and see the login credentials). In the "Security" settings select "Firewall rules" and make sure that no remotely forwarded port (i.e. the ports you have forwarded on our servers, for example 12352) is open. Optionally, in the "Security" settings again, select "Port forwarding" and tick "Disable port forwarding" if you don't need port forwarding for some of your services OUTSIDE the VPN. Finally, enter the UPnP menu and make sure that UPnP is disabled (you won't need it when connected to the VPN). Kind regards

Hello! Splitting traffic to different NICs on a process basis is a serious challenge. Our servers push routes and default gateway so that all the client traffic will be tunneled. OpenVPN client does not provide a built-in way to split traffic. You can have your client refuse the push (nopull directive) and then build your own routing table(s) with appropriate gateways to split the traffic between tun0 and eth0 (or any other card you have). A discussion about issues, troubleshooting and possible solutions of such a setup in an Ubuntu environment (check the links inside the thread as well): http://ubuntuforums.org/showthread.php?t=1200601 Alternatively, if the programs have the appropriate function, you can bind all those that you don't want to be tunneled (Apache, ftp server...) to the NIC you wish. Otherwise (this is an alternative, not a solution to what you have asked) your web and ftp services can be anyway reachable from the VPN server : (just forward remotely the appropriate ports and configure them in Apache and ftpd). This might give you the advantage to have a static IP address, making no-ip unnecessary. About ftp servers some additional care is required for forwarded ports: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1700&Itemid=142#1702 Kind regards

Hello! Usually it's just a matter to access the router web interface. Please consult your router manual. If you tell us your router brand and exact model, maybe we can help you as well. Kind regards

Hello! Our testing system could reach your real IP address and received a response by some service running on your computer on the same port that you remotely forwarded. This makes you potentially vulnerable to correlation attacks from someone with the ability to monitor your line. In order to prevent it, just make sure to close port 12352 on your router. Kind regards

Hello! The correct IP is 212.117.180.25. Try to ping it. Previous problems should be resolved now. In order to access the alternative frontend please insert in your hosts file: 85.17.207.151 airvpn.org Make sure it is the only entry pertaining to airvpn.org. Kind regards

Hello! Please delete the 46.105.19.36 entry, this IP is no more used by us. The Comodo rules are fine. Please check the IP address of the frontend, it's 212.117.180.25. We apologize for the previous mistyping, which anyway does not explain your previous problem. In the meantime, leave in your hosts file only the following entry for airvpn.org: 85.17.207.151 airvpn.org What about the certificate fingerpring check? Is it ok or not? Kind regards

Hello! It seems there are some intermittent connectivity/routing/packet loss problems on the frontend you're pinging. We'll keep an eye on it. In the moment of writing the issue seems resolved. If you can't access that frontend, switch to the second: 85.17.207.151 airvpn.org Kind regards

Hello! With some precautions you have plenty of choices. Pay attention to access your mail provider (either it has a mail-to-www wrapper or direct access to SMTP and POP3/IMAP servers) always when you're behind the VPN or behind TOR (in this case remember to tunnel your mail client over TOR) and never use that account with e-mail whose content can disclose your identity. Pick a provider that provides access either to https web mail wrappers or to SMTP and POP3/IMAP over TLS. We recommend gpg usage as well. http://www.gnupg.org/ A/I (Autistici Inventati) have quite a good reputation as free, privacy aware mail provider: http://www.autistici.org/en Kind regards

Hello! As far as we know Rhapsody discriminates against non-USA IP addresses. Please try to connect from an USA server. Kind regards

Hello! Without knowledge of which software it is, we can only propose mere speculations. Maybe the software connects to a host which performs geographical IP discrimination. Or maybe the host has a business model which can work only with privacy intrusions, and this model is threatened by usage of VPNs. Kind regards

Hello! It's good that you access our website through TOR. The TOR browser did not give you any certificate warning about our website, right? The certificate is emitted by a proper CA which is correctly recognized on every browser. You should check the certificate of the site where you get the warning, it might not be our real website. Please check the fingerprint of the certificate to verify whether you're really on our website or not: SHA-256 fingerprint: 7F C6 1C D8 97 F9 51 EC 3B D5 84 F0 4F BD E3 2D DB 3D F8 12 16 C8 86 BB A0 EA 26 31 36 35 21 8E SHA-1 fingerprint: EE 54 D8 0A E5 68 DB 61 69 51 E7 0B BF C6 E8 D1 0C EC 86 3F airvpn.org must resolve to 212.117.180.25 If your DNS is "poisoned", try to use another one, or anyway put in your hosts file the line: 212.117.180.25 airvpn,org If it's the IP address that is blocked, you can access our alternative frontend 85.17.207.151. Insert in your hosts file the line: 85.17.207.151 airvpn.org Check the Comodo rules and make sure they allow access to airvpn.org You can determine whether an IP address of our frontend servers is blocked on your system for example by trying to ping it directly: ping 85.17.207.151 ping 212.117.180.25 Anyway, using TOR is a very good solution. Poor quality programs like Malwarebytes can prevent access to our website because they block whole datacenter IP ranges. Kind regards

Hello! Yes, once you're inside the VPN browse to https://speedtest.air to perform a direct speed test with the server, without relying on external services. Kind regards

Hello! In order to change DNS: - Choose Apple menu > System Preferences, and then click Network. - Select the network connection service/card you want to use in the list, and then click Advanced. - Click DNS and enter the IP address of the VPN DNS server (10.4.0.1) as first Repeat the process for every network card. Kind regards

Hello! Uh, sorry, when you talked of iptables this admin assumed that you were trying to implement the iptables rules without graphical iptables frontends. If you use gufw, just send the gufw rules, don't bother about the underlying iptables rules. Kind regards

Hello! It depends on your OS, which one are you using? No DNS query will go out when you're disconnected from the VPN with the firewall recommended rules set in the computer which runs the client, regardless of a locked or not locked router (this is the reason for which we recommend, in some configurations, to add in the hosts file the airvpn.org resolution, otherwise reconnection with the Windows Air client would not be possible - no modification is necessary if you use OpenVPN directly). When that computer is connected to the VPN, only encrypted (tunneled) DNS queries will go out. The tunneled DNS queries not only can't be read by your ISP, but can't even be recognized as such. Kind regards

Hello! Did you create a script to flush rules and add the rules showed in https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=30&Itemid=142#2010 ? If so, can you publish it? Kind regards

Hello! We can tell you ad nauseam that we don't log and we respect privacy of our customers etc. but IF you can't trust us and/or if you think that your adversary has the power to control the VPN servers, THEN the only safe solution is performing partition of trust: this a technical solution to defeat ANY adversary that spies on you directly on the VPN server. Kind regards

Hello! Great news, thank you for sharing! Kind regards

Hello! There's probably something wrong in your rules, Firefox must be unable to send data when the VPN connection drops. Can you post your rules? Kind regards

Hello! That depends on the investigation methods chosen by the proper authorities and on the alleged crime. We can't spy on our customers, the investigation methods are not our competence. Sorry, we don't understand the scenario depicted in your phrases as well. [EDIT] In case you're speculating about a scenario in which the adversary has the power to monitor the VPN provider servers, then again the technical solution to defeat such an adversary is performing partition of trust as described in the post linked in the previous message. Kind regards

Hello! No investigation based on logs is possible because we don't keep any log on OpenVPN clients traffic. About the USA (since you cite FBI, probably you're thinking of the USA only), there are no USA laws which compel any provider to keep logs. Please read carefully our ToS: if an account allegedly violates our ToS (in particular infringements of the ECHR) AND we are authorized to proceed by the jurisdictional competent magistrate with the aid of competent/specialized authorities, nothing prevents us to perform ex-post investigations if we wish so, just like it happens with any real mere conduit of data. The important difference between us and several VPN providers is that we don't log ex-ante and that we strictly comply to 95/46/EC and 2002/58/EC. We can go on forever discussing about what's true or not, so the ultimate argument is that our system has been designed so that you don't need to trust us, please read here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 Partition of trust is sometimes overlooked but it becomes essential when you can't allow yourself to trust a single entity, like your ISP, or a VPN provider. Kind regards

Hello! There are no problems with Air servers. Please see here for possible causes: https://airvpn.org/faq#speed That said, another option is that your ISP is capping bandwidth on some ports. Please try connections on different ports to make a comparison (for example 80 UDP, 80 TCP and 53 UDP). Kind regards