Jump to content
Not connected, Your IP: 18.117.81.240

Staff

Staff
  • Content Count

    10615
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1767

Everything posted by Staff

  1. Hello! In order to provide a better service, we are working to bring access to geo-discriminatory services also from the servers which are located outside the specific country. The additional feature may be useful to all the users which would like to access a geo-discriminatory service in a country, while being connected to a server on another country. Furthermore, this service provides the option to access services in a country where there is no Air server. We have some countries available and we will be glad to "use" them against geo-discriminations. This idea was born when one of our kind customers warned us about the IP block of The Pirate Bay website performed by one of our UK ISP (with which, hopefully, we will never make business again). It was the first time we saw such a blatant, not enforced by law Net Neutrality violation in a datacenter, worsened by the fact that nowhere in the policy or in any other place the IP block was mentioned. After having solved the problem, the expansion of the idea was obvious. Experimentally you can test CBS on Castor (NL) and Pandora on Serpentis (SE). CBS discriminates against non-USA IP addresses, while Pandora against a lot of different country-IP, including Sweden. You are now able to access CBS even when you're connected to Castor and Pandora even on Serpentis. Remember, this is still at an experimental stage. http://www.cbs.com http://pandora.com Please do not hesitate to give us your feedback, let us know what you think of the service and how it works, and also let us know whether you like to have access to some geo-discriminatory service if located in a country where there are no Air servers. Kind regards
  2. Hello! Please see our real time servers monitor: https://airvpn.org/status Kind regards
  3. Hello! We don't support IPv6 at the moment, so your IPv6 traffic will be "IPv6 over IPv4" when tunneled to our VPN servers. It should NOT cause such performance decrease, unfortunately your tests suggest the contrary. In our plans, full support to IPv6 is currently not planned in the next two months. Please contact us through our "Contact us" form, or write directly to info@airvpn.org explaining your issue (or just a link to this thread) so that we'll consider to refund you while at the same time keeping your account active for testing purposes, if you're interested. Finally, a couple of questions: do you detect such performance decrease when you use different devices (i.e. not the DS)? How does the DS connect to a VPN server? Kind regards
  4. Hello! You can set the Firewall Security Level to "Disabled". This will make every and each firewall rule inactive, even without rebooting, but will not prevent Comodo to startup. Your solution in the other message, on the contrary, will prevent Comodo completely to start at the subsequent reboot. Kind regards
  5. Hello! Can you please describe what you have done to prevent DNS leaks? Also, please send us the OpenVPN logs. Kind regards
  6. Hello! Probably you have blocked DNS resolution when you are not connected to the VPN (preventing therefore DNS leaks, and that's fine). The Air client needs to resolve airvpn.org in order to show you the servers list, download certificates etc. You have various options to solve the issue: 1) Use OpenVPN or OpenVPN GUI instead of the Air client or 2) Add to your hosts file the following line: 46.105.19.36 airvpn.org This line resolves airvpn.org to the correct IP address, rendering a DNS query unnecessary. or 3) Secure your VPN connection with Comodo firewall in order to prevent every leak, not only DNS leaks, in case of unexpected VPN disconnection. https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Kind regards
  7. Hello! Let's check the server(s) first. Which server(s) do you use for uTorrent? Kind regards
  8. @okcmallrat The IP ranges published list is not correct, it includes too many IP addresses not belonging to Neflix, please ignore it. Kind regards
  9. Hello! You can send them where you prefer: here on this thread (cut sensitive information), on the "Contact us" form or on the Help Desk. Kind regards
  10. Hello! If you always connect to the same port with the same protocol, you can make this rule stricter. For example, if you always connecto to 443 UDP: Allow UDP In/Out From MAC Any To IP 95.211.169.3 Where Source Port Is Any And Destination Port Is 443 Or you can define a set of ports (53, 80, 443) and set "Destination Port" in that set ("Network Security Policy"->"Port Sets"->"Add a new port sets"). If you are annoyed by too much logging, just disable the logging for the block rule (untick the "Log when this rule is fired") and re-enable it only when you need it. Kind regards
  11. Hello! Can you please send us the Tunnelblick logs? Kind regards
  12. Hello! This is an unfortunate series of events, we apologize for any inconvenience. In this case we have had a problem with Cygnus. The server went suddenly offline, we only now know that the service has been suspended without prior notice by the ISP. The server did not communicate anymore with the backend and the connected accounts to the server were not "freed" for a vicious bug which has now been fixed. You should have no more this issue, but should this problem occur again please do not hesitate to contact us. Kind regards
  13. Hello! This is an unfortunate series of events, we apologize for any inconvenience. In this case we have had a problem with Cygnus. The server went suddenly offline, we only now know that the service has been suspended without prior notice by the ISP. The server did not communicate anymore with the backend and the connected accounts to the server were not "freed" for a vicious bug which has now been fixed. You should have no more this issue, but should this problem occur again please do not hesitate to contact us. Kind regards
  14. Hello! No, of course the packets of a local network from/to hosts of the network are routed inside the network itself. Exactly, see RFC 1112 http://www.ietf.org/rfc/rfc1112.txt Yes, it is safe, as long as all the hosts in your network are safe. It does not expose your real IP on the Internet. Kind regards
  15. The most accurate speed test is our internal speedtest, directly on our VPN servers. In this way you will get a consistent and coherent relative index of the performance (of course do not use speedtest to have an absolute index) which will help you determine the server, port and protocol which can provide you with the best performance. The speedtest is available in menu "Member Area"->"Speed Test". You need to be connected to a VPN server and logged in the website. Kind regards
  16. Hello! Thank you for your nice words. Yes, it's ok, the block rule we published blocks everything, so any other subsequent (i.e. "lower") block rule does not need to be evaluated. They are ok. They may be blocks of DNS leaks or UPnP attempts etc. If you wish to support UPnP, share printers etc., you can allow communications to and from the IP addresses you report on point 3). About sharing devices on your local network, if you don't update regularly your Windows OS, please carefully read this before allowing those connections in Comodo: http://technet.microsoft.com/en-us/security/bulletin/MS10-061 This shows that you lost connectivity with your ISP and/or with your router. If it happens regularly every 2 hours, chances are that your ISP is losing connection regularly or that your DHCP settings on your DHCP server (typically your router) are not correct (see also DHCP lease time) and/or the DHCP settings of your ISP are grossly misconfigured. You might like to read this: http://www.tcpipguide.com/free/t_DHCPLeaseLifeCycleOverviewAllocationReallocationRe.htm Kind regards
  17. Hello! We apologize for the delay, your issue deserved an extensive and careful evaluation. If TCP reduces your speed drastically in comparison with UDP (let's say more than 15%) then there may be a high rate of packet loss, unfortunately, or a replay attack (see below). With TCP, each lost packet is properly resent thanks to its extensive error-correction implementation, but this is of course not the best solutions for performance of some applications (VoIP, online gaming, real A/V streaming...). It seems really related to the OpenVPN connection, see below. You might like to read here: http://en.wikipedia.org/wiki/Peering A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator (of course not in our case!!!) or by an adversary who intercepts the data and retransmits it, possibly as part of a masquerade attack by IP packet substitution. OpenVPN will reject correctly the fraudulent packets and no injection is possible. However the attack, if well organized, will slow down considerably your VPN connections. If your problem occurs on EVERY Air server, then it's extremely unlikely that you are the target of a replay attack, UNLESS your adversary has the ability to monitor your own ISP line. However, the "Authenticate/Decrypt packet error: bad packet ID (may be a replay)" log entries do really suggest a replay attack against you even before the connection to our servers. If this an attack, then the adversary is not attacking our servers in general, he/she is attacking you specifically. About the "Replay-window backtrack occurred", this is the consequence of the problem. OpenVPN writes in the log this event. Please read here. Although it is not 100% sure, it might mitigate your problem without having to use TCP: http://openvpn.net/archive/openvpn-users/2004-09/msg00068.html It is not sure that the above will improve your connectivity for online gaming, you will have to test various parameters. But it is sure that it may lower your security if you are under attack. The risk is forcing OpenVPN to accept fraudulent packets as valid packets. The directive to set the n parameter is replay-window in your .ovpn configuration file. See the OpenVPN manual: Kind regards
  18. Hello! 1. This is normal. Please make sure that uTorrent listens to the same port you have remotely forwarded. Make sure that Windows firewall is not blocking uTorrent on any network. "Run a torrent" and check whether you obtain a green token in uTorrent to verify that the port is correctly forwarded. We confirm you that port forwarding is working correctly on all servers for every client. Please see the FAQ https://airvpn.org for various reasons for which you may obtain low performance. Since you have already jumped to conclusions, remember that you have 3 days to ask for a full refund, "no questions asked". Kind regards
  19. @FPyro Hello! The logs show that either duplicate packets are being received or packets are arriving out of correct order. Seeing the last lines of the logs ("Replay-window backtrack occurred") the second option is more probable. If the problem was born only recently, maybe it is just a temporary peering issue between our servers and your ISP. Rarely it may also be a symptom of a defective Ethernet cable or network card, router issues or WiFi problems. Please try connections to VPN servers' TCP ports to mitigate the problem and also test different servers. Finally, just in case, if you have the chance, try to replace momentarily cable and router and if possible also the computer. Change only one item at a time to determine if the problem is in the hardware. Kind regards
  20. @itsmeprivately 1) It just means that Comodo is doing its job. By checking source and destination IP address you can see if you wish to authorize that traffic outside the tunnel or not. 2) Losing connection so often is not normal, probably you have connectivity issues with your ISP. Once you are disconnected, you should be able to reconnect immediately, but only if the ISP is giving you back full connectivity. Kind regards
  21. Hello! It means that you lose connectivity with your ISP each time. Therefore ALL the established connections will be lost (not only OpenVPN ones). Please contact your ISP customer service, we really can't do anything about it. Kind regards
  22. Hello! Please see here: http://www.gnupg.org Kind regards
  23. Hello! The TAP-Win32 interface is the virtual network adapter used by OpenVPN. Air is a routed VPN, not bridged, and uses a TUN interface. Please also see here: http://en.wikipedia.org/wiki/TUN/TAP Kind regards
  24. Hello! Yes of course, your care for privacy is absolutely correct. Please attach the file in an e-mail and send it to info@airvpn.org. Ask for and send your gpg public key before sending the file if you don't wish to send it unencrypted. Kind regards
  25. Hello! We apologize for the inconvenience, that link was wrong. Fixed now. Kind regards
×
×
  • Create New...