Jump to content
Not connected, Your IP: 3.145.38.116

Staff

Staff
  • Content Count

    10934
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1843

Everything posted by Staff

  1. Hello, we have insert swiss tv (rsi.ch, srf.ch) in our anti-geo-blocking service. Can you try again and confirm that it works now ? Kind regards
  2. Hello! Well, with Tor over Air you don't put your trust on AirVPN. Our servers will see only traffic encrypted by Tor and only to/from various Tor guards (at least for your applications using Tor). So it's quite a good partition of trust. If you don't use end-to-end encryption you put a lot, really a lot, of your trust on the Tor exit-nodes operators, watch out. Tor over OpenVPN with end-to-end encryption is really good and, as we have seen from leaked documents, it is a "huge", huge problem even for NSA. Kind regards
  3. Hello! No, the VPN servers are not compromised. It's that web site that's compromised. You can easily verify that. First of all, have a look here: https://sitecheck.sucuri.net/results/www.lsri.uic.edu Then, look at how that page appears in Google cache (it appears with scam links): https://webcache.googleusercontent.com/search?q=cache:-hOXCMK9BA0J:www.lsri.uic.edu/faculty-staff+&cd=1&hl=en&ct=clnk&gl=it The above shows that it's not a problem in our VPN servers and that it's not an injection in the middle. So, that's what we think (and we are very very probably right) has happened to that web site. Someone infected their web server with SEO spam, and they configured the php / js / whatever file to show the scam links and pages only to some destinations in some list which includes Google bot, dedicated servers... In this way the scam is indexed and the rank is increased. This enhances the likelihood that the scam will remain for a long time before the web site operators even realize that their server has been compromised. From an Italian ISP we can see the scam links, from other ISPs we can't. Also, most of our VPN servers don't see the scam links (so they are not included). That's a quite subtle tactics for the purposes of the attackers. Is there anyone willing to link this thread to that web site operators? We'll also do the same as soon as possible. Kind regards
  4. @sheivoko Adding a "Con" to VPN over Tor: all the system traffic will flow indefinitely on the same Tor circuit (for an important reason Tor does not change circuit for the same TCP stream - incidentally it is this feature that makes OpenVPN over Tor a viable option). Kind regards
  5. @Verby The DD-WRT OpenVPN client logs you posted in your previous message showed a successful connection. Please proceed to test as we told you to, in order to verify whether the traffic is properly tunneled or not. When/if something goes wrong open a ticket. Kind regards
  6. Hello! That's correct. UDP is connectionless, so when a client loses the connection to the VPN server and is unable to notify the server, the server has no way to know that the client is no more there. The VPN server will assume that the client is no more connected after the ping timeout and the system will accordingly free up the connection slot. With TCP this problem does not occur because the server almost-immediately knows of a client disconnection, even if not explicitly notified about it by the OpenVPN client. Now that you have managed to connect your DD-WRT router to our service, you could connect your iPad to your router and have its traffic tunneled "transparently". Regardless of the amount of the devices connected to the router, our system will only see one connection, thus only one connection slot will be "busy" for your account. About the strange logs from OpenVPN in DD-WRT (connection/disconnection series warned by the OpenVPN management) that could be just a glitch of the OpenVPN management. To determine whether it's the case, browse (with your iPad connected to the DD-WRT router, while the router is allegedly tunneling traffic) to airvpn.org and verify whether the central bottom box is green or red. If it's green then the traffic is properly tunneled (airvpn.org sees your connection coming from one of the exit-IP addresses of the Air VPN servers). If it's red something is wrong, in this case feel free to open a ticket and send us at your convenience the screenshots of the DD-WRT OpenVPN client configuration panel and/or re-check configuration with our instructions https://airvpn.org/ddwrt Kind regards
  7. Actually it was not at all a problem of notices. See here for the whole story, if you are curious: https://airvpn.org/topic/10166-new-100-mbits-server-available-izar-in-experimental All the other datacenters in India we have inquired pose the same or similar problems: they can't meet our technical requirements, we're sorry. Kind regards
  8. @wakaflockaflame Hello, just as a side note (quite irrelevant for the core of the important arguments you raise) we would like to add that you can access Netflix USA from Swiss servers (provided that your system queries the VPN DNS server). Kind regards
  9. Hello! Unfortunately Netflix Canada blocks ALL of our Canadian servers. So we decided that Netflix USA is maybe better than no Netflix at all in Canada. Kind regards
  10. Hello, we have inserted tvcatchup.com in UK routing. Kind regards
  11. Hello, Issue for Wilmaa online TV has been fixed. Kind regards
  12. @eyes878 Warning, that procedure would work only on Windows, which handles sockets in a very peculiar (and somehow dangerous) way. In every other operating system you must also take care about the so called "infinite routing loop problem": communication between Tor and the guard node (the first node of each Tor circuit) will fall back into the VPN. Eddie for Linux and OS X resolves this problem by talking to Tor Control to detect and route correctly the guard(s) IP addresses (Eddie adds specific routes to the Tor guard to prevent the infinite loop). Kind regards
  13. Hello, we have insert http://dbna.de/ in our anti-geo-blocking service. Kind regards
  14. Hi, this is one of the community forums, please open a ticket to reach the support team. Kind regards
  15. @acacia We confirm that Eddie 2.10.3 runs just fine in our Debian jessie testing boxes. Just an idea related to Mono, did you install some newer Mono package not coming from the jessie repositories? Could you please post the output of the commands: mono --version dpkg -l | grep mono issued from any terminal in your system? Kind regards
  16. Staff

    pec.it

    Hello, we have insert Aruba PEC sites in our anti-geo-blocking service. imaps.pec.aruba.it smtps.pec.aruba.it Can you try again and confirm that it works now ? Kind regards
  17. Hello, we have insert this sites in our anti-geo-blocking service. hdts.ru hd-torrents.org hd-torrents.net hd-torrents.me Kind regards
  18. Hello, we have identified the problem. Can you try again and confirm that it works now ? Kind regards
  19. Hello, we have insert a special configuration for "wiki.debian.org" in our anti-geo-blocking service. Can you try again and confirm that it works now ? Kind regards
  20. Hello, we have insert ddl-warez.in in our anti-geo-blocking service. Can you try again and confirm that it works now ? Kind regards
  21. Hello, we have insert www.cpasbien.pw in our anti-geo-blocking service. Can you try again and confirm that it works now ? Kind regards
  22. Hello, that's the main reason in this case. We will (in various steps, no dramatic changes) rationalize the infrastructure, discarding servers with poor customer satisfaction and/or servers which pose excessive technical problems or bureocratic burdens. The infrastructure must always remain redundant just like it is now, so any withdrawn servers will be replaced by one or more better servers when/if necessary. Kind regards
  23. Hello! Can you post the logs? In particular, the fact that Eddie fails where OpenVPN alone succeeds is particularly annoying and we need. to investigate. Our purpose with Eddie is to make connections easier, not harder. Kind regards
  24. Hello! In order to update and optimize our infrastructure the server Cygni (Sweden) will be withdrawn during the night between Aug 31 and Sep 01 2015. Kind regards AirVPN Staff
  25. @BreathingAir Not sure what you're trying to achieve, but maybe the events can help you. Events can be set in "AirVPN" -> "Preferences" -> "Advanced" -> "Events". You can define to run a script or an executable file at App Start, App End, Session Start, Session End, VPN Pre, VPN Up and VPN Down. For each event you can tell Eddie to wait or not for the process (originated by the event) to end. This should give you granular control on any phase with Eddie. Kind regards
×
×
  • Create New...