Jump to content
Not connected, Your IP: 3.21.104.201

Staff

Staff
  • Content Count

    10626
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1772

Everything posted by Staff

  1. 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
  2. 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
  3. 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
  4. 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
  5. @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
  6. @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
  7. 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
  8. Hello! Please see here: http://www.gnupg.org Kind regards
  9. 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
  10. 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
  11. Hello! We apologize for the inconvenience, that link was wrong. Fixed now. Kind regards
  12. @dexter010 Hello! Thank you for your purchase. You should have received instructions to use your code from bitcoincodes, our authorized reseller, but if your mailbox is blocked you clearly could not. Anyway... To activate your account to premium status: - register and log in our website https://airvpn.org - select "Payment Plans" https://airvpn.org/payment_plans - pick the non-recurring subscription plan matching the code you have - before the checkout, insert your code (uppercase) and click "APPLY" - your account will be activated to premium status (no traffic limit, no bandwidth limit) After that, just select your favorite server and port with our configuration generator (for Linux, Windows, MacOSX, Android, DD-WRT), or connect through the AirVPN client (for Windows). You can generate as many configs as you wish in order to switch easily from one server/port to another with the OpenVPN client. FAQs are available here, please take a moment to read them all, because they will help you use our system at best (including enhancing performance for p2p and fully use our unique Remote Port Forwarding system): https://airvpn.org/faq More details on recent improvements on the system: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1616&Itemid=142 Another useful tool is the real-time servers monitor: https://airvpn.org/status The ToS and the Privacy Policy are available at the bottom of most of our website pages. Please do not hesitate to contact us for any further information. Kind regards
  13. Hello! Please send us: - Comodo network zones - Comodo global rules - Comodo application rules - Comodo Firewall events logs - Air client (or OpenVPN) logs Kind regards
  14. Hello! If you don't want use the Air DNS, you should force your favorite DNS servers on your TUN/TAP interface, so that encrypted and tunneled DNS queries will be forwarded by our servers to those. No problems with the Comodo rules, they don't prevent DNS queries in the tunnel, they prevent them outside the tunnel. Usage of DNSCrypt is useless when a device is connected to the VPN. Usage of DNS servers different of Air DNS will not impact anonymity, but will neutralize our anti-ICE censorship system. Kind regards
  15. Hello! Can you please send us the logs? Kind regards
  16. Hello! The operation you performed should give you no problems. If you still can't connect to our servers, please send us the Air (or OpenVPN) logs. Basically nothing changes. You will have to know some parts of your network, though, just in case you'll need additional allow rules to communicate with your gateway, or with the corporate proxy (if any). Kind regards
  17. Hello! We are not willing to offer "false solutions" which give a dangerous, false sense of security, like other services do. If we find a solution as reliable as a firewall rule, we will of course be very glad to implement it. Setting the rules for Comodo should take no more than 3-4 minutes, except for persons who don't know what a firewall is. In that case, reading the Comodo quick guides is useful and it is very well spent time. We repute that nobody should ignore what a firewall is nowadays. Techno-ignorance is the most powerful weapon in the hands of the censors. Please consider that if you just need to block a torrent client, only ONE rule is necessary (application rule for the torrent client as explained). Kind regards
  18. Hello! We don't detect any problem. Can you please make sure that the proxy type you select (http or socks) matches the proxy type you're using for TOR? Kind regards
  19. Hello! Yes, it's totally normal. No, this is important, please make sure that you don't have forwarded on your router the port your torrent client listens to. Please see here for a clarifying explanation https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 (if you have Windows; you can find rules for other systems in the top part of the forum, in the "Announcements" section). You should set firewall rules to prevent leaks in case of unexpected VPN disconnection. This is the safest solution. We don't recommend different solutions, due to security reasons. Kind regards
  20. Hello! Please follow the instructions for Mac OSX, you will be ready in 5 easy steps. Instructions are available in menu "Enter"->"Mac OSX", direct link: https://airvpn.org/macosx/ Kind regards
  21. Hello! That's exactly what our customer asked for. Please elaborate, it's written in the message above. If you mean how an OpenVPN server pushes routes, then the answer is "with the push directive". A client may refuse pushes with the nopull directive, in which case a tunnel is established but nothing will be tunneled until a proper routing table is defined. Kind regards
  22. Hello! Yes, it's possible. By default our servers push routes so that all traffic is tunneled. You need to change the routing table in order to route the traffic for Netflix through your normal gateway instead of the VPN one. You need also to know the Netflix IP ranges. According to comment by "Jon" here: http://kaeding.name/articles/2010/11/15/prioritizing-netflix-traffic-with-dd-wrt/ the IP addresses used by Netflix to serve content are many: 208.75.76.0/22 128.242.0.0/16 63.97.94.0/24 65.200.11.0/24 96.16.0.0/15 216.246.75.0/24 204.0.0.0/14 204.200.0.0/14 184.84.0.0/14 62.0.0.0/8 58.0.0.0/8 198.76.0.0/14 4.27.0.0/16 8.0.0.0/8 206.32.0.0/14 209.84.28.0/23 209.84.24.0/22 209.84.16.0/21 192.221.0.0/16 205.128.0.0/14 4.0.0.0/8 204.160.0.0/14 199.92.0.0/14 184.72.0.0/15 208.111.128.0/18 Now, you need to modify your routing table so that the above IP ranges do not get tunneled: route add -net 208.75.76.0/22 gw <your "non-VPN" gateway> ... route add -net 208.111.128.0/18 gw <your "non-VPN" gateway> In this way you'll obtain that all the traffic for Netflix (assuming that the above IP ranges list is correct and exhaustive) will not be tunneled. Kind regards
  23. Hello! Can you please send us the logs? Kind regards
  24. Hello! On some versions of NetGear DG834G it is possible to flash OpenWrt, which includes OpenVPN support. It is very important that you determine exactly which version you have (1, 2, 3, 4 or 5). Please see here: http://wiki.openwrt.org/oldwiki/openwrtdocs/hardware/netgear/dg834g Kind regards
×
×
  • Create New...