Staff

Hello, please input ALL those commands (in that order, starting from ipconfig /flushdns) and send us the output at your convenience. Kind regards

Hello, if DropBox was hogging all your bandwidth, it could have caused a timeout in the TLS "handshake"... just speculation anyway. Kind regards

Hello, your account is now successfully connected, is it alright now? Kind regards

Hello! Your account is still successfully connected to some Air server. Stopping the VPN service will cause the connection to drop... if there's something wrong (for example Tomato does not really stop the service for some reason), go to your "Client Area" while logged in with the same account you use for VPN connection, and click "Disconnect Now" button. Your account will be forcefully disconnected in a few seconds. Kind regards

Hello! With reference to this: https://airvpn.org/faq/locations can you tell us if you need a French server to access some French services only (if any, which ones?) or you need a French server in general? We ask because we have privacy problems with some datacenters we have contacted in France, they seriously fail comply to some of our non-negotiable privacy requirements; on the other hand, such compliance is not necessary for routing servers. Kind regards

Hello, as already quoted, "During SSL/TLS rekeying, there is a transition-window parameter that permits overlap between old and new key usage, so there is no time pressure or latency bottleneck during SSL/TLS renegotiations." By the way, you can use the reneg-sec directive (default is 3600 seconds) to disable it (not recommended). https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage --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.

Hello, do you know whether contents are the same from Sweden, Finland, Norway, Denmark, or not? Kind regards

Hello, yes, understood, all the previous message by a staff member was built assuming your hypothesis was true AND assuming that the final node was monitored as well AND assuming that a powerful correlation system is in place. Sorry if it wasn't clear. Kind regards

Hello! How to determine which versions and service pack levels of the Microsoft .NET Framework are installed: http://support.microsoft.com/kb/318785 How to check your Windows version: http://windows.microsoft.com/en-us/windows/which-operating-system Kind regards

Hello, does anybody else experience the same problem? Currently no problems are reported, neither from users nor from our monitoring system. Kind regards

Hello! Not really, furthermore there are crucial missing data, among which, relevant to this argument: correlations. Are correlations performed? If so, how? Assuming that a certain degree of correlations is actually performed, for example (just an example) timing attacks against a datacenter, some precautions are necessary to transmit sensitive data or anyway to keep the anonymity layer: connect to a VPN server which is located outside your country and outside the countries of the adversaries and use end-to-end encryption (to enhance content protection). Additional protection: connect over OpenVPN over TOR https://airvpn.org/tor - then launch a VM and connect the VM over TOR. Finally use only the VM to receive/transmit data, so that: VPN server will receive data from a fixed TOR circuit ; when the data get out of the VPN server, they will enter ANOTHER TOR circuit. As before, end-to-end encryption is applied. In this way you have astronomically high chances to defeat an adversary which is monitoring and correlating connections both from your node AND the destination node; or you can defeat two adversaries that co-operate with each other, one monitoring your node and one monitoring the destination node (which is a worse scenario than that currently one described by the leaks). Content is absolutely protected just by end-to-end encryption; correlations are made extremely difficult, the adversaries should have an incredible stroke of luck in being able to correlate with a high degree of confidence data from two different TOR circuits + VPN server staying in a different jurisdiction. Kind regards

Hello, according to the currently available data, a VPN would be more than enough to protect your privacy against PRISM etc. However chances are that important information are still missing. Besides, some information should be technically clarified. Please read this article, written more than a year ago, to identify which adversaries can be defeated and how: https://airvpn.org/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 Note that the service is able to defeat adversaries with the currently known NSA abilities and adversaries with higher power as well. About the linked articles on GCHQ, according to the currently available information, end-to-end encryption alone (for example gpg for e-mails, encrypted end-to-end VoIP (with keys owned only by the ends, never by the VoIP servers) for voice/video communications) is sufficient to defeat the system on the content side. As a precautionary measure, however, it should be assumed that the effective abilities are higher than those publicly leaked, therefore additional protections should be taken: once the content is protected, a combination of VPN+TOR can be used to prevent the disclosure of the origin of the encrypted content. Kind regards

@Baraka Hopefully momentary problems from your ISP or somewhere between your node and the server. We don't detect any particular problem with that server. Kind regards

Hello, we don't have a routing server in Norway, but we'll discuss about it during the next week. Kind regards

Hello! We're sorry, it's a glitch related to timezones, it will be fixed in the next client release. It does not affect VPN connectivity in any way. Kind regards

Hello StarDuck, we confirm that Winpkfilter is not included in OpenVPN package. You must have had it from somewhere else. Kind regards

Hello, we don't know the decoder but you can start from here: http://www.sat-universe.com/showpost.php?p=744508&postcount=5 It appears that with Gemini 2 you can run OpenVPN in client mode flawlessly. Our Configuration Generator will provide all the necessary files (click "Advanced Options" then tick "Separate certs/keys from .ovpn files". Keep in mind that: client certificate is user.crt servers certificate is ca.crt client key is user.key Configuration file has a .ovpn extension so you might need to make some adjustment to the .ovpn file (in particular, explicitly declare paths to the certificates and key files). Kind regards

Hello, can you please check that you're running the correct version (matching 64 bit and .NET framework version)? Kind regards

Hello, thanks, but Winpkfilter LightWeight Filter should not be there (we exclusively include the original OpenVPN packages). We'll investigate if they have put that in OpenVPN 2.3.0 for Windows and we'll let you know. Note: we did not refer to Winpkfilter as crapware, we were referring to some network managers which replace Windows network manager. This also reminds us about an important test that you can perform, upgrade to OpenVPN 2.3.2. We will upgrade the package in our web site soon. Kind regards

Hello, perhaps it's a DNS issue. Can you please open a command prompt, issue the following commands and copy and paste the output? ipconfig /flushdns ping 10.4.0.1 ping google.com ping 8.8.8.8 Kind regards

Hello! Winpkfilter has been reported multiple times as causing various issues on network performance. Since you cite Winpkfilter LightWeight Filter you probably have an Asus with a pre-installed Windows. If so, check also for ASUS Network iControl utility and any other crapware Asus installs on its hardware, they are very well known to cause all sorts of network bottlenecks. If not, just ignore that, but anyway check that the manufacturer has not replaced the Windows network manager with some of its software, and in case disable it to make a comparison performance test. Kind regards

Hello, thank you for the information. At your convenience you might like to test also all the other port and protocols (if you haven't already done so since when you disable the filtering tool), on different servers. Additionally, check for packet loss/fragmentation in the OpenVPN logs (feel free to send them to us). Kind regards

Hello! Correct. No. It's necessary to establish a new circuit, so you had better restart the proxy, in consideration of your purpose. In particular, since you want to prevent your ISP to see that you use TOR, always "switch off" Vidalia (or any other TOR proxy) before disconnecting from the VPN, and turn it on only after the VPN connection is established. Kind regards

Hello! There are no problems on the USA servers. You can check anytime the servers status on our real time servers monitor (click "Status" on the upper menu). https://airvpn.org/status Can you please send us your client connection logs? Kind regards

Hello, maybe you're running Tunnelblick 3.2.8 or 3.2.9 which are not compatible with OS X 10.8.x. Feel free to send us Tunnelblick logs. Kind regards