Staff

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

Yes, I generated it and it is self signed, as the website states. There are many issues I take with Certification Authorities. And, in fact, I use Convergence, which removes the whole spurious CA issue. The certificate is trusted by default in Convergence. I have thought about implementing something similar to your suggestion. I have not decided yet but it is possible--to avoid scaring off people. Hello! A confirmation from you of the following would be enough atm: SHA-1 fingerprint: 5E 1B EA F4 B3 76 E0 01 E0 3D 51 21 0C 9F FC 77 00 E3 5C 85 SHA-256 fingerprint: 7B 5F A0 F0 18 49 13 B4 8E 06 F5 A6 B4 2F 94 FF 59 9B B2 A2 5D 4F B4 AB 86 7A 6B E6 26 61 0A B2 This is the certificate we can see from the Air network. Since it's the same from all the Air servers, the probability of an hijacking can be considered practically zero if you confirm the above. This manual verification may be irrelevant in several countries, but might be important in some other countries. Kind regards

Thank you! Since the certificate is not emitted by a CA, can you please publish the SH1 and MD5 fingerprints of the certificate to allow verification to everyone? Kind regards

Hello! Of course, this may happen if your computer sends DNS queries to your locked router/modem. The locked router/modem will then send a query to your ISP DNS. In this case you need either to prevent leaks with our firewall guides or force the DNS resolution to the VPN DNS (10.4.0.1 https://airvpn.org/specs), so that the VPN query will be encrypted and encapsulated by your OpenVPN client, sent to our servers and finally processed by them. This gives the advantage to be able to access VPN internal services and bypass some ICE censorship which can't be bypassed with any other DNS. Kind regards