Staff

Hello! We're very glad to inform you that a new payment processor for Bitcoin is available: BitPay. From now on, you can more comfortably pay in Bitcoin with an automated order in our web site. During the checkout, just select "Bitcoin (via BitPay)" and follow the quick & easy instructions! Paying in Bitcoin effectively enhances your privacy and improves the anonymity layer provided by our service. We would like to remind you that ONE and ONLY ONE authorized AirVPN reseller currently exists (12-Feb-2014), bitcoincodes.com. Anybody else selling or proposing AirVPN subscriptions or selling coupon codes is NOT authorized by us (12-Feb-2014). Kind regards and datalove AirVPN Staff

Hello! First of all, let's clarify the units for every reader. MB: Megabyte Mbit: Megabit s: second 1 Byte = 8 bit 1 MB/s = 8 Mbit/s Assuming a good quality line and low latency from your node to the VPN server (if you have high latency, for example with a satellite connection, then you will be unable in any case to get stellar performance with OpenVPN), a couple of possible reasons for poor performance are: 1) Traffic shaping. In the past years many ISPs (the majority in the world) have performed wild overselling, promising peak bandwidth performance that they could deliver constantly only if a tiny fraction (1% of even less) of their customers were connected simultaneously. They now prefer to shape traffic on almost everything instead of investing in infrastructure expansion. Comcast performs traffic shaping. In the European Union, an ISP is obliged by law to tell you if it performs traffic shaping or applies any other technique limiting your usage of any service or protocol, but not in the USA. https://airvpn.org/topic/10967-slow-airvpn-speeds-050mbs-down-or-less/?do=findComment&comment=15358 2) Wrong MTU size, so that you get packet fragmentation that hits performance. Possible solutions to problem 1 are changing connection ports (try in particular port 53 UDP) and switching to a protocol which might be less capped than another, for example by trying OpenVPN over SSL if you see that your "https traffic" is not as slow as pure OpenVPN traffic. A more effective solution might be changing ISP with one that can deliver what it advertises. Solution to problem 2 is changing the packet size with mssfix. Do not change TUN MTU size with directives "tun-mtu" and/or "fragment"! Without a corresponding change on the server side, doing that would have unpredictable effects and might also prevent a connection. Change it by using "mssfix" only. Start with "mssfix 1350" and test, then increase or decrease the size with little steps, re-testing each time. Please note (important) that mssfix directive makes sense only in UDP mode. On the www you can find also good methods which help you determine the correct value in order to speed up the trial-and-error process. See for example here for some more information and details http://www.dslreports.com/faq/695 Once again: do not touch the MTU of your physical or virtual network cards (unless you exactly know what you're doing), just operate through the OpenVPN directive mssfix. Kind regards

Why do I have to pay transaction fees on Bitcoin transfers? Why do I get the message "This transaction is over the size limit. You can still send it for a fee of 0.0005 BTC"? For transactions which draw coins from many bitcoin addresses and therefore have a large data size, a small transaction fee is usually expected. The transaction fee is an incentive on the part of the bitcoin user to make sure that a particular transaction will get included into the next block which is generated. See also https://en.bitcoin.it/wiki/Transaction_fees

Hello, Autoconfiguration" IP Addresses: 169.254.0.0 - 169.254.255.255Addresses in the range 169.254.0.0 to 169.254.255.255 are used automatically by most network devices when they are configured to use Internet Protocol, do not have a static IP Address assigned and are unable to obtain an IP address using DHCP. Please see also RFC-1918. http://www.iana.org/help/abuse-answers Kind regards

Hello, we do not detect any problem on Singapore servers, is there any feedback from customers living in some Asian country? Feel free to post! Kind regards

Hello, is the DD-WRT router behind some other network device? Kind regards

Hello! We're very glad to inform you that two new 1 Gbit/s servers located in Virginia, USA, are available: Electra and Kuma. The AirVPN client will show automatically the new servers, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The servers accept connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Electra and Kuma support OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello, performance improved probably because your ISP performs traffic shaping on a port/protocol-basis or deprioritizes certain packets. UDP traffic to port 53 is less likely to be capped or deprioritized because it is normally made of DNS queries. Anyway, what you experience is a hint of possible illegal behavior from your ISP, IF you live in the EU and you have not been informed in a clear, comprehensive and understandable way in the contract about limitations on services and protocols (when such limitations are allowed by national and Community laws). Please see Directive 2009/136/EC (amending directive 2002/22/EC article 20): 14) Articles 20 to 23 shall be replaced by the following: ‘Article 20 Contracts 1. Member States shall ensure that, when subscribing to services providing connection to a public communications network and/or publicly available electronic communications services, consumers, and other end-users so requesting, have a right to a contract with an undertaking or undertakings providing such connection and/or services. The contract shall specify in a clear, comprehensive and easily accessible form at least: [...] — information on any other conditions limiting access to and/or use of services and applications, where such conditions are permitted under national law in accordance with Community law, [...] — information on any procedures put in place by the undertaking to measure and shape traffic so as to avoid filling or overfilling a network link, and infor­ mation on how those procedures could impact on service quality, Kind regards

Hello, just an additional note to the above: in checkmytorrentip, from our USA servers, you will see a different IP address, because the traffic is re-routed (this is performed to bypass a lot of trackers problems we were made aware of in the past, so for consistency the traffic is re-routed even to the checkmytorrentip address). Just make sure that your real IP address never comes out in the test. Kind regards

Hello! Generally not. Please see https://airvpn.org/faq/udp_vs_tcp Since you report that you have erratic perfomance, we can rule out ISP traffic shaping. Logs taken after a couple of hours of a connection could help to determine whether the problem is caused by packet loss and/or packet fragmentation (in which case it is possible to intervene) or not. Also, this behavior (performance with wide oscillations) is typically experienced in low-signal WiFi connections and high latency connections, such as satellite connections. The recommended server is the server with the highest rating determined as the outcome of a formula which includes parameters such as available bandwidth, server status, server packet loss to/from all the other Air nodes, latency to/from all the other Air nodes. Kind regards

Hello! Given that you experienced lower performance suddenly, and that the available bandwidth and the overall performance of our service increased very much recently, maybe your ISP started traffic shaping. Have you tried to connect to different VPN servers ports? If not, please test port 53 (UDP) to begin with. Kind regards

Hello, "Adaptive" can be the best solution, although your device will work in any case. Kind regards

Hello, the MTU size looks wrong. Please make sure that you pasted certificates and key properly and that cipher suites are correct. If in doubt please feel free to open a ticket including a screenshot of your OpenVPN client configuration page. Kind regards

Hello, however it does seem a problem of date: in 1970 the certificates were not valid. Anyway the full logs can be more helpful. Kind regards

Hello, yes, it is working. Please note that your account, lacking a subscription, is not authorized to access the CG. Kind regards

Hello, there is no such leak "from OpenVPN", or "from an OpenVPN client", they have nothing to do with anything of that. "DNS leaks" are a direct consequence of Windows buggy DNS implementation and lack of concept of global DNS. Kind regards

Hello, we do not detect any problem on Singapore servers. Kind regards

Hello, yes it definitely looks like a DNS issue, please check the content of your /etc/resolv.conf file and also see here to accept VPN server DNS push: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf Kind regards

Hello, increasing the replay window may be a very bad idea if it is a real replay attack. Please see here https://airvpn.org/topic/3773-pls-help-strange-logs/?do=findComment&comment=3784 Kind regards

Hello, we are aware that the Configuration Generator is not working properly and we are working to restore it. We apologize for the inconvenience. We will keep you updated on this thread. EDIT: problem fixed. Kind regards

Hello, we'll be looking into the issue, in the meantime please stop posting duplicate messages. Use any NON USA server for Hulu. Kind regards

Hello! It might be a DNS issue, can you please publish the output of the following commands: ping -c 4 google.com ping -c 4 8.8.8.8 ping -c 4 10.4.0.1 Kind regards

Hello! That's because we thought to leave that task to the server DNS push, that your client is free to accept or not (well, in Windows the DNS push is accepted by default, in Linux and *BSD it's not considered by default), but that's a good idea anyway, thank you. Kind regards

Hello, it's extremely trivial for a web server or a p2p client. The attacker just sends packets to the same port both to your ISP assigned IP address and to the VPN server exit-IP address and compares the result. If the victim service replies to packets on both the IP addresses (because the same inbound router port is open) and those replies are consistent (as they are, obviously) both in timing and content, then the attacker have a proof (usable in courts but also useful to criminal organizations etc.) that that service is run by you. No: the first attack condition is already that the attacker is wiretapping your line. If the service does not reply to packets to your real IP addres, no correlation proof is possible and the attack fails: it is not possible to prove that a certain service is run by you. The primary point is exactly to defeat those who are wiretapping your line. However, as a secondary but not less important point, there are more subtle attacks which allow an attacker to establish correlations even if that attacker is unable to monitor your ISP line. All of these attacks are possible only with the misconfiguration of your system, as already said over and over. Kind regards

Hello, no, totally false. The real risk is much higher. As it has been already explained, the exploit can be performed when the system is properly connected to a VPN server and properly tunneling. The consequences of the attack are that your real IP address is discovered and all the p2p activities or the activities of the service behind the VPN server are related to your REAL IP address. In order to avoid that, do NOT forward ports on your router, or at least close those ports on your physical network interface with a properly configured firewall, or bind the service to the tun/tap interface (but not all services can be bound to a specific interface). Be careful, this is NOT a fault or a problem of OpenVPN, this is a deliberate vulnerability that you voluntarily insert into your system: your system just complies to your orders and OpenVPN can't protect you against your own behavior. Kind regards