Staff

Interesting response! How about this senario.1. A court orders the data centre to provide them with logs of all network traffic associated with AirVPN server (source IP address, source port, destination IP address, destination port, time, bytes). Hello! So, they already can see your real IP address in the first place, if that VPN server is the first hop you connect to. So, even if they can't see your real IP address, they can see the exit-IP address of another server of the same company. It can slow it down. OpenVPN over TOR can make it impossible. It is useless in comparison to OpenVPN over TOR. Additionally, OpenVPN over TOR protects you against the VPN provider itself, while multi-hopping to different servers of the same provider does not. Kind regards

@DemonsRuns You mean that you get: RESOLVE: Cannot resolve host address: europe.vpn.airdns.org regardless of the DNS server you query? Can you please give us the list of such DNS servers? We have checked a few minutes ago that the domain name is correctly resolved on every public DNS (except OpenDNS, as usual) we have tested. Kind regards

Hello, please remember to ALWAYS state the exact VPN server(s) name. We can't check if you don't state that, sorry. Kind regards

Hello! The problem is here: 2013-09-18 08:31:14 UDPv4 link remote: [AF_INET]67.215.66.132:443 This is caused by OpenDNS hijacking our *.airdns.org to one of their servers IP address, as if the domain name did not exist. 67.215.66.132 is an OpenDNS server and of course OpenVPN connection fails. You can solve this problem in two different ways: 1) Change DNS (use for example OpenNIC, http://opennicproject.org) and discard OpenDNS once and for all - after all, you might not like to use a poisoned DNS that hijacks your queries 2) Solve the problem at its roots by generating .ovpn configuration files which contain only IP addresses (and not names) in the following way: - in the Configuration Generator tick "Advanced Options" - tick "Resolved hosts in .ovpn file" - tick "All servers for area or region" Kind regards

@nunz Hello! Your account is successfully connected to some VPN server since approx. 15 hours ago. You can see anytime the reason of the last failed connection in your account panel (please click "Client Area" from the upper menu). Kind regards

Hello, some significant advantages of such a setup is the option to keep the whole VM encrypted when it is off, with the additional security that no unencrypted file can ever leak on the host system. These may be extremely important features in some cases (imagine an activist working in a country controlled by a human rights hostile regime). Then there are the 'usual' advantages of a VM: portability (just a file) and isolation of "disasters" in particular. The most important cons you have to consider are: more resources required from the host, slower performance of the guest system (mitigated if you have a CPU supporting hardware virtualization). However, setting up a firewall will be necessary anyway to prevent leaks in case of unexpected VPN disconnection. If the VM is connected to the host machine via NAT, the firewall settings may be simpler on the host side. If the VM is attached to a bridged network adapter, firewall rules will be necessary on the VM itself. You have also another option, i.e. connecting the host to a VPN server, and attaching the VM via NAT to the host. In this case you always need firewall rules on the host side, and all the VMs will have their traffic tunneled 'transparently'. This setup can be additionally hardened (under a security point of view) by connecting the VM itself to TOR or to another VPN, to obtain (in the VM) a multi-hop connection (traffic over VPN1 over VPN2 for example) with multiple layers of encryption at the price of a remarkable network performance decrease. Kind regards

Hello! Yes, port 9150 is the default SocksPort in the TOR proxy bundled with the latest TBB versions, other packages can have the TOR proxy configured to listen to port 9050 or other ports, please check. Kind regards

Hello! Can you please publish the Tunnelblick logs, taken after the problem has occurred? Kind regards

Hello! By default (when you register an account) it's already off. You must specifically turn it on if you wish it. It can be useful for troubleshooting, in case of issues, or to monitor the traffic volume (for example for users on a traffic-volume-limited connection). Kind regards

Hello! When you connect OpenVPN over TOR, if you run a browser that's configured to connect over the same TOR proxy which OpenVPN connects to, that browser traffic will be tunneled over TOR only. In order to tunnel a browser traffic over OpenVPN over TOR, first connect OpenVPN over TOR, then run a browser that is NOT configured to connect to the TOR proxy. In order to tunnel a browser traffic over TOR over OpenVPN, first connect OpenVPN directly (i.e. NOT over the TOR proxy), then launch TOR and use a browser that IS configured to connect over the TOR proxy. With OpenVPN over TOR our VPN servers can't see your real IP address and the TOR nodes can't see your traffic. Your packets "get out on the Internet" with the VPN server exit-IP address. With TOR over OpenVPN our servers can't see your traffic and the TOR entry-node can't see your real IP address. Your packets "get out on the Internet" with the TOR exit-node IP address. Kind regards

Hello! Ok. Please remember that you need to run OpenVPN GUI with administrator privileges. From the piece of log you sent us, OpenVPN had "access denied" to interfaces. Kind regards

Hello! Why? It's not necessary at all to keep logs for those stats. You just increase counters of servers and accounts when they are online, when they disconnect they are lost. Kind regards

Hello! Apparently your local proxy is not running or not listening to port 9150, can you please check? Can you tell us which proxy are you running, is it a TOR proxy? Kind regards

Hello! The percentage shows the BUSY bandwidth on a server. Please do not pick 100% bandwidth busy servers. Kind regards

Hello! We're very glad to inform you that a new 100 Mbit/s server located in France is available: Furud. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Furud supports 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! Is the Verizon DNS inserted somewhere in your router or in the device used to perform the DNS check? If so, wipe it out. Kind regards

Hello! Assuming that you use the Air client: - in order to change port, after you have picked a server click on the "Modes" tab, select a port and protocol (for example 53 UDP) and click "Enter". - in order to send us the logs, please right-click the Air dock icon (a white cloud), select "Logs", click "Copy to clipboard" and paste into your message. Kind regards

Hello! Yes, that's normal: in your case OpenVPN is commanded by the Air client, not by OpenVPN GUI. In reality, you should not even launch OpenVPN GUI and the Air client simultaneously. Just run whichever you prefer, but not both at the same time. That's normal, it's an old-time Windows glitch based on an unreliable method to determine whether a connection is working or not. The 10 Mbit/s value is just a bogus hard-coded parameter (it's there since so many years in OpenVPN tun/tap package), it does not mean anything. The tun/tap adapter is the virtual network interface used by OpenVPN. Kind regards

Hello! First of all, please try connections to different servers AND different ports. In particular, please test port 53 UDP and 80 TCP. Can you also please send us the client connection logs? Kind regards

Hello! Can you please send us the Air client logs taken just after the problem occurs? Please right-click on the Air dock icon (a white cloud), select "Logs", click "Copy to clipboard" and paste into your message. Kind regards

That sounds very unlikely. I use ufw on Linux with 2 extremely simple rules. Allow out anything on tun0 and allow in from anywhere to port xxxxx on tun0 (where port xxxxx is the one I open and forward to use in Transmission). Otherwise all packets are dropped. That's all. I can post my exact rules if you'd like. Hello! The problem is here (or at least part of the problem). You should allow anything to tun0 on all ports, because you can't foresee which source port will be used by any application (remember that tun0 is the virtual interface used by OpenVPN, where packets are still/already unencrypted). So in several circumstances you actually block everything except incoming connections to Transmission from the Internet. But tun0 must also communicate with eth+ or wlan+. According to the exact rule definition, it might even block communications between eth+ (or wlan+) and tun0, causing a total tunnel disruption, and that would also explain the apparently erratic behavior you observe. There is one more thing to check, i.e. if there are packet inspection tools on the router which could trigger a traffic block in case of elevated UDP traffic, but this is most probably not the case, because the ultimate proof is that when you disable ufw everything works fine. Kind regards

Hello! That's not necessary, our TLS web server implementation includes Perfect Forward Secrecy, so a different TLS key is negotiated (through ECDHE or DHE, according to your browser) with airvpn.org server at each SSL/TLS connection (provided that you don't run an obsolete browser or IE 8 in Windows XP). The underlying preferred encryption is AES-256 (but you can change your preferences on the cipher from you browser) making any attack revealed by the recent leaks ineffective. Please check here: https://www.ssllabs.com/ssltest/analyze.html?d=airvpn.org Anyway you can change your web site password as many times as you wish from your control panel. Yes, until the account subscription expires or you explicitly require account de-activation. Kind regards

Hello! Ok, another of our DNS servers runs on 54.246.124.152, it is a failover DNS in case the first VPN DNS server fails. So it's not a leak. However, you should see it only when the first DNS fails. It remains to be seen why ipleak.net does not display it and dnsleaktest.com does. From various tests, dnsleaktest does not display it (at moment of this writing) from Cephei. Maybe 184.75.214.163 DNS failed just when you run the test, causing the query to be sent to the "backup" DNS. We will investigate, anyway no action from your side is required and no DNS leak is occurring from your system. Can you please tell us whether you get those results on a regular basis? If so, can you please try to delete "10.5.0.1" and "10.6.0.1" (using therefore only 10.4.0.1) and test again? Kind regards

Hello! 1) This is typically caused by ISPs which hijack packets to port 53 UDP to their own DNS servers (for example Vodafone Italia). 2) As far as we can see, most firewalls do not cause any performance hit, provided they are not configured to inspect packets or to log excessively. Packet inspection of encrypted packets can cause heavy system load (and it's not useful, because the packets are encrypted). Can you please tell us which firewall you disabled to have better performance? Kind regards

Hello! The discrepancy is very strange. Is the 2nd DNS displayed by dnsleaktest a "plausible" one? We'll need to investigate on the matter. In the meantime, can you please tell us your DNS settings in your DD-WRT router? Kind regards