Staff

Hi, why "partial"? Kind regards

Hello! Thank you for the information. We need to investigate and check. In the meantime enable DHT+PEX, you really don't need trackers. Kind regards

Hello, please use OpenVPN directly, OpenVPN GUI or any other OpenVPN wrapper while we investigate the issue. The files for those can be generated in "Client Area"->"Config generator". Kind regards

Hello, deletion of file C:\Users\XXXXX\Downloads\AirVpn\AirVPN.xml does not solve the problem? Kind regards

Hello! They show the current busy bandwidth for each server (updated every 60 seconds). 0% -> all bandwidth is free - 100% -> server is at capacity. Percentages above 100% show that the server "is bursting". Kind regards

Hello, problem solved with a new routing GB server, we could not wait for an inefficient provider. Kind regards

Hello! Can you please send us the Air client logs taken just after the problem occurs? Kind regards

Hello, the problem is shown here can you please check your Internet connectivity when that occurs? Kind regards

Hello, datacenter solved the problem on Pavonis. Useful tools to check the servers status are the Status page (click on "Status" on the upper menu) and the Ping Matrix (linked inside the Status page). Kind regards

Hello, the certificate SHA1 fingerprint you report 'from Sirius' is the airvpn.org certificate -expiring May-31-2013- fingerprint. The new SHA1 fingerprint, correctly reported by grc, is the fingerprint of the certificate expiring on May-31-2014. The old certificate is currently installed ONLY on our 'non-public' NL frontend. From Sirius DNS, and from any other AirVPN server DNS server, airvpn.org correctly resolves to 95.211.138.143, our primary and public frontend. Maybe you have multiple entries of airvpn.org (which is good!) in your hosts file which include the non-public frontend IP address. We will update the certificate in that non-public frontend within May-31-2013. Kind regards

Hello! The server in itself works, but has more than 70% packet loss which makes it unusable. It's a problem in the datacenter unfortunately. Check the servers monitor ("Status" from the upper menu). Kind regards

Hello, that's correct, please check the servers monitor ("Status" from the upper menu). EDIT: the anti-geo block for BBC will be re-enabled as soon as the UK routing server datacenter solves the server issues. Kind regards

Hello! Only one concurrent connection per account is allowed. Kind regards

Hello! It's because OpenVPN client needs to access directly network cards settings, modify routing table and default gateway. Kind regards

Hello, the problem is here: Try to run OpenVPN (or OpenVPN GUI) with administrator privileges. Kind regards

Hello, no, you don't, please read all the FAQ starting from here: https://airvpn.org/faq/what_is/ Kind regards

Hello! Can you please send us the client connection logs of the Windows system(s)? Kind regards

Hello, thank you for your inquiry with Comcast. Feel free to keep us updated. Just an additional note (very unlikely it may help you, but it's worth checking), we have seen in the past the some custom network managers pre-installed on Windows by a computer manufacturer (we had (very few) cases with Asus and Acer) impair OpenVPN connections performance (for unknown reasons). Re-activating the default Windows network manager solved the problem. Kind regards

Hello! Thank you for your inquiry. You can subscribe to a plan. The Configuration Generator is reserved to Premium members (any subscription plan). Kind regards

Hello, your account is successfully connected to some server. Please note that you can't connect to different servers with the same account simultaneously. Kind regards

Hello! Additional note: can you please try a connection with any antivirus, packet filtering tool (firewall etc.) disabled? Kind regardas

Hello! To keep you informed: the problem appears quite complex and we're still investigating. One of the backend servers stopped working for a kernel panic (the causes of which are still to be determined). When this happens the VPN servers simply can switch to another backend server with no strict time pressure. However, in this case, lots of OpenVPN daemons (especially those for port 443 UDP) on many different servers crashed, causing disconnections to the clients (if this did not happen, you would have not noticed anything - this is the major issue in our point of view, why so many OpenVPN daemons crashed all at once) and of course preventing re-connection. Additionally, since the VPN servers were still working, the remaining working backend servers did not consider any of them as "dead", and therefore did not release the connected accounts, causing another impossibility to re-connect. Finally, about the button "Disconnect Now"... it did not work, because the command has remained "stuck" to the non-working backend server (no backend switching on the frontend occurred). Now that we have re-built the chain of events (which anyway were solved in less than 20 minutes) we are proceeding with further investigation. Kind regards

Hello! It was a problem on our side, now it's solved. We'll post an update on the forum when our investigation on the causes ends. Kind regards

Hello! It was a momentary problem, can you please try again now? We'll post updates when our investigation on the causes of the problem ends. Kind regards

Hello! It's not your fault, we had a problem for more than 10-15 minutes with disconnections, you should be all right now but please do not hesitate to contact us for any issue. Kind regards