Jump to content
Not connected, Your IP: 18.218.99.80

Staff

Staff
  • Content Count

    11048
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1867

Everything posted by Staff

  1. If the suggestion to resolve this issue is to use an additional paid service then that is not a viable solution for me. If unblock-us can continue to bypass Hulu's geolocation restrictions then why can't AirVPN? I don't know about other members but I don't want to be (and can't afford to be) paying for an additional proxy service just so I can watch Hulu. When this has happened periodically in the past it has always been resolved quickly. It seems like this time there is no desire to fix the issue which is disappointing to say the least. "Not in the near future" isn't very encouraging. Please let us know what is the plan and timeline to resolve the issue? This must be affecting tonnes of AirVPN users right now. Hello, unblock-us uses a server whose IP address is still not blocked by Hulu. It might get blocked tomorrow, in a hour, or in 10 years, who knows. Our service uses micro-routing as an experimental feature, we are focused on VPN services aimed to privacy, anonymity and data protection, while unblock is exclusively concentrated on DNS and reverse-proxy services to bypass geo-restrictions (so such a service can't work if the IP check is implemented also at streaming level: your real IP address is visible and the stream is sent to it - unless you're connected to a VPN). You just can not compare such services. Our service is more complete in the sense that it can include services such as unblock-us and preserve privacy and anonymity at the same time, but in any case it needs an IP address that's not blocked by Hulu and at the moment we do not have such IP address. As soon as and if we have a solution we will be able to publish an ETA for such solution implementation. Kind regards
  2. Hello, our OpenVPN Data Channel cipher is AES-256-CBC. You're getting the maximum AES-256 throughput that can be sustained by your router CPU (assuming that OpenVPN runs on Shibby Tomato). AES-256 is a high grade encryption that's computationally heavy for a consumers' router CPU. In other services, if no encryption or weak encryption is used in the OpenVPN Data Channel, throughput will be obviously much higher, at the price of significantly lower security. You can anyway bypass the bottleneck by connecting directly your computers (up to three simultaneously) or using a more powerful routing box (see pfSense for example). Kind regard
  3. Hello! We're very glad to inform you that five new 1 Gbit/s servers located in the Netherlands are available: Ceres, Julliet, Pallas, Riguel and Sedna. The AirVPN client will show automatically the new servers, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Ceres, Julliet, Pallas, Riguel and Sedna support OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team
  4. Hello, route checking fails, please try to disable it. Un-tick "Check if the tunnel effectively works" in "AirVPN" -> "Preferences" -> "Advanced". After that try again a connection to a VPN server, browse to airvpn.org and verify whether the central bottom box is green or red. If it's green, everything is fine. Since the route checking is somehow a security check, if you need to keep it disabled for this problem we would suggest that you activate "Network Lock" (available only on Eddie 2.5 or higher). Kind regards
  5. Hello! Clearly some system of our customers is infected. Kind regards
  6. Hello! The TLS Cipher is wrong. Try with "None". If it fails, try with "TLS-DHE-RSA-WITH-AES-128-CBC-SHA". Both are very wrong but for some DD-WRT glitch, on newer builds either the first or the second work, while all the other ones (wrong as well) fail. Kind regards
  7. Hello, it seems that some certificate or key has not been pasted correctly or that the cipher you selected is wrong. A screenshot of the DD-WRT OpenVPN client configuration page may help. Kind regards
  8. Hello! Your method is perfectly fine. In Eddie Network Lock has not been implemented in this way for some potential problems in specific configurations, we needed a method that must be as generic as possible and applicable to a wide amount of systems. Additionally, Eddie performs a lot of tests for servers ratings, but the route command execution can be extremely slow in Windows: keeping the rating system with Network Lock would have needed dozens and dozens of route commands with huge delays. Kind regards
  9. Can you explain as to why is this? Other VPN providers are working fine with Hulu.. Which ones? Kind regards
  10. Hello! The tun interface (the virtual network card used by OpenVPN) does not come up. Please try the following: https://airvpn.org/topic/8320-solved-connects-but-ip-doesnt-change-on-windows-server-essentials-2012/?do=findComment&comment=8321 Kind regards
  11. Hello! Since Ultrasurf employs HTTP proxies, probably your company Fortigate firewall allows those packets. Additionally, your solution (OpenVPN over Ultrasurf if we understand it correctly) is quite elegant. There is widespread concern about Ultrasurf, the addition of a further OpenVPN tunnel potentially solves any risk, because data are still encrypted by OpenVPN when they pass through Ultrasurf servers. See for example https://en.wikipedia.org/wiki/Ultrasurf#Evaluation in particular Appelbaum's concerns and criticism. Kind regards
  12. @hakrins You might like to run Eddie with "Network Lock" function enabled: https://airvpn.org/topic/12175-network-lock Kind regards
  13. Hello, we think we will not be able to restore Hulu access in the near future, we're sorry. Kind regards
  14. Hello! The only way to have an automated subscription is with "PayPal subscription". Any other mode (credit card, PayPal, Bitcoin) will not charge you automatically. If you have picked "PayPal subscription" unintentionally just delete the authorization to payments from inside your PayPal account. Kind regards
  15. Hello! Thank you very much for all the information you provided! Of course, if you gather more data, feel free to publish. Did you contact OpenVPN community (in the forums) or OpenVPN Technologies about this problem? Kind regards
  16. Hello, any confirmation on this by third parties? We have a roughly estimate of >5000 systems with Win 7 64 bit using the latest tun/tap adapter driver and not even one single report about this problem. Bug tracker? Links? Kind regards
  17. Hello! Thank you for the report. Some documentation about the bug? Ways to reproduce it? Kind regards
  18. Hello! Provided that you downloaded the original package (check the fingerprint) it's a false positive. As a side note, please upgrade to 2.6. Kind regards
  19. Hello! 1. It does not seem necessary because authentication and data integrity are already guaranteed by the tunnel itself... we will ponder about it. 2. Not in 2014, sorry. Support to IPv6 on our side has not yet a defined time line. But of course sooner or later it will be necessary. Informally, we have postponed IPv6 discussions to 2015. All in all, OpenVPN full support to IPv6 has been implemented only recently. 3. It is technically possible and this argument will be evaluated soon. Currently a user.key change requires our intervention, it is not possible to do it on the client side alone, and the system is configured to have one single key per account at the moment, so some work will be necessary. Kind regards
  20. @McLoEa Hello, an "original" DNS restore might fail under very rare circumstances which however we need to be able to reproduce. Eddie has also an emergency recovery in case it could not restore before shutting down (for example if it was forcefully killed). Feel free to keep us posted if the problem re-occurs: if possible try to detect a pattern for which the failure is reproducible. Even OpenVPN itself, if put in conditions to be unable to execute the down script, would leave the DNS settings not restored. Kind regards
  21. Hello! Which Eddie version are you running? A possible explanation is that Eddie does not reset your original DNS, maybe because they were already set to VPN DNS for some reason (in this case, for Eddie the "original" DNS are the VPN DNS...). While you're disconnected from the VPN, please verify which DNS are set in your system, before you perform any card reset. Kind regards
  22. Hello! Do you mean that we should solve a problem that's occurring in another platform and servers completely out of our control? What should we do? Kind regards
  23. Hello! We do not block NTP, absolutely not. Additionally, connection to NTP servers from the router, when booting, should be performed before a connection to a VPN server, to allow the router to set the correct date and time, otherwise authentication will fail. Kind regards
  24. Hello! If you click (left-click) on the "AirVPN" button with a down arrow (menu symbol) in the upper left corner of the Eddie client main window, does a drop down menu appear or not? If so, "Preferences" is one of the items of such menu. Kind regards
×
×
  • Create New...