Staff

Hello! The "Exclude" tick might or might not work properly (it works as a NOT operator), it depends on your configuration. Probably the most straightforward way is switching from your "Custom Policy" (when connected to the VPN) to "Safe Mode" (when you want connectivity without the VPN), because to do that you just need to right-click on the Comodo dock icon. Kind regards

Hello! Blocking outgoing packets is enough to prevent leaks, no packet with your real IP address as origin will get out of eMule. If you wish to block ingoing packets as well for eMule, things are just a little bit more complex with Comodo, because you can't know from which IP address and ports those packets come from. But what you do know is that eMule must accept only packets coming from the TAP-Win32 adapter. So you can add a rule for eMule that says Typical solution: Action: Block Direction: In Protocol: TCP or UDP Source Address: Network Zone (specify the Network Zone defined for your physical network adapter) Source Address (alternate solution): MAC (specify MAC address of your physical network adapter) Destination Address: Any Source Port: Any Destination Port: Any Alternative Solution: Action: Block Protocol: TCP or UDP Source Address: NOT Network Zone (specify the Network Zone defined for your TAP-Win32 adapter when connected to the VPN) Destination Address: Any Source Port:Any Destination Port: Any The alternative solution might pose issues if you change connection port to Air servers, because for each connection port Comodo will define (correctly, because subnets are different) a different Network Zone. In this case you'll need to add further rules for each Zone created for the VPN. Kind regards

EDITED ON 21 Aug 12 EDITED ON 24 Nov 12: added important note for some Linux users, see bottom of message Hello! You can use iptables, a very powerful packet filtering and NAT program (probably one of the most powerful, if not the most powerful of all). iptables is already included in all official Ubuntu distros and most Linux distros, anyway if you don't have it just install it with aptitude. Adding the following simple rules will prevent leaks in case of [accidental] VPN disconnection. In this example, it is assumed that your network interface is eth+ (change it as appropriate; for example, you might have wlan0 for a WiFi connection). a.b.c.d is the entry-IP address of the Air server you connect to. You can find out the address simply looking at the line "remote" of your air.ovpn configuration file. In case of doubts, just ask us. Some of the following rules might be redundant if you have already chains. Assumptions: you are in a 192.168.0.0/16 network and your router is a DHCP server. You have a a physical network interface named eth*. The tun adapter is tun* and the loopback interface is lo. iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #allow loopback access 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 iptables -A INPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT #make sure that you can communicate within your own network iptables -A OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT iptables -A FORWARD -i eth+ -o tun+ -j ACCEPT iptables -A FORWARD -i tun+ -o eth+ -j ACCEPT # make sure that eth+ and tun+ can communicate iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE # in the POSTROUTING chain of the NAT table, map the tun+ interface outgoing packet IP address, cease examining rules and let the header be modified, so that we don't have to worry about ports or any other issue - please check this rule with care if you have already a NAT table in your chain iptables -A OUTPUT -o eth+ ! -d a.b.c.d -j DROP # if destination for outgoing packet on eth+ is NOT a.b.c.d, drop the packet, so that nothing leaks if VPN disconnects When you add the above rules, take care about pre-existing rules, if you have already some tables, and always perform a test to verify that the subsequent behavior is what you expect: when you disconnect from the VPN, all outgoing traffic should be blocked, except for a reconnection to an Air server. In order to block specific programs only, some more sophisticated usage of iptables is needed, and you will also need to know which ports those programs use. See "man iptables" for all the features and how to make the above rules persistent or not according to your needs. Warning: the following applies ONLY for Linux users who don't have resolvconf installed and don't use up & down OpenVPN client scripts In this case, your system has no way to process the DNS push from our servers. Therefore your system will just tunnel the DNS queries with destination the DNS IP address specified in the "nameserver" lines of the /etc/resolv.conf file. But if your first nameserver is your router IP, the queries will be sent to your router which in turn will send them out unencrypted. Solution is straightforward: edit the /etc/resolv.conf file and add the following line at the top (just an example, of course you can use any of your favorite DNS, as long as it is NOT your router): nameserver 10.4.0.1 # in order to use AirVPN DNS nameserver 8.8.8.8 # in order to use Google DNS only if AirVPN DNS is unavailable Kind regards

Hello! This explains why the rules did not have the expected effect. ...we don't understand this question, anyway from your paste it appears that the network card you're interested in is the Broadcom 440x 10/100 Integrated Controller. Kind regards

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