Staff

@Orfeo Hello! What happens with the following rules? block out all pass out quick from 127.0.0.1 to any pass out quick from 192.168.0.0/16 to <AirVPN_server_entry_IP> pass out quick from 10.0.0.0/8 to any pass out quick from 192.168.0.0/16 to 192.168.0.0/16 Kind regards

Hello! PF needs ALTQ (Alternate Queing for Network Packets) kernel support to use all its features. Alternate queuing of network packets provides disciplines for queuing outgoing network packets (for example traffic shaping) in *BSD based systems. Apparently your Mac OSX does not come with a kernel built with this support or your network card driver does not support ALTQ functions, however you should not need them for basic firewall operations: PF will just run with disabled ALTQ functions. You can't recompile and build Mac OSX kernel (it's not open source). The default configuration file read by pf is pf.conf, not pf.con (if it was just a mistyping on your message, ignore this warning). Lines 23 and 24 have a syntax error, feel free to paste pf.conf here. You can find the entry-IP address by watching at the line with directive "remote" in the air.ovpn configuration file you have (just display it with the cat command or open it with any text editor). Please do not hesitate to contact us for any further information. Kind regards

Hello! Suppose that the account used by your SSH server has forwarded port 12345 TCP and remapped it to local port 22. Then, when your server is running OpenVPN as a client connected to one of our Air servers, you will be able to reach the SSH service on your server on :12345, NOT :22 Perform a check from your panel (click "Check", wait for some seconds, then click "Refresh"). If you see a green token, then your service on your server is reachable. If you see a gray token, then your service is not responding (or not running). If you see a yellow token, then your server is responding on port 22 even when reached to its real IP address. You might as well change the SSH listening port to a TCP port number>=2048 that matches one of the remotely forwarded TCP port numbers. In this case you will not need a remap to local port 22, and you should obtain a red token (evaluate if this can be a vulnerability exploitable for correlation attacks and if so solve it). You should also make sure that once your server establishes a connection with an Air server, it can communicate with the Internet as usual (except for incoming connections on non-forwarded ports, of course). Please do not hesitate to contact us for any further information. Kind regards

Hello! We kindly ask you to read the ToS and the Privacy Notice, available through the links at the bottom of most pages of our website, and the FAQ (menu "More"->"Frequently Asked Questions"). Acceptance of ToS and PN is mandatory for subscriptions. In a few words we don't log IP addresses on any VPN server and we don't log and/or monitor traffic (including both headers and payload) on any VPN server. Please do not hesitate to contact us for any further information. Kind regards

Hello! Thanks for your clarification. Can you please tell us how do you disconnect from an AirVPN server (just in case it is a useful info for better troubleshooting)? Kind regards

Hello! Thank you very much for your choice. There are no particular problems with PayPal, however when you pay as a guest with PayPal (i.e. without having a PayPal account), PayPal will not accept some kinds of debit cards. Please check with PayPal in your country to know which debit cards and which credit cards are accepted. Furthermore, please be aware that if you have a PayPal account and you log in your account with an IP address of a different country (for example behind a proxy, a VPN, TOR etc.), the PayPal security system will "put on hold" all the transactions you perform. The funds will be unavailable both for us and for you for 1-5 days. We also accept Bitcoin and Liberty Reserve. Please do not hesitate to contact us for any further information. Kind regards

Hello! Thanks. Also please note that if you don't use internal Air resolution, you might not be able to take advantage of the anti-ICE/DHS USA censorship system: since it is based on domain name seizure at VeriSign/ICANN etc. level, no matter which DNS that recognizes ICANN authority you use, you will always be censored. On Windows system, using custom DNS rises probability of DNS leakage (we are investigating - Windows users can get rid of this potential leakage by blocking outgoing packets from svchost.exe NOT from IP range 10.4.0.0->10.9.255.255, or by blocking connections from network card IP address to port 53 when destination IP is not AirVPN entry-IP address). Kind regards

Hello and welcome aboard! Yes, we are outside USA jurisdiction, although the recent developments in the UK pose the question whether the USA jurisdiction is unlimited... http://torrentfreak.com/pirating-uk-student-to-be-extradited-to-the-us-120313/ 1. You can use an account on as many devices as you wish. However, only one can connect to an Air server at the same time. For simultaneous connections from different devices in different networks you will need multiple accounts (contact us for discounts on additional accounts). 2. It can be a point of failure in the sense that a smart phone has geotracking abilities "independent" of the IP address you're visible on the Internet. Please read here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1333&Itemid=142#1339 3. They are both low latency "anonymizer networks". Apparently, TOR has been much more peer-reviewed, so its anonymization layer can be considered more robust. 4. Air over TOR uses the OpenVPN ability to tunnel over a socks proxy (see https://airvpn.org/tor), so our servers will not see your real IP address and all TOR nodes will see encrypted traffic and will not know the real destination of your outgoing packets and the real origin of your incoming packets (you have therefore a precious partition of trust, where if one party betrays the trust your anonymization layer is not compromised). TOR over VPN is a connection to TOR through the VPN server, so the TOR entry-node will not see your real IP address and the Air servers will see encrypted traffic and will not know the real destinations of your outgoing packets and the real origin of incoming packets. For further considerations please see https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 5. We guess that if usage of "Care Bear" were to become a violation of human rights as enshrined in the European Convention on Human Rights, either we will be forced to change our ToS or you will have to face the dramatic consequences to change your nick. Speaking of which, let us check if we have some "Hobbit" or "The Hobbit" nicknames in the forum... http://torrentfreak.com/hollywood-lawyers-threaten-hobbit-pub-120313 Please do not hesitate to contact us for any further information. Kind regards

Hello! If you have already tried lolwhat suggestions, consider the following (just in case...): - remote port forwarding must be enabled on the side of the account used by the server you're trying to reach and the SSH daemon must be started (or restarted) after OpenVPN has connected to an Air server; - services of two clients behind the same VPN server can't communicate to each other. So if your server is behind a certain Air server, you can't reach it if you are connected to that same server - make sure that you are trying to reach the SSH server on the proper IP address and port. Each Air server has different entry and exit IP addresses, so the listening SSH service is reachable on :. Please note that is not the remapped local port - if you are using ssh to perform sftp, then you will have to consider some additional issues: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1700&Itemid=142 Please do not hesitate to contact us for any further information and support. Kind regards

Hello! Can you please tell us which site does that? We'll look into the issue. In the meantime, if you were using Vega please switch to Sirius, and vice versa, to see whether this fixes the problem. We're looking forward to hearing from you. Kind regards

Hello! You should check whether AVG has the ability to set specific rules for each program as specified in the guidelines given for Comodo in this thread (for your comfort, your message has been moved here). AVG Manuals are available here: http://www.avg.com/us-en/downloads-documentation AVG FAQ & Tutorials: http://www.avg.com/us-en/faq Please do not hesitate to contact us for any further support or information. Kind regards

Hello! Excellent. You will just have to add the rules posted in the previous messages in IceFloor. In the list of features, the author writes "edit main PF and anchors configuration files with the built-in editor". You can just do that and copy & paste the given rules. Just take care to identify the correct IP addresses and network cards. Please do not hesitate to contact us for any further information or support. Kind regards

@Orfeo Hello! Just an additional note, if you need your Mac to communicate with your internal network when connected to the VPN, assuming that your internal network has devices in 192.168.0.0/16: block out all pass out quick on <your_network_interface> from 192.168.0.0/16 to <AirVPN_server_entry_IP> pass out quick on <your_network_interface> from 192.168.0.0/16 to 192.168.0.0/16 pass out quick on tun0 from any to any Finally, you may add as many "pass out ... to as you wish, listing all the Air servers entry-IP addresses, in order to switch swiftly from one server to another. Kind regards

Hello! Mac OSX 10.6 was shipped with the FreeBSD ipfw firewall. If you're not comfortable with shell and command lines, ipfw has a practical frontend, Waterroof, that will allow you to set the aforementioned rules in order to block outgoing packets in case of accidental VPN disconnection: http://www.hanynet.com/waterroof ipfw has been deprecated since Mac OSX 10.7 and 10.8. The powerful OpenBSD PF is now recommended, anyway ipfw+Waterroof will work. The PF GUI can be found on System Preferences: Security & Privacy: Firewall, unfortunately this GUI is too rudimentary so you'll probably have to set the rules in the pf.conf file. A quick how-to is here: http://www.obfuscation.org/ipf/www.inebriated.demon.nl/pf-howto A quicker how-to is here: http://thenewtech.tv/community/openbsd-pf-on-mac-osx-lion The following very basic rules would block all traffic outside the tunnel (edit with any text editor /etc/pf.conf) assuming that your ethernet or wifi interface has the address 192.168.*.* and that the tun interface used by OpenVPN is tun0: block out on <your_network_interface> from 192.168.0.0/16 to any pass out quick on <your_network_interface> from 192.168.0.0/16 to <AirVPN_server_entry_IP> pass out quick on tun0 from any to any Then execute pfctl -e pfctl -f /etc/pf.confto enable pf and load your ruleset. If the connection drops, no packets will go out, so you will be able only to reconnect to the VPN and nothing else until you disable pf with pfctl -d. Also, those rules will prevent DNS leakage. You might prepare automated scripts to enable and disable pf or to modify rules. Also, the above example is really rudimentary, so you might like to refine the pf behaviour. Please test always your rules to check whether they do what they are expected to. Please do not hesitate to contact us for any further information or support. Kind regards

Hello! At the moment the safest and simplest solution for Windows is to set rules for your firewall. We recommend not not use programs which forcefully kill other programs when connection drops: the time between connection drop detection and program shutdown may well allow leak of packets out of the tunnel. Also, a forced kill may pose further problems. Features of Comodo Firewall allow extremely quick setup, with optional selection to block outgoing packets only for certain programs in case of accidental VPN disconnection. Comodo is not open source, but it is freely distributable. It is considered the most robust software firewall for Windows. Looking at the following example, you will be able to set rules for any sufficiently advanced firewall, either to block everything if VPN connection drops, or just selected programs: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&Itemid=142#1715 Comodo Personal Firewall and other suites are available here: https://personalfirewall.comodo.com Please do not hesitate to contact us for any further information. Kind regards

Hello! Yes, that's exactly what we asked for, thank you. It looks like a very similar problem met on HTC Desire. Can you please read this: http://forum.xda-developers.com/showthread.php?t=771857 and try the suggested fix? We're looking forward to hearing from you. Kind regards

@hmmmm Hello! The remark from blknit suggests that you are using a Windows system. First of all, flush the DNS resolver cache (only if you have Windows). If the problem is not fixed after the flush, you might check that: - you don't have DNS leakage on your system (you may use http://www.dnsleaktest.com) - your system is not compromised (scan for malware, check hosts file) - your system, after the connection, is capable to contact the VPN DNS address (see here for further details: https://airvpn.org/specs). We're looking forward to hearing from you. Kind regards

@hmmmm Messages removed for spam. Please do not spam, watch your language and do not insult. This forum is aimed to give proper support to AirVPN customers and non-customers and must remain free from insults, flames and any other kind of spam. Kind regards

Hello! Good, just run it and it will prompt you to install or upgrade OpenVPN. Kind regards

@zombie1982 Try: ip route show If this fails too, look at what's in /proc/net/route cat /proc/net/route Kind regards

Hello! This netstat does not comply, the output is not the kernel IP routing table. Try then with route -n or netstat -r Kind regards Kind regards

Doesn't AIR VPN need to see what user logs in to know if it should be allowed to connect or not, so if the site ur connecting to see the AIR VPN IP adress they know what server connected and when and could match that to airvpn as you can log the user logins, so the trust is back on the your service to uphold the control over the information. Hello! The VPN server needs to check whether an account is on premium status in order to allow the connection but does not keep any information about any account, it queries for authorization a backend server. We recommend NOT to put information in your account data that can be exploited to disclose your identity. As long as we don't know who you are, we can't tell anybody who you are. With Air over TOR, you can also prevent our servers to know your real IP address, even while you are connected. The AirVPN system, if used correctly, is designed to defeat an adversary that has up to the following abilities: the ability to fully monitor the customer's line AND (the relevant portion of the Tor network OR all of the Air VPN servers) the ability to fully monitor any financial transaction of the customer An adversary with such abilities can be defeated in the following way: the customer subscribes to AirVPN with a Bitcoin transaction or a transaction performed through some cryptocurrency designed to keep an anonymity layer on the transaction (check Monero, we accept it without intermediaries) the transaction is performed by tunneling the cryptocurrency transaction and any other operation of that wallet over Tor the transaction is performed with a wallet exactly fit for that transaction the wallet is destroyed immediately after the transaction success (safe deletion of the wallet) the customer always performs "partition of trust" (with the proper account) between parties from now on the customer does NOT insert personally identifiable information in his/her payload, unless he/she wants explicitly to be known by the final recipient: remember that a VPN or Tor or any other system are impotent if you insert personally identifiable information in your content Partition of trust is essential, so that a betrayal of trust by one party does not compromise the anonymity layer. An example of partition of trust is AirVPN over Tor: the Tor nodes see only encrypted (by OpenVPN) traffic and AirVPN servers do not see the real IP address of the user (they see the TOR exit node IP address). On top of that, entry-IP and exit-IP addresses of AirVPN servers are different (to emulate a 2-hop VPN in addition to the multi-hop provided by Tor) in order to prevent correlation attacks. The VPN admins therefore do not know the identity of the customer while the TOR nodes admins do not know the content, the real origin and the real destinations of the packets from/to the Air customer. The drawback of the above setup is that Tor will use always the same circuit, so when this is a concern, you should consider Tor over AirVPN: just run Tor after the system has connected to the VPN and use only Tor-configured applications to transfer sensitive data. In this way, our VPN servers will see your real IP address, but will not know the real, final origin and destinations of such data. Additionally, your packets are still encrypted by Tor when passing through the VPN. The VPN will act as a jumping point to reach Tor, will hide Tor usage from the eyes of an adversary wiretapping the customer's line (extremely useful when someone can be targeted for the mere fact of using Tor), and will at least provide a first protection for UDP flows (if any) and system flows that might be originated by the system and that can't be handled by Tor. Furthemore, the customer should add an encryption layer to protect her packets payload once they get out of our servers or while they transit through the Tor circuits (trivial examples, use GnuPG for e-mails, HTTPS if you reach web sites, SFTP or FTPES for FTP transfers, and so on) in case the payload could be exploited (for example by a second adversary, even unrelated to the first, that monitors the line of the final recipient) to disclose the customer's identity. Always use end-to-end encryption. Always. An adversary with superior abilities may not be defeated by the above setup. Typical examples: an adversary with the ability to monitor the customer's line AND the relevant portion of the Tor network AND all the AirVPN servers an adversary with the ability to fully control the hardware or software of the customer, without the customer's knowledge AND while the customer uses this hardware or software (it's only up to customer to take care against this threat, we can't do anything about it) a global adversary The first kind of adversary requires additional trust partition(s). The second kind of adversary renders the anonymity layer outside the victim's hardware irrelevant. The global adversary theoretically can never be defeated on the Internet. Luckily, the very existence of the global adversary (an adversary with the ability to monitor, store, analyze and correlate all the connections in the world continuously) is highly debatable. Please do not hesitate to contact us for any further information or support. Kind regards

Hello! About Air over TOR, please see https://airvpn.org/tor and http://openvpn.net/index.php/open-source/documentation/howto.html#http About TOR over Air, it's just a proxy over OpenVPN. Please note that a strong additional security layer is obtained with Air over TOR thanks to the partition of trust (TOR nodes see your traffic payload still encrypted and Air servers don't see your real IP address). For deeper knowledge, you might like to examine your routing table, analyze your incoming and outgoing packets with appropriate tools (Wireshark is great), and examine the OpenVPN source code http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=summary Wireshark is available here: http://www.wireshark.org Please do not hesitate to contact us for any further information or support. Kind regards

Hello! There is a very slight delay (keep in mind that VPN servers do not keep or store any account information, login data etc.) of the order of very few seconds or less. A five minutes delay is abnormal. We'll look into the issue, does it happen for you on every and each server or on some particular server? Kind regards

Hello! Good, netstat without parameters just confirms what we already knew from the OpenVPN logs. Can you please send us the kernel IP routing table after the connection? netstat -nr Kind regards