Staff

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

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