Jump to content
Not connected, Your IP: 3.19.237.16

Staff

Staff
  • Content Count

    11333
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1948

Everything posted by Staff

  1. Hello! It is not a reported bug as far as we know, but if you can manage to have a reproducible bug under a controlled environment, you can surely warn about it in the OpenVPN Community bug reports forum. Kind regards
  2. Hello! Are you referring to airvpn.org? If so, that's quite odd. While you are connected to an Air VPN server, can you please send us the output of the commands: ping airvpn.org traceroute airvpn.org (replace "traceroute" with "tracert" if you're running Windows). Feel free to delete sensitive information from the traceroute output. Kind regards
  3. Hello! The Air client is an OpenVPN wrapper so everything pertaining to the VPN connection is handled by OpenVPN. Kind regards
  4. Hello! The other thread refers to a connection which is usable only after some data have been exchanged, while your problem, if we get it right, is that your connection freezes. Do we understand it correctly? Kind regards
  5. Hello! It appears clearly a problem on your side, because different servers in different countries can't have all the same problem (additionally, we don't detect any problem on any server and thousands of clients connect and exchange data just fine). What do you mean when you say that Wireshark nearly crashed? What were the symptoms of it? In order to focus on the problem, do you have any other system in your place? If so, what happens if you try a connection from a different system on the same router and ISP? Kind regards
  6. Hello! All the servers are responding correctly on all ports and your connection logs look just fine. Probably it's something related to your system, considering also that Cygni and Serpentis are on different datacenters with different ISPs. Can you determine what is the task or process which causes such a spike in upload bandwidth? You can see it with Wireshark or with the Comodo firewall connection monitor. http://www.wireshark.org Also, does the problem occur to you on servers outside Sweden too? Kind regards
  7. Hello! The logs do not show any problem. Let's see whether it's a DNS resolution issue, since your system resolves airvpn.org from your hosts file. While you're connected to a VPN server, please open a command prompt, issue the following commands and send us the output: ping google.com ping 10.4.0.1 ping 8.8.8.8 ping airvpn.org Kind regards
  8. Hello! Probably it's a display bug in the Air client we were unaware of. 44000 kB/s is a stellar bandwidth (5500 Mbit/s) which is not even supported by any of our servers. Kind regards
  9. Hello! It's not necessary. However, some Windows system may have (rarely) DNS issues which can be solved by setting as primary DNS server in the physical adapter (wifi and/or ethernet) the VPN DNS IP address 10.4.0.1. Kind regards
  10. Hello! Your uTorrent is well configured, you're just fine. As you can see in the screenshot, the green token shows that uTorrent is able to receive incoming connections on port 41380. The fact that you don't seed fully may be due to the swarm status (for example high seeds/leechers ratio). Kind regards
  11. Hello! For Windows and Comodo, please follow this guide: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards
  12. Hello! Please: - forward a TCP & UDP port - do not remap it to any local port - configure uTorrent to listen to the above port number - make sure to start uTorrent AFTER you have connected to the VPN Kind regards
  13. Hello! Please ask them through the "Contact us" form (or find them with the configuration generator). Kind regards
  14. Hello! Can you please send us your client logs? Kind regards
  15. Hello! The problem is that you remapped a remotely forwarded port to a different local port. This is a special case where a local port remapping can not work, because the swarm will try to reach the p2p client on the local port instead of the remotely forwarded "public" port. Please forward a port and do not remap it to a local port. Then set your uTorrent to listen to the same remotely forwarded port. Finally make sure that the option to randomize the listening port every time uTorrent runs is not active. Kind regards
  16. Hello! It does not disappear, on the contrary thank you very much for the very nice guide! It can be read by anyone here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=2&id=6652&Itemid=142#6652 Each time you edit it a moderator must approve it again, this may be the reason for which after an editing you can't see it for a little while. Some delay for the approval was due to the advertising of the image hoster reported in the screenshots (ads are forbidden in the forum) but it was decided to publish it anyway. We will also evaluate to put it in the "Enter" pages for Tomato. Also, apparently Tomato works better than DD-WRT. Thank you again. Kind regards
  17. Hello! Despite the reports you cite, perhaps your firmware version is bugged. The following version has been reported as working for Linksys E4200: dd-wrt.v24-18774_NEWD-2_K2.6_openvpn.bin Before re-flashing, please make sure that your second router is working in bridge mode (only if the DD-WRT router is behind your second router and the second router connects to your ISP). Kind regards
  18. Hello! We're glad to inform you that a new feature aimed to locate easily a sequential range of free ports has been added on the port forwarding panel. Now you can ask the system to locate for you a range of contiguous ports if you need them. You can also watch a graph which reports free (in green color) and allocated ports (in red). Furthermore, the port random allocation algorithm has been improved in order to rationalize the forwarded ports assignments. Please remember that if your account subscription is kept expired for more than 10 days, the reserved ports for it will be released. Kind regards
  19. Hello! Please set correctly the date and time of your DD-WRT router. In 1970 the certificates were not valid. Unfortunately, while the above needs to be fixed (otherwise TLS negotiation will always fail), it does not seem to be the real root of your problem. If the problem persists, you have a bugged firmware, please see here: http://svn.dd-wrt.com/ticket/2536 Kind regards
  20. Hello! If you wish to make the ssh daemon reachable from the Internet outside the tunnel, you need to bind it to the physical server interface (for example eth0). On the contrary, if you wish to run the ssh daemon behind the VPN, just forward remotely a port on our system and make sshd listen to that port on your tun interface. Your sshd will be reachable from the Internet on : Kind regards
  21. Hello! Unfortunately the symptoms strongly suggest that your computer is compromised. First of all, please check thoroughly for malware. It's also absolutely necessary that you determine which task(s)/process(es) are causing the bandwidth spikes and cause your loss of control of your own system: it's likely that there you will find the malignant program(s). To monitor your packets try with Wireshark: http://www.wireshark.org Kind regards
  22. Hello! Thank you for your subscription! The pushed routing table and default gateway by our OpenVPN servers force all the client traffic to be tunneled. The only way to escape this behavior are programs that take control of the system with administrator (root) privileges and bind to the "wrong" interface. Does your MMO game client pretends to run with high privileges? You can check the traffic flowing in your machine with programs like Wireshark (very powerful) or the network activity monitor (a limited tool, but good for your purpose) of the Comodo firewall. If you find that your game client takes control of your system and overrides your system routing table you might try to force it to bind to the TUN adapter (in Windows TAP-Win32 Adapter V9...) with this code/DLL injector: http://www.r1ch.net/stuff/forcebindip In general, programs which behave in that way should be considered near to malware (overriding a system routing table without the system owner explicit authorization may be a very dangerous operation in a lot of countries and anyway it is an unacceptable violation of the system security) and customers of such programs, in our opinion, should contact the software house and pretend that the problem is solved. Kind regards
×
×
  • Create New...