Staff

Hello! It seems there are two problems. First, the TAP-Win32 adapter does not come up properly. This may due to improper installation, deactivation of the adapter or OpenVPN running without sufficient privileges. See here for details and how to fix: http://support.real-time.com/open-source/openvpn/index.html Second, there might be high latency during the handshake, which causes the Replay Window Backtrack. http://openvpn.net/archive/openvpn-users/2004-09/msg00068.html The AUTH_FAILED may be caused by this high latency. Try also to use a TCP port instead of UDP and to switch servers. Kind regards

Hello! From the logs, it seems that the pushed routing table conflicts with your current private subnet. In your home network, do you use private IP addresses that may overlap with VPN IP addresses? See also here: https://airvpn.org/specs/ We're looking forward to hearing from you. Kind regards

Hello! Incidentally, the .zip file prepared by our configuration generator is exactly in the format wished by FEAT VPN, including the suffix for the configuration file inside it (.ovpn). Official web site: http://www.featvpn.com/ Disclaimer: this software has no relationship with AirVPN and has not been tested by AirVPN admins. Kind regards

Hello! You might accuse us to be lazy, but we didn't do anything at all. We could not detect any problem... so it's great to know that the problem solved "by itself". Perhaps it was just a momentary issue on connections between your provider and ours. Kind regards

Hello! Your total available bandwidth is split between all the devices connected to the DD-WRT router. It's up to the router to perform a sort of "load balance" of the bandwidth between all the devices, both cabled and WiFi. Of course, if your desktop is not using bandwidth while you test your laptop, then this is not an explanation. In this case, you should focus on possible bottlenecks toward your laptop. A first-glance difference is the connection type: while the desktop is wired the laptop is not. Try to connect the laptop to the router with the cable used by the desktop to determine whether the problem is caused by the WiFi connection. Kind regards

Hello! The probable cause is that you are mixing OpenVPN usage. If you launch openvpn with "sudo openvpn ..." then you can't stop it by stopping the daemon (simply because there's no daemon managing the connection). To see how to use OpenVPN as daemon and where to put the files in this case: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=242&Itemid=142 Kind regards

Hello! We can see that you have solved the problem, anyway we recommend that you upgrade to OpenVPN 2.2.2 and Air client 1.7 at your earliest convenience. Kind regards

@kafebob Hello! The logs look ok. Can you please make sure that you are not trying to double-connect your account (AUTH_FAILED...)? Kind regards

@rokyn Hello! Port 1337 is used by Tunnelblick, it's ok. From the logs, there's a hint that could point to a known Tunneblick issue: See also http://code.google.com/p/tunnelblick/wiki/cKnown Try to disable connection monitoring. If this does not solve the problem, first of all try to connect with Viscosity, in order to determine whether the problem lies in Tunnelblick or not: http://www.thesparklabs.com/viscosity/ It's closed source. They offer 1 free month evaluation period. We're looking forward to hearing from you. Kind regards

Hello! It looks like a mis-identification by Freenode IRC server of Draconis IP address. Maybe some of our customers abused freenode IRC from it. Here we just want to underline that such Net Neutrality violations are not caused by us. Banning TOR nodes and also VPN exit-IP addresses is a questionable behavior from a service which should aid freedom of expression. You might try to ask for explanations to their support team, in the meantime you can try different Air servers. Kind regards

Hello! Thank you for your purchase. You should have received all the instructions from Bitcoincodes. - register and log in our website https://airvpn.org - while logged in, go to "Payment Plans" https://airvpn.org/payment_plans - pick the subscription type (not recurring) which fits the coupon you have purchased - enter the coupon and click APPLY Your account will be immediately activated to premium status. Please do not hesitate to contact us for any further information. Kind regards

Hello! Can you please send us the connection logs related to the error? Kind regards

@rokyn Hello! Can you please send us the Tunnelblick connection logs? Kind regards

Hello! Connecting TOR over Air is just like connecting any program over Air. First connect to the VPN, then use TOR. Example: first connect to an Air server (without any proxy), then use the TOR browser bundle. Please note that in this case, contrarily to the Air over TOR setup, only the programs which are specifically configured to be tunneled over TOR (for example the TOR browser) will use TOR over Air, all the others will use Air only. Please do not hesitate to contact us for any further information. Kind regards

Hello! About disconnection problems, we are quite famous for the stability of our servers (we have people connected for months without interruption), so we wonder if it's a line problem. If it was the case, you might solve the issue with a connection on a TCP port. Instead, if it is caused by your assigned by ISP IP address rotation (do you have a dynamic IP which changes frequently even if you're connected to your ISP?), then unfortunately there's no solution (IP address frequent rotation is a very effective method to disrupt VPN connections). You are already aware of the thread on how to prevent leaks in case of disconnection. Currently we're not going to discuss any other firewall for Windows, because (unfortunately) all the software firewalls for Windows 64 bit are not safe except Comodo and recently Outpost: http://www.matousec.com/projects/proactive-security-challenge-64/results.php Kind regards

Hello! Our configuration generator lets you pick the port you wish to use for the connection and generate the appropriate configuration file. Otherwise, you can simply edit with any text editor the air.ovpn file. Locate the lines "remote" and "proto" and change them accordingly. For example, if you wish to connect to port 80 TCP, use the directives: proto tcp remote <entry-IP> 80 Also, can you please publish the connection logs? They may be very helpful for troubleshooting. Kind regards

Hello! Please see our real time servers monitor. As an additional information, we can tell you that Vega is in Oregon and Sirius in Virginia. To the best of our knowledge that's not true, can you please cite the laws you're referring to? Please see our Terms of Service and keep in mind that, as far as it concerns ex-ante investigations, we can't give information that we don't have. Both. With single-hop, you have anyway separate entry-IP and exit-IP addresses, to prevent correlation attacks. Multi-hop is achieved with Air over TOR, or Air over some proxy, in order to give a real multi-hop (multi-hopping on servers all owned by the same company would be not really effective, if not totally useless). Yes, please see out Terms of Service. Two certificates and a key. In the next months we plan to add tls-auth key, which is currently unavailable in order not to cut off from access DD-WRT users who use a web interface which does not allow to insert a tls-auth key. The relevant steps recommended by the OpenVPN team in order to harden OpenVPN security have been performed as you might have seen. Spam is a problem and outbound port 25 is blocked, while we don't put any limit on traffic or bandwidth. Limits on bw are purely technical limits of our infrastructure. While we guarantee a minimum of 8 Mbit/s allocated bw per user on the whole virtual network, currently the infrastructure is oversized and is statistically capable (considering the maximum accounts connected at any given time and the average bw request) to provide much more (on 1 Gbit/s servers, at any given time we still have permanently 750 Mbit/s free). We plan to remain with an oversized, redundant infrastructure, adding servers well before we reach capacity. Please see our Terms of Service for forbidden usages and more. Please do not hesitate to contact us for any further information. Kind regards

Hello! Just checked that onion routing works just fine and .onion sites are accessible even with TOR over Air. Since it has always worked for you, it's difficult to say what's wrong. Did you change anything in your setup lately? Can you provide more details? Kind regards

Hello! Please see the FAQ for detailed instructions on torrent clients: https://airvpn.org/faq Also, the fact that everything works great except p2p hints that you are clogging your line with upload speed. This is a typical problem of ADSL lines, so if you have any type of asymmetric line please check whether the upload speed limit in the torrent client is appropriate for the upload capacity of your line (try set it to 70% of the peak up bw of your line). You might not notice this issue without VPN connection, because several ISPs cap p2p uploads, so they prevent you to clog the line with a p2p program. Kind regards

Hello! Instructions to block everything when disconnected from the VPN can be found here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&Itemid=142 If you also wish to kill programs, you can use VPNetCheckMon, a tiny program that kills a list of programs you give it when VPN disconnection is detected. The "Network number" you have to insert in it is "10" in order to allow it to monitor properly the Air connection. VPNetCheckMon has been tested successfully with Air, however this method is deprecated. First of all please try changing connection ports, just in case your ISP caps bandwidth on port 443 UDP, and also test all the servers to determine the one which can give you the best performance. Kind regards

Hello! Thank you for your subscription. No, when you access the website your IP address is not logged. It is displayed on the bottom central box, but not logged. To fight spambots. Captcha are required to write the first 2 messages only. Please do not hesitate to contact us for any further information. Kind regards

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