Staff

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

Hello, you're right, there's some confusion about it. The tutorial is correct but not entirely: some builds must be configured in that way, although TLS-Auth is "None" in our service. But if you set "None" on those builds, OpenVPN will inexplicably fail to maintain a stable connection, as if some different TLS-Auth parameter is passed to OpenVPN. We see that newest builds work just fine with the correct setting. On yet some other builds, the setting must be forced in the nvram (with a simple command). Usually this is not needed, we have met this necessity only on very old builds. So, please try to set it to "None". If it fails again, feel free to write back and we'll show how to set the proper setting directly, by bypassing the interface. Kind regards

Hello, tray icons are usually on the taskbar (the same bar where you can see the "Start" or Windows logo button). The Air client tray icon is a white cloud on a gray (or blue, if connected) sky. If the Air client tray icon is not there, expand the tray icons section by clicking the arrow symbol. If it's still not there, then the Air client is probably not running. Kind regards

@pxmjd Hello, be patient, we'll make an announcement soon. We are aware that Eddie development is terribly late with delay after delay since the announcement in April 2013, and we're working to fix the situation. In the meantime, please spend 10 seconds of your time to 'fix' the flawed DNS implementation in Windows (if you run Windows). Kind regards

Hello, we do not provide a SOCKS proxy in our service but you can connect OpenVPN over any SOCKS or http proxy. See here for an example: https://airvpn.org/tor If you need to connect an external proxy over OpenVPN, then you don't need anything special, just connect to a VPN server, then "proxify" the applications whose traffic you want to be tunneled over AirVPN over a proxy. On the contrary, if you wish OpenVPN to connect over a proxy, then you need to configure OpenVPN to connect over that proxy according to the aforementioned example. Kind regards

Hello, please enable the TUN/TAP adapter (the interface used by OpenVPN) in the Control Panel and make sure that you run only one instance of OpenVPN. The interface name is "TAP-Win32 Adapter ...". See also here: https://airvpn.org/topic/9988-airvpn-failed-to-start/?do=findComment&comment=13089 Kind regards

Hello, certificates and key are embedded in the .ovpn files. From the error message, maybe you're making some mistake during the installation of the .ovpn file. Can you please try the classical old, safe method according to the instructions? For example create a folder on the Destkop (example: "blabla"), paste one (and only one) .ovpn file inside it, rename the folder with a ".tblk" extension (so it becomes "blabla.tblk") and double click on the folder icon. Kind regards

Hello, your account needs a subscription. Accounts without a subscription can't access the Configuration Generator. Kind regards

Hello! In the username please use characters included in [a-z], [A-Z] and [0-9] sets. About the password, please use passwords not longer than 32 characters. While we have foreseen longer passwords, the authentication method still shows problems with longer than 32 characters passwords. Anyway, a "good" password with just 16 characters is extremely strong already. Kind regards

Hello! Is the .NET framework on the laptop up to date? Please see here about your problem: http://support.microsoft.com/kb/915599 and possible solutions. If every Microsoft suggested bug-fixes fail and your framework is up to date, you can anyway run OpenVPN GUI instead of the Air client. Kind regards

Hello! The directive for the renegotiation time is reneg-sec. We don't know whether it's possible to assign this custom directive with Viscosity (probably so, just add it on the .ovpn file with the custom directive option in the Configuration Generator or with a text editor and test). Default in our servers is 3600 seconds. You can't go over this value but you can go below. The "overlying" RSA keys sizes (2048 bit) can't be modified by you. See the OpenVPN manual: --reneg-sec n Renegotiate data channel key after n seconds (default=3600). When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour. Also, keep in mind that this option can be used on both the client and server, and whichever uses the lower value will be the one to trigger the renegotiation. A common mistake is to set --reneg-sec to a higher value on either the client or server, while the other side of the connection is still using the default value of 3600 seconds, meaning that the renegotiation will still occur once per 3600 seconds. The solution is to increase --reneg-sec on both the client and server, or set it to 0 on one side of the connection (to disable), and to your chosen value on the other side. Kind regards