Staff

Hello! An Air client version for Windows 8 is ready. The following is bundled with OpenVPN 2.3_rc1 for 64 bit systems: https://airvpn.org/repository/air_windows8_x86_64.zip The following is bundled with OpenVPN 2.3_rc1 for i686: https://airvpn.org/repository/air_windows8_i686.zip The Air client has been recompiled with .NET framework 4, so it will start immediately on a default Windows 8 installation. Please feel free to let us know if the above solves your problems. Kind regards

Hello! "Tor is free software and an open network that helps you defend against a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security known as traffic analysis". https://www.torproject.org While a VPN outperforms TOR in terms of bandwidth and latency, and allows all protocols (while TOR can't support UDP and is not suitable for p2p) TOR is anyway an important tool to increase your privacy and strengthen your anonymity layer. In critical situation, when a person can't afford to trust the VPN operators (to make an extreme example, when his/her life is at stake if his/her identity is disclosed and related to the information he/she imparts and/or receive), TOR can be used to perform what we call "partition of trust", so that betrayal of trust by one party does not destroy the anonymity layer. Some considerations on partition of trust and how to increase the strength of the anonymity layer if a person lives in a human rights hostile regime: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 How to connect over AirVPN over TOR: https://airvpn.org/tor In order to connect, on the contrary, over TOR over AirVPN, just connect to an Air server first, then use TOR. Considerations about different approaches on partition of trust: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=5821&Itemid=142#5822 Of course if you don't find yourself in such critical environments you probably don't need any of the above, just connect to Air "normally". Kind regards

This is what I would like to do. Can TOR browser be made to work in this way? Hello! Thank you. Well, yes, for example the Aurora (a customized Firefox) browser in the TOR browser bundle can be configured to use no proxy, and you still have all the protections configured by the TOR Project Team (no scripts allowed, no Flash, https anywhere possible...). Just like with Firefox, in order to set how Aurora must connect to the Internet, go to "Options"->"Advanced"->"Network" tab. Then click on the "Settings" button near "Configure how Aurora connects to the Internet", finally select "No proxy". Kind regards

Hello! Your connection is "AirVPN over TOR". In this case, if you use a browser NOT configured to connect over a proxy: - our servers can't see your real IP address, but can see your traffic - TOR nodes can't see your traffic, which is encrypted by OpenVPN - you are "visible" on the Internet with the Air server exit-IP address With the same setup, if you run a browser configured to connect over the same TOR proxy used by OpenVPN: - you will be using TOR only - your traffic will not pass through our servers - you will be visible on the Internet with the TOR exit-node IP address of the established circuit - you are not protected against TOR malicious exit-nodes So, if your purpose is getting protected from malicious TOR exit-nodes and hide to our servers your real IP address, you should connect over OpenVPN over TOR, as you have already done, and then use a browser not configured to connect over a proxy. If your purpose is hiding your traffic to our servers, then just connect to an Air server normally, and then use the TOR browser. If your purpose is hiding your traffic AND your IP address to our servers, but trusting TOR exit-nodes, you can connect over TOR over AirVPN over TOR. In order to do that, the simplest way is through a Virtual Machine. In the host you just connect over OpenVPN over TOR as you do now. In the guest OS you connect over TOR. Kind regards

Hello! Please check your account (menu "Member Area"->"Your Details"). Kind regards

Hello! The application rule for uTorrent looks ok and the AirVPN Network Zone is correctly defined. Maybe uTorrent is using a proxy? Please also check that Comodo Firewall security is set to "Custom Policy". As a side note, please check your Loopback Zone definition (it is wrong), it must be IP/Netmask [127.0.0.0/255.0.0.0] or equivalently IP range [127.0.0.0 - 127.255.255.255] Kind regards

Hello! You're right, if you need contiguous ports the system is annoying. We planned to modify this system actually (for example with the addition of a "map" of free ports) and we'll work on it soon. EDIT: option was added. In the meantime please contact us and we'll give you a free consecutive 20 ports range. We'll have to provide the option to use the same forwarded ports to different accounts and direct those accounts to different exit-IP addresses or invent some other trick. Actually, it is a problem which we would be glad to face, it would mean that Air is used by very many people. Kind regards

Hello! The problem was solved some hours ago, anyway your account was one of those not affected by the issue. Your account is connected and exchanging data successfully with some Air server since 15-16 hours ago approximately. Kind regards

Hello! tun0 IP will be DHCP-assigned by our servers, unless you reject the push with nopull. https://airvpn.org/specs Yes, it makes sense, and if you notice no leaks you're just fine. The "no connection found" is probably correct (it should occur until your OpenVPN client receives the push from the server). Of course you're right, a remotely forwarded port for a p2p client must not be remapped to a different local port, as specified in our FAQ, otherwise the client won't be reached from the Internet (p2p is of course possible but with no incoming connections). This is a particular case for which a port remap is not desirable with our cone-NAT. Kind regards

Hello! It appears that your account has no problems at all. Can you confirm? Kind regards

Hello! This should NOT happen (unless the frontend is under attack, in which case it may happen for various minutes), we apologize for the inconvenience, we'll investigate. If the webpage takes some time to update, we are probably under flood/attack Which servers and ports do you usually connect to, and which protocol (UDP/TCP) do you use? Kind regards

Hello! Normally the activation is immediate. In the last hours we have had an issue which blocked RSA keys generation and sometimes slowed down considerably the activation to premium status of new accounts. The problem has been fixed, now your account is on premium status and you can access all the VPN servers. We apologize for any inconvenience. Kind regards

Hello! Can you please send us a screenshot of the rule which should block uTorrent? Kind regards

Hello! Normally you don't have to, the above problem has been now fixed. Kind regards

Hello! We have had a problem with the database, we deeply apologize for the inconvenience. Several accounts could not re-connect and new accounts did not have their keys generated. We have now solved the problem. Kind regards

Hello! The problem has been solved. It was related to the database. We're sorry we needed several hours to fix it and we apologize for the inconvenience. Kind regards

Hello! We're working to solve the problem, we apologize for the inconvenience. Kind regards

Hello! We're working to solve the problem. We apologize for the inconvenience. Kind regards

@diablo99 Hello! We apologize for the inconvenience. We're working on the problem. Kind regards

Hello! The days were actually lost. We are changing all the account processing system to overcome some limitations and bugs of the current one. Kind regards

Hello! The approach is very good and clean. You can make it even better by allowing communications from any interface to the single IP 255.255.255.255 to allow initial communications with a DHCP server. 255.255.255.255 is the broadcast address of 0.0.0.0 (the zero network, i.e. the local network), so it's necessary to NOT drop the packets to it in order to establish a packet flow with a DHCP server. No worries about it, in IPv4 no packets toward 255.255.255.255 can ever leave the local network. For those using a DHCP server, probably the vast majority of people, the addition will make unnecessary to turn off and then on the firewall at the bootstrap and in every other circumstance where a DHCP negotiation is needed. With iptables something like: iptables -A OUTPUT -d 255.255.255.255 -j ACCEPT #make sure you can communicate with any DHCP server iptables -A INPUT -s 255.255.255.255 -j ACCEPT #make sure you can communicate with any DHCP server Another circumstance to think about (and we'll have to address it even in the iptables guide) is when a user does not have the resolvconf package installed (so the client has no way to process a DNS push from our servers) AND uses his/her router as a DNS server. In this case the DNS queries will be sent to the router and then sent out by the router itself unencrypted. Mutatis mutandis, the same problem has been already addressed and solved in Windows and in the Comodo rules. Linux users without resolvconf will have to change manually their DNS server in /etc/resolv.conf (any DNS except the local router DNS will be tunneled), but to make them aware of their problem we could add a rule which prevents any communication toward their router (or even inside their whole LAN/WAN) if the destination port is 53 UDP. This rule will not harm communications inside the LAN/WAN but will make impossible to resolve names through the router (actually blocking DNS resolution if the primary nameserver is "misconfigured" and therefore alerting the user). [EDIT] Finally, you can allow communications from/to the loopback interface (lo in most Linux flavors, 127.0.0.0/8) in order not to disrupt communications within it, which in some cases may be a serious problem. Kind regards

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