Jump to content
Not connected, Your IP: 18.220.178.207

Staff

Staff
  • Content Count

    10612
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1765

Everything posted by Staff

  1. Hello! Thank you for your subscription! You can post Comodo global rules and network zones screenshots here or through the "Contact us" form or send us via mail to info@airvpn.org, as you prefer. Please download the following client versions. For 64 bit systems: https://airvpn.org/repository/air_windows8_x86_64.zip For 32 bit systems: https://airvpn.org/repository/air_windows8_i686.zip The client is compiled for .NET framework 4. We'll soon rationalize the Air client and OpenVPN packages now that OpenVPN 2.3 stable version has been released. Kind regards AirVPN Support Team
  2. Hello! When you connect to a server and you have 30-40 minutes available to remain connected, please warn us and we'll check the port forwarding to your account IP directly from the server in real time. Kind regards
  3. Hello! Can you please make sure that the proxy set in the Air client is the correct type and that the port protocol is set to TCP? Kind regards
  4. Hello! We thought that "Reserved for AirVPN staff" was clear enough, but if it's not we'll be glad to modify it. The servers showed in the servers monitor page and in the configuration generator are the available servers for connections. If a server has problems you will see on that page an error status inside the server box. If a server is not shown there, it is not available anymore. If a server is withdrawn for ever or if its problems persist we publish an announcement on the forum. Finally, if all frontends are unavailable for forum access (emergency cases which should never happen, for example all frontends or all backends are down) we make announcements on Twitter. Theoretically, if a server goes down it should never happen that we are not aware of it, because our monitoring system sends the support team (via mail, IM and SMS) warnings and reports every 5 minutes. However it may take several minutes to understand the nature of the problem. Kind regards
  5. Hello! We are reluctant to post the list here, please ask it through the "Contact us" form (or see the IP addresses with the configuration generator), we'll send it to you. Kind regards
  6. Hello! Yes, we have noted recurring problems with Vega and Octantis in the past days. They are related to the provider's infrastructure: lines go down and the server get isolated from the world for several minutes or even hours, like today. If the problem will not be solved soon, we'll seriously consider to dismiss Vega and Octantis. Now Vega and Octantis are up and running. Just like with any service in the world, failures happen beyond the human ability to control reality. Anyway we notify about problems both in the real time servers monitor (with appropriate messages), the forum and Twitter in case of major problems. Kind regards
  7. Hello! Which failure are you referring to? The german servers were and are up and running, please feel free to send us your connection logs if you need support. You can always see the infrastructure status here: https://airvpn.org/status Currently, at the time of this writing, the only unavailable server is Ophiuchi in the Netherlands, due to causes we're investigating (the server does not respond and does not come up after a forced power off/on). Kind regards
  8. Hello! Well, that's unrelated (none of the above sends and receive packets to and from outbound UDP ports, for example). Anyway it was just a consideration to check, because we know many providers that perform port shaping always. Kind regards
  9. Hello! The first check to perform is whether you use some third-party "network manager" bundled with Windows by the computer vendor (just in case you have an OS pre-installed by the vendor). An Asus network manager, for example (which handles both WiFi and Ethernet), has been reported several times by Air customers to slow down incredibly the throughput on the tun interface. De-activating it solved the problem. After that, we would recommend to check the logs to verify whether there's packet loss/fragmentation. In case of doubts just send us all the OpenVPN logs of one of your connections, in particular the slowest ones. In that case, it will be not easy to solve the problem, but there are some steps to try that could mitigate it. Finally, it remains to be seen whether your ISP deliberately caps bandwidth/deprioritize packets on some ports or with encrypted connections. In the European Union ISPs are obliged by law to declare such limitations (and any other limitation on applications, services and protocols) in the contract in a clear, understandable and easily accessible way, just in case you live in the EU. Kind regards
  10. Hello! Excellent, we're very glad to know it! Windows firewall is dropping or rejecting uTorrent incoming packets on the VPN adapter (and possibly other programs as well). You should add uTorrent as a authorized/trusted application in Windows firewall on all networks. Actually Windows firewall may authorize a program on some network while keeping it blocked on a different one. Perhaps you might also consider to change firewall. Kind regards
  11. Hello! We have performed various tests. The port forwarding in the server you're currently connected to works fine. The packets are forwarded to your VPN IP address correctly, but your system does not respond. Might there be anything on your system which is blocking incoming packets on the tun adapter? You can test with Wireshark or with the Comodo network monitor to verify that. A hint can be also given by uTorrent. uTorrent is able to punch our NAT, therefore it would not even need remote port forwarding. If you let uTorrent work without port forwarding (but with NAT-PMP and UPnP re-enabled) and share something, do you get a green token after a couple of minutes or not? Kind regards
  12. Hello! If you can, please stay connected to the server you're currently connected to for some minutes, we'll perform some tests right now. Kind regards
  13. Hello! Which firewall are you running? Do you get the same results also with the firewall off? Do you get the very same performance on all servers, all ports and all protocols? What happens if you connect to port 53 UDP and port 80 TCP? Kind regards
  14. Hello! Can you please make sure that the service you want to be reachable is listening to the same port and that it is running while the port check is performed? Which service is it? You can try different ports and protocols, just in case your ISP performs port shaping. Try connections to port 53 UDP and 80 TCP to make a performance comparison. Also try different servers, even those geographically further to your location. Kind regards
  15. Hello! Difficult to say for sure, anyway the symptoms point to a peering issue. Or maybe a routing problem. The servers are in the best Singapore datacenter, connected directly to tier1 providers. You might like also to check with your provider whether there are known issues of this sort with the http proxy. Kind regards
  16. Hello! It's normal that you can connect only over TCP, because with an HTTP proxy (the proxy type you're using) TCP is mandatory, UDP is not supported by the proxy. Connections over OpenVPN over a proxy cause a severe performance hit. You can try a direct connection to the servers (i.e. without passing through al proxy) if you don't need to hide your real IP address to our servers while your client is connected. With a direct OpenVPN connection you can use UDP, of course. Kind regards
  17. Hello! Now that you have discovered e-mails that you were not aware of, please follow the suggestions the support team gave you. In particular: unfortunately, you have never connected to any port other than 443 TCP, while it was recommended that you tried different ports and protocols to make a performance comparison. You were also asked to send the connection logs and information about your system, but the support staff never received them. We are confident that you understand that asking for assistance and then not complying to recommendations and requests may severely impair the support team ability to solve problems. Additionally, you have sent a refund request. We follow a "no questions asked" refund policy. Please note that once a refund request is accepted, the refunded account is no more supported as a premium member and can't connect anymore to VPN servers. You will be able anyway to receive pre-sales support. Kind regards
  18. I did point the 'openvpn path' to the 2.3 rc2 location but it didn't work Hello! Strange, it might be a bug, the client programmer (who anyway reads the forum) will be informed about it. Kind regards
  19. Hello! The current road map includes major new releases essentially aimed to circumvent censorship in a much more robust way and integrate new services which are being developed (OpenVPN over SSL and OpenVPN over SSH). Also, a Linux version which requires Mono is under development. Correct. With OpenVPN GUI for Windows you have that limit. Anyway you can have as many configurations as you wish and access them by launching directly OpenVPN. Statistically, the overwhelming majority of disconnections we have analyzed through support requests is caused by a new IP address "assignment" to the client system by its ISP, this obviously can't be solved on our side. A minor number of disconnection cases are caused by disruptions of OpenVPN connections (only in human rights hostile countries). Kind regards
  20. Hello! This is a special case for which the latest stable release of OpenVPN seems to cause issues on some Windows 8 systems. Normally the client is bundled, and programmed to run, with the latest stable release, not with a release candidate. Remember that you have always the option to use OpenVPN directly or the OpenVPN GUI or any other OpenVPN wrapper. Kind regards
  21. Hello! No, it is a slighty different matter. You were asked whether you had launched the Air client before launching the OpenVPN GUI because in that case, if you connected with the Air client, a first instance of OpenVPN would have established the connection. Then, if you launched the OpenVPN GUI, it would just display the red monitors in the dock icon, because no OpenVPN started by the GUI was launched. You have a central bottom box which is green, therefore your system is connected. The fact that the OpenVPN GUI dock icon shows red monitors might be explained by the fact that you previously connected with the Air client. Did you connect your system with the Air client and THEN you launched the OpenVPN GUI? Kind regards
  22. Hello! If the middle bottom box is green your system is connected to an AirVPN server. Maybe you have connected with the Air client and THEN you launched the OpenVPN GUI? Kind regards
  23. Hello! If you use the OpenVPN GUI, the computer "screens" (the OpenVPN GUI dock icon) should turn green when a connection to a VPN server is established successfully (they never flash). If you use the Air client, the Air client dock icon is gray if your system is not connected, and it's a white cloud on a blue sky while the system is connected. By the way, please browse to https://airvpn.org and check the bottom central box (do not use a proxy or TOR when you perform this check). If it's green (stating "Connected" and an Air server name) your system is connected, if it's red it's not. Kind regards
  24. Hello! Yes, you can try the following bundles, which come with an Air client compiled for .NET framework 4.0 (you'll need it as well). The following is bundled with OpenVPN 2.3_rc1 for 64 bit systems: https://airvpn.org/repository/air_windows8_x86_64.zip The following is bundled with OpenVPN 2.3_rc1 for i686: https://airvpn.org/repository/air_windows8_i686.zip They were originally prepared for Windows 8 but they run just fine on any system with .NET framework 4 (just make sure not to mismatch 32 and 64 bit versions). Kind regards
×
×
  • Create New...