Staff

Hello! Security and privacy on the Internet, as well as in life, require a continuous process of information and education. We do our utmost best to provide a strong anonymity layer, however (as we write in our ToS) a VPN secures your connection, not your computer or your behavior. We don't agree, the system has been designed to destroy correlations between the purchase and an account. When you buy a subscription with BTC, in reality you buy a code from a completely independent reseller (bitcoincodes.com). Then you use that code to activate any account on our website, so there is no correlation between the purchase of BTC through other currencies and/or the purchase of a code, and a premium account on the VPN. The following post may be what you're looking for. It describes how to preserve a strong anonymity layer in the worst case scenario: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=54&limit=6&limitstart=6&Itemid=142#1745 Kind regards

Hello! Please replace that link with this one: https://airvpn.org/tor Kind regards

Hello! Draconis is up and running again. Kind regards

Hello! You're correct, Draconis has been temporarily withdrawn form the servers list due to instability. It suffered a second crash today, after a critical crash yesterday. We are investigating with the help of datacenter support in the hope to bring it up again in a short time. Kind regards

Hello! Since pinging 10.4.0.1 is successful, we could suppose it's a DNS resolution problem, although the routing table apparently shows further problems. Please force your system to use 10.4.0.1 as primary DNS (leave your favourite DNS as secondary) to see whether it fixes the problem. Please note that 10.4.0.1 is your VPN DNS only if you connect to port 443 UDP: https://airvpn.org/specs Kind regards

Hello! You might like to switch to Comodo (for which full instructions are provided in this forum) or ask for support from G-Data Internet Security support team. And yes, DNS leak is a typical Windows problem, not a Linux or BSD one (Mac OSX has been built on BSD - quite funny in the light of the Apple wars against free and open source software ), because Windows allows each adapter to have its own DNS. Kind regards

@locksmith Hello! There are major problems in the routing table when you're connected to Lyra. Why you have this issue only with Lyra and with no other server is still an "enigma". Can you figure out any difference in the connections? Kind regards

Hello! You should block packets with destination port 53 UDP, not 55, and only from your physical interface. Do not block traffic from your TUN/TAP interface, otherwise your system will not be able to send out DNS queries, not even when connected to the VPN. Kind regards

Hello! In the logs there are hints that the routing table is ignored. In any other server connection logs (the servers with which you have no problems), do you have something like: ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=xx and dwForwardType=x after each route.exe command? Can you please send us the routing table after the connection to Lyra? Can you ping 10.4.0.1 after the connection to Lyra? Can you confirm that the IP address of your router is 192.168.1.254? Kind regards

Hello! We confirm there are no problems on our side with Lyra. Several clients are connected and exchanging data. The server is correctly responding on all ports and properly routing packets. Average load is practically 0. Can you please send us the connection logs? Kind regards

Hello! On top the good solution by worric, if you use the Air client you might like to add to your hosts file the line: 46.105.19.36 airvpn.org This is because when you are not connected to the VPN your system will not be able anymore to perform DNS resolution, preventing Air to connect via SSL to our frontend (airvpn.org). airvpn.exe connects via SSL/TLS to airvpn.org in order to provide some commodities and download certificates, key and generate on the fly a configuration according to your choices. With the addition of that line, your system will not need anymore to send a DNS query to resolve airvpn.org. If you use OpenVPN directly, or any other OpenVPN GUI/wrapper, you don't need that (all the files you need are already in your HDD, while the commodities are available on our website). Kind regards

Hello! To the best of our knowledge you are right. This is a good question to ask to the Bitcoin support. However, a suggestion for the really paranoid people (almost like us ): buy the coupon code with a dedicated wallet only used over TOR and filled with only the exact amount you need, then (once you have received the coupon and you have managed to activate your account) securely delete that wallet. Kind regards

Hello! Please follow the instructions and make sure that your proxy is a SOCKS proxy (not http) and it is running and listening to port 9001 (which is not the default port the SOCKS proxy listens to on the latest TOR browser bundles). https://en.bitcoin.it/wiki/Tor Kind regards

Hello! Currently the recommended bundle by the Tor Project is the Tor Browser Bundle which uses a SOCKS proxy. It's not that the Bitcoin client has TOR integration, however it can be easily configured (in the settings menu) to use a proxy. Anyway, it is not a matter of concern for the Bitcoin client: the problem was that DNS queries for websocket connections were not made by the proxy. You might also like to read here: https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#IkeepseeingthesewarningsaboutSOCKSandDNSandinformationleaks.ShouldIworry The problem about DNS leaks should be taken seriously with Firefox (and perhaps other browsers). For this reason, the Tor Project updated their bundles with a very important security release on May the 4th, 2012: https://blog.torproject.org/blog/new-tor-browser-bundles-security-release Further considerations: https://lists.torproject.org/pipermail/tor-talk/2012-May/024155.html All of the above does not apply if you tunnel over Air over TOR, however we very strongly recommend to keep your Tor bundle up to date just in case you need to use Firefox over TOR without Air. Kind regards

Hello! A general solution is layer 7 filtering on your physical interface (so that p2p will be blocked only when you are not connected to the VPN). pf is perfectly capable to do that, but it's not an easy solution. Since you want to block "yourself", you don't have to bother about all the possible cases. You can just block all and every port used by your p2p client (either with a "whitelist" or a "blacklist") on your physical network interface, so the p2p client will be able to send and receive packets only through tunx. Kind regards

Hello! You can also accept BTC for (some of) your work / sales / services or anything else you do in your life. Usually this is the easiest way to earn BTC. About anonymity, we recommend you tunnel your Bitcoin client over TOR (the default client has an immediate option to do that). If you feel that your wallet compromise your anonymity, just use another one to subscribe to the VPN. You have no limits on the number of wallets, obviously, and you can transfer anonymously BTC from a wallet to another. Kind regards

Hello! You're welcome. Just for your and other readers information, a quick clarification (otherwise someone might think that security is compromised). The router might be the cause of such dramatic fluctuations, but not for the number of connections. The router sees only one connection on one port. The effective number of connections are handled on one side by your OpenVPN client and on the other side by our servers. The "real" headers and payload of every packet (both outgoing and incoming) are already/still encrypted when passing through the router, therefore they are not accessible to it. You might like to check the CPU load on your computer when you experience a bandwidth drop, just to see if there's some bottleneck on the OpenVPN client side (our servers have usually an approximate 0 average load). Kind regards

Hello! AndyG, should you use OpenVPN in DD-WRT with your router you should expect 7-8 Mbit/s at best, due to CPU power as explained by yerozard. 20 Mbit/s on Draconis with a connection from your computer appears perfectly normal. You have to also consider that the 70/10 Mbit/s provided by your ISP are the maximum peak bandwidth you can obtain, not a guaranteed bandwidth. Routing and peering are to be taken into consideration. That said, please test all the other EU 1 Gbit/s servers (Tauri, Castor and Delphini) to check whether you can obtain a better performance. All of them are located in data centers with POPs directly connected to all the major tier1 EU providers (including the "big four"). Please feel free to let us know your experience with the above servers. Kind regards

Hello! Usually this is a problem with some firmwares, and the solution is flashing a newer firmware. However, the quoted log line poses some questions. Can you please tell us what the address 10.2.1.2 is? Is it the router's address? The remaining log looks just fine (apart, of course, the series of connections and disconnections). Also, your DD-WRT router is using tun1 interface. Therefore, you need to modify accordingly your iptables rules, because in our examples we assume tun0 as the interface managed by OpenVPN. Kind regards

Hello! AirVPN Client requires the .NET Framework 2 (not 4). This framework is pre-installed in XP and above, but maybe you use a minimal XP. Try to download and install Framework 2 from here: http://www.microsoft.com/en-us/download/details.aspx?id=19 Kind regards

Hello! Can you please send us the failed connection logs? Kind regards

Hello! First, please keep in mind that the Air client is for Windows only. For other OS, you can use OpenVPN directly or any OpenVPN GUI/wrapper. You have at least two options. 1) Tunnel your host over Air over TOR and connect the guest(s) with the VirtualBox NAT (not bridged). In this case all the guests will be tunneled transparently IF they are connected with the VirtualBox NAT. You'll need to install OpenVPN and Tor Browser bundle in your host. Also, you'll need to forward ports in VirtualBox NAT to make your guest capable to use the remote port forwarding feature of our system. You'll just need one account. 2) Tunnel your guest over Air over TOR. In this case only the guest (regardless whether it is bridged or NATted) will be tunneled over Air over TOR, while the host will not be tunneled, not even over Air. You'll need to install OpenVPN and Tor Browser Bundle in each guest. Also, you'll need a different account for each guest which connect simultaneously. Kind regards

Hello! We're very glad to know that you could manage to solve your problem. Yes, if this setup works on your system, it's not worth to modify anything. It already works in this way. However, your tun interface must be able to send and receive packets from/to any IP through your physical adapter, and the physical adapter only sees packets that have "real" header and payload already encrypted. When there's a VPN disconnection, the original routing table is restored. Therefore the "key factor" to prevent leaks is that your physical adapter must be authorized to communicate only with our VPN servers, so Comodo needs to know the entry-IP addresses of the servers. A different solution with Comodo is allowing outgoing packets only if coming from the tun adapter (i.e. only if coming from the IP range 10.4.0.0->10.9.255.255), as it has been described in the main thread. In this case, you don't need to set rules for your physical adapter, but you'll have to configure every and each application that you use (or any relevant application) and system applications (especially svchost.exe, to prevent DNS leaks) with the above rule. This is a solution particularly suitable for clients who just want to block certain traffic (for example p2p) while allowing other traffic when disconnected from the VPN, so probably your current setup is the one which really meets your requirements. Kind regards

Hello! We re-send you a synthesis of our replies here in the forum for your comfort. The logs show that you have been connected without interruptions for several hours (since 5:59 AM till 6:40 PM). The connection was working because, as you can see, OpenVPN renegotiated successfully the TLS key every hour, as it is expected to do with our configuration. The TLS key renegotiation is an additional OpenVPN security feature which causes no delays in the connection, since the key renegotiation is performed with "overlapping windows" (another nice OpenVPN feature). After the disconnection, caused by an intervention on your system, your system could not resolve "airvpn.org" in order to reconnect, a problem you can immediately solve (instead of changing Comodo rules each time) by editing your hosts file, just add the line: 46.105.19.36 airvpn.org Kind regards

Hello! We confirm that our setup uses a TUN interface (routed VPN), not a TAP one (not bridged VPN). The name of the interface can vary according to your system setup, by default anyway it's tun0. When writing such an application, the key problems to consider are the time between disconnection detection and applications kills or disconnection. We have seen some utilities for which such time is enough to potentially allow leaks. If you opt for application kill, another consideration is the "violence" of the technique, which potentially may result in lost or corrupted data. Kind regards