Staff

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.

Hello! Thank you very much for your choice and for your nice words. The displayed bandwidth is the bandwidth under usage by a server in real time (or with a difference of a few seconds). Premium members do not have any limit neither on bandwidth nor on usage, so we have no interest in collecting such data (we just collect total bandwidth and traffic usage of each server in order to offer a better service, check whether there are critical points in the infrastructure, decide for infrastructure expansions etc.). Anyway, if you wish to keep statistics about your dl/ul traffic, you can enable this feature on your member panel. Of course you can delete those info whenever you wish. We allow plans accumulation, however due to a bug in our AEC account processor (a commercial product) the remaining days of the previous plan might get "burned" when you change plan type. We can fix this quickly and give you back the missing days, just warn us if you lose days and we'll fix it for you at once. Kind regards

Hello! Most probably you have mismatched the configuration for Delphini with the configuration for Omicron. You can check this by looking at your Delphini .ovpn file, probably in the "remote" line you will not see an IP address beginning with 146. Just regenerate the configuration file for Delphini and overwrite it. Kind regards

Hello! Since you use Viscosity, please read here: http://www.thesparklabs.com/forum/viewtopic.php?f=3&t=189 We're looking forward to hearing from you, Mac users might be interested in your setup. EDIT: see also this article http://www.niteoweb.com/blog/openvpn-over-ssh that is not completely related to your case but that can anyway be useful. Kind regards

Hello! Thanks for your nice words. We are not aware of any IP geolocalization service which detects our UK server exit-IP address as located in Germany... can you tell us what it is? Kind regards

Hello! Sure, it all depends on what you want to achieve. We were asked how to block a specific program and we answered accordingly. About trojans, generally it does not make a big difference if they can get out through the tunnel or not, a VPN will not protect you against trojans which send out data without your knowledge (see also Terms of Service, point 1). Chrome must be a "trusted application" in Comodo in order to be able to send and receive data. As usual, you can define further customized rules for any program, including Chrome. Please do not hesitate to contact us for any further information or support. Kind regards

Hello! Advanced options might appear only when you "Apply settings", see the DD-WRT wiki here: http://www.dd-wrt.com/wiki/index.php/OpenVPN#Enable_OpenVPN_in_the_Router According to DD-WRT developers and community, all the DD-WRT web GUI interface with firmware withOpenVPN flavor have the option to pick encryption type. We can't confirm that, since we don't have all the routers in the world, but it appears strange that such a lack would have gone unnoticed. Please keep us posted. Kind regards

Hello! Please note that you should block outgoing packets NOT in the range 10.4.0.0->10.9.255.255. If you blocked outgoing packets in that range, it was normal that uTorrent could not work with VPN connection. If you wish to block incoming packets not coming from our VPN server, just block anything to your Ethernet or WiFi interface not coming from Air server entry-IP address (also note that entry-IP and exit-IP are different; you can find the entry-IP with our configuration generator or with the Air client). Finally, we strongly recommend NOT to use any Symantec/Norton product on Windows systems: http://www.matousec.com/projects/proactive-security-challenge-64/results.php not even on 32-bit Windows system: http://www.matousec.com/projects/proactive-security-challenge/results.php#products-ratings Kind regards