Staff

Hello! Please ask Android community. Air does not support L2TP VPNs. Kind regards

Hello! Sure, ipconfig /all will display all the adapters and relevant info about them. Kind regards

Hello! Thus it is sure that the the torrent client is the responsible, as expected from the red token. With your new setup, you will be prompted by Comodo what to do with incoming packets, however we're afraid it will not be easy to discern which packets you should accept and which reject, because you will see them coming anyway from the same, real IP address, regardless whether they have been sent through the tunnel or directly to your real IP address. Kind regards

Hello! Yes. Please find further answers on our FAQ: https://airvpn.org/faq A substantial difference is that we don't keep logs and we don't monitor your connection. Yes, there are a variety of solutions. We recommend to properly set firewall rules. Methods which scan connection and in case of disconnection detection forcefully kill programs are not reliable, because the time between disconnection detection and program kill is enough to allow leaks. Kind regards

Hello! We performed an independent port scan (that is, independent of the test which gives you a red token) on that port on your real IP address, and we can confirm you that you are reachable on that port on the IP address you were connected from. Something replied back on TCP. So the red token is correct. First, determine the program which is responding on that port, turn it off and re-perform the test. You should obtain a gray token. If not, there's some other thing listening on that port, TCP. If you obtain correctly the gray token, check with Comodo that the Home #2 network zone is really the zone for which you want to drop the incoming packets. You can also try to block all the packets for that zone NOT coming from the Air server entry-IP address you're connected to: if the zone is correct, you should lose connectivity when you disconnect from the VPN server. Additionally, add a rule for the BitTorrent client, block it for all outgoing packets NOT coming from IP range 10.4.0.0->10.9.255.255, so that the torrent client can't send out any packet outside the tunnel. We're looking forward to hearing from you. Kind regards

Hello! Do you get a gray token when your torrent client is not running? Kind regards

Hello! The second rule looks correct. Make sure it is not overridden by previous "Allow" rules: put it on top. Kind regards

Hello! It is likely that your modem/router keeps all ports opened, exposing you to correlation attacks. If you can configure your router, make sure to close (or put on stealth mode) port 13761. If you can't configure it, with Comodo detect your network zone related to your router (probably 192.168.*.*). Go to "Firewall"->"Network Security Policy" and tell Comodo to drop incoming packets for that zone toward port 13761 (tab "Global Rules"). Please do not hesitate to contact us for any further information. Kind regards

Hello! We moved your message to this thread so that you can see how to proceed. Kind regards

Hello! Well, anyway a feature missing on the OpenVPN configuration web interface is not a feature missing in OpenVPN. Just enable it with a script. For example, you might store in nvram this: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1955&Itemid=142#1956 and launch it whenever you need it (or at boot time) to connect to Air. Just adjust it in order to fit your needs (server and port for the connection). Kind regarfds

erm... sorry for that noob-question, but what exactly does that mean (remap)? i'm afraid i will need a step-by-step explanation here... windows firewall is of course turned off. Hello! Just leave the "local port" field blank. Kind regards

ah, ok. i was using the swedish server, and tried the uk one. same results on both of them. set emule as trusted application in comodo, same results. still low id, still failing tcp port test. the port forwarding test seems actually to be quite buggy. i refresehed it several times, the emule udp port changed from red to green and back, so did the bittorrent port from grey to yellow. no changes on the emule tcp port. Hello! We have checked that port forwarding works both on Draconis and Delphini and that the system check is ok as well. eMule and various BT clients work properly and receive incoming connections. Try to do following: - forward a port TCP/UDP - do not remap it to a local port - change the eMule ports (TCP and UDP) to the same number of the port you have just forwarded - make sure that Windows firewall is disabled We're looking forward to hearing from you. Kind regards

thanks for your quick answers! i am not using any servers, i connect through kad only. i'm afraid the problem remains. to be sure, i enclosed a screenshot of my connections settings. i forwarded the ports given there. Hello! We meant: which Air server(s) are you connected to when emule port tests fail? Maybe you were connected to TOR [over Air]? Or perhaps imgur wrongly identifies one of our exit-IP addresses as an IP of a TOR exit-node (this fact could be caused by TOR exit nodes run behind our VPN: we don't know whether there's any, as usual we don't monitor connections at all). We'll perform further tests with eMule once you tell us which Air server(s) you use with eMule. In the meantime, make sure that eMule is a "Trusted Application" for Comodo. Kind regards

Hello! Thanks for your subscription. Yes, it's perfectly ok, of course. Thanks agains. The red token on the UDP port might be a bug of the checking system. Currently, we have just re-checked that port forwarding works ok. Can you please make sure that the emule port number matches the remotely forwarded port number? You should obtain a green token. Also, can you please tell us which server(s) are you using for that? Yes, BT can work without port forwarding, but performance may be impaired, because it can't receive incoming connections. It is just a peculiarity of any and each BT client speed indicators, no worries. That method is not safe. Apart from considerations on possible data loss and corruption in forced killing of applications with this barbaric method, in this case the time between disconnection detection and program killing may allow packet leaks. If you are determined to follow this method anyway (but there's no reason, since you are already protected by Comodo) you can use VPNetMon (http://vpnetmon.webs.com/), which supports OpenVPN and has been tested successfully with Air servers. Just tell it to monitor subnet "10" if it does not detect the correct private IP (usually it does not detect it at all). We'll pass this request to the Air client programmer. Kind regards

Hello! As you can see, speeds vary enormously according to different tests from different ISPs. On our side, we make sure to always provide a guaranteed allocated bandwidth: no overselling at all. Furthermore, our servers are located in datacenters directly connected to tier1 providers (except Vega). Finally, we pick hardware for our servers so that the average load on CPU and I/O never affects ability to provide full dedicated port bandwidth on each server. Technically, there's really nothing more we can do to provide better performance. If your ISP is connected to tier3 providers (or worse) only, even with redundancy, the problem is from your ISP. That said, there may be very many different reasons which cause an anomalous speed decrease: your ISP might cap ports (in this case, test ports 80 TCP, 53 TCP and 53 UDP, which are less likely to be capped); your router or hardware might slow down the traffic due to encryption (we provide one of the strongest encryption available in OpenVPN, AES-256-CBC, which may cause slowdowns on old hardware and old DD-WRT routers). Further explanations are given in the FAQ. Finally, one-time tests performed with speedtest.net might mean absolutely nothing. Kind regards

Hello! That is neither a script nor command lines, but a configuration. With DD-WRT, it might be better to insert the rules as you did before for the connection setup: as a list of iptables commands. Please see https://airvpn.org/ddwrt/ paragraph "DD-WRT Firewall rules". Also, check the "lo" interface, it is very probable that on your DD-WRT you use "br0". A simple example of rules to block all outgoing packets except those toward the Air server whose entry-IP is 95.211.98.154 and assuming a "default" DD-WRT firmware with OpenVPN flavour and tun0 as tun interface: iptables -I FORWARD -i br0 -o tun0 -j ACCEPT iptables -I FORWARD -i tun0 -o br0 -j ACCEPT iptables -I INPUT -i tun0 -j REJECT iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE iptables -I OUTPUT -o br0 \! --dst 95.211.98.154 -j DROP # if destination for outgoing packets (on br0 only!) is NOT 95.211.98.154, drop the packet Insert the above rules as specified in the aforementioned tutorial. Kind regards

Hello! You might use iptables. See here for a significant example, and adapt it to your DD-WRT router. Keep in mind that: - Air uses a tun interface; - change the "lo" interface according to your DD-WRT router; - the xx.xx.xx.xx IP address reported in the example must be changed to the Air server entry-IP server address, not the exit-IP (add as many rules as you wish for each entry-IP address, in case you want to switch Air server from the DD-WRT OpenVPN web interface). You will find the entry-IP address of each server on the air.ovpn file generated for that server, line "remote". http://www.linuxforums.org/forum/networking/178976-how-only-allow-openvpn-connections-iptables.html Kind regards

Hello! It depends on your network configuration. If you make the connection through a computer and you accept the routes pushed by our servers, you should have no DNS leak, and your computer should use no more the router DNS. Your router will not even know your traffic payload and real sources and destinations, so it can't discern DNS queries among all the packets. Watch out for DNS leaks directly from your computer, if they are sent out unencrypted your provider may know which domain names you communicate with, potentially even if you don't use their DNS. See here for VPN DNS resolution: https://airvpn.org/specs Using VPN DNS will allow you to bypass USA ICE censorship in several cases. You'll find in the forum several suggestions to prevent DNS leaks. When connected to the VPN, check whether you have DNS leaks with this tool: http://www.dnsleaktest.com Kind regards

Hello! The resolv-retry infinite directive in our configuration files should already force openvpn to try a reconnection as soon as the connection with an Air server is lost. However, if the DD-WRT OpenVPN has crashed you need either to reboot or to prepare a script which re-launches OpenVPN. You might also try to run OpenVPN as daemon and prepare a startup script to launch it, based on our ca.crt, user.crt, user.key and air.ovpn. A script would look like this (it's assumed that openvpn is in /usr/sbin) cd /tmp /usr/sbin/openvpn --mktun --dev tun0 echo \” # Here just paste your air.ovpn file content... daemon # ...but note the addition of the directive daemon # end of air.ovpn paste \” > air.ovpn echo \" -----BEGIN CERTIFICATE----- …INSERT ca.crt CONTENT HERE… -----END CERTIFICATE----- \" > ca.crt echo \" -----BEGIN CERTIFICATE----- …INSERT user.crt HERE… -----END CERTIFICATE----- \" > user.crt echo \" -----BEGIN RSA PRIVATE KEY----- …INSERT user.key HERE… -----END RSA PRIVATE KEY----- \" > user.key chmod 600 user.key sleep 12 ln -s /usr/sbin/openvpn /tmp/airvpn /tmp/airvpn --config air.ovpn Kind regards

Hello! Yes, you just need to connect only the Mac, like apparently you did. The OpenVPN servers routes push does not "affect" communications inside your home network. Kind regards

Hello! Yes, the privacy legal responsible person has the ability to make such correlation. If he hadn't, we could not offer a refund policy. However, he has not the ability to correlate any account with any VPN usage, not even with which server the account has been used for connections. On top of that, keep in mind that PayPal transactions remain stored "forever" (just like any bank transaction), you can't delete them. The transactions proves just that you are an Air customer. Please use Bitcoin if you want to make such correlations impossible. Can you please elaborate? Kind regards

Hello and thank you! Fixed. We apologize for the inconvenience. Please do not hesitate to contact us for any further information or support. Kind regards

Hello! No, they would be no more available on our servers. However, the system would not allow you to do that. If you think that your account is not ok, probably it's better to ask us to delete it and then re-start with a new one. Feel free to contact us in private for further details (menu "Support"->"Contact us"). Kind regards

Hello! Stored information (not on VPN servers, but on a backend server) are: - your login name - your name as entered in the subscription - your password (encrypted) - date and time of account subscription - date and time of last login on the website - date and time of account expiration - subscribed plan type (if any) - e-mail address associated with the account - forwarded ports linked to the account (if any) The above information are provided by you and must be stored in order to provide the service. Without them, you could not even log in. We recommend not to put in your account data any information which can be exploited to disclose you real identity. For example, do no put your real name, do not use an e-mail address which can be linked to your real identity. We don't check e-mail validity, but you might need a working e-mail in case you need to reset your password, receive support or any other private communication from us. If you enable the connections statistics, further stored data (deletable whenever you wish) are: - time and duration of connection to a VPN server (not specified which one) - total uploaded and downloaded bytes - uploaded and downloaded bytes of last 50 sessions IP addresses are not stored, not even if you enable the sessions statistics. The above information can be deleted upon simple written request. Yes. Please note that each server has different entry-IP and exit-IP addresses. Thank you! Please do not hesitate to contact us for any further information. Kind regards

Hello! Please give us detailed information on your system and how you can reproduce the behaviour. The more information you give us, the easier it will be to reproduce and spot the bug. Thank you and kind regards.