Jump to content
Not connected, Your IP: 34.200.236.68

Staff

Staff
  • Content Count

    8542
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1213

Everything posted by Staff

  1. @hydrotux Yes, but some services restrict streaming to IP addresses assigned to residential ISPs. Any IP address, even geo-located in Italy, not assigned to some residential ISP is treated as a foreign address. That said, RAI programs are perfectly accessible from all of our VPN servers. Kind regards
  2. Problem resolved in Eddie 2.18 and higher versions. Kind regards
  3. @Flx No reboots have been recorded and no daemons have been restarted. However some Amanah servers have suffered a line blackout at ~ 3.30 AM (UTC) for several minutes. We also see that the problem was sorted out just before 4 AM. During the blackout they could not communicate at all. It might be the problem you mention. Check the real time server monitor and when you mention time remember to specify time zone. No communications from Amanah so far. Kind regards
  4. @Flx You can check anytime the issue history of each server in the real time server monitor by clicking a server's name. We think no peculiar problems affected our servers in Amanah at the time you mention but check yourself. https://airvpn.org/status Kind regards
  5. @NLVPN Hello! Also consider that you can have robust load balancing with a pfSense (and in general *BSD) box and AirVPN: https://nguvu.org/pfsense/pfsense-multi-vpn-wan/ Kind regards
  6. @Maggie144 Hello! Eddie development will be re-opened soon, to align Edie with latest AirVPN library, improve general usability and comply to the future November 2020 Google requirements. Kind regards
  7. Hello! Eddie's guides have been moved to the FAQ answers which in turn point here: https://eddie.website FAQ section is linked in the web site top menu and in the welcome e-mail (but of course it's not mandatory to enter a valid e-mail address, so if you did not you have not received the welcome e-mail). Another guide which you might find useful is the one linked in our welcome e-mail. It's the first, pinned guide in the How-To section: https://airvpn.org/forums/topic/18339-guide-to-getting-started-links-for-advanced-users/ 1. The welcome e-mail and the guide both stress the purpose and the importance of Network Lock. In general yes, we would recommend to activate Network Lock, but actually some special cases may require its de-activation, or its partial activation. About servers selection, that's up to you. If you leave the choice to Eddie, it will do its best to pick a good server. for your node, according to the rule you will find in above documentation. As usual, a human choice can be more fine tuned. 2. It should do so when you minimize the window, except in desktop environments where system tray and tray icons are not supported. What is your system? 3. In all systems except Windows sockets are reset when the default gateway changes. In Windows, which is insecure by design, you should take care to start applications after you have established a VPN connection, unless you run Eddie with Network Lock enabled, which will block any possible traffic leak outside the tunnel. 4. If Network Lock is enabled, you will know immediately. :) Otherwise a manual check is required, by browsing on https://airvpn.org home page for example. Kind regards
  8. Hello! Probably the least difficult solution is using a Virtual Machine. Connect the host to a VPN server over Tor (OpenVPN over Tor). Then run a VM and attach the VM to the host via NAT (very important to achieve your purpose). Connect the VM to a different VPN server. Use your VM only to connect to the final services on the Internet. Traffic from the VM will be tunneled over OpenVPN over Tor over OpenVPN. The final services will not see a Tor exit-node IP address (instead they will see VPN server exit-IP address), while your ISP will not see that you connect to a VPN or that you run OpenVPN, it will see that you're using Tor. Things to consider carefully: if VPN traffic is "problematic" for your ISP or country, probably Tor traffic will be even more "problematic" performance will be hit seriously Kind regards
  9. Hello and thank you! Can you please check the URL? The FQDN does not exist at the moment. https://isitup.org/pluzz.france.tv $ drill @8.8.8.8 pluzz.france.tv ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 23313 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;; pluzz.france.tv. IN A ;; ANSWER SECTION: ;; AUTHORITY SECTION: france.tv. 1799 IN SOA a3-66.akam.net. hostmaster.akamai.com. 1560960371 43200 7200 604800 7200 ;; ADDITIONAL SECTION: ;; Query time: 60 msec ;; SERVER: 8.8.8.8 ;; WHEN: Tue Sep 1 14:25:13 2020 ;; MSG SIZE rcvd: 104 Kind regards
  10. @giganerd Yes, NL servers in Alblasserdam (i.e all of them) are connected to AMS-IX with 40 Gbit/s. The IANA database (for the readers: this is the only database that counts because https://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority) is also correct, entries of NL servers IP addresses show the Netherlands, without changes since 2016 (so there is apparently no explanation for such gross errors in poorly maintained databases? puzzling). If you find errors in whois please warn us. Example: $ whois 109.202.107.14 % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object refer: whois.ripe.net inetnum: 109.0.0.0 - 109.255.255.255 organisation: RIPE NCC status: ALLOCATED whois: whois.ripe.net changed: 2009-01 source: IANA # whois.ripe.net inetnum: 109.202.104.0 - 109.202.107.255 netname: GLOBALLAYER descr: Global Layer network country: NL admin-c: GL6540-RIPE tech-c: GL6540-RIPE remarks: INFRA-AW status: ASSIGNED PA mnt-by: GLOBALLAYER created: 2013-04-08T16:29:12Z last-modified: 2016-03-29T20:47:41Z source: RIPE person: Global Layer address: Postbus 190 address: 2950AD Alblasserdam address: Netherlands phone: +31 78 20 20 228 nic-hdl: GL6540-RIPE mnt-by: GLOBALLAYER created: 2011-08-04T20:36:25Z last-modified: 2017-10-30T22:14:45Z source: RIPE % Information related to '109.202.107.0/24AS49453' route: 109.202.107.0/24 descr: Global Layer network origin: AS49453 mnt-by: GLOBALLAYER created: 2016-03-17T11:39:02Z last-modified: 2016-03-17T11:39:02Z source: RIPE % This query was served by the RIPE Database Query Service version 1.97.2 (HEREFORD) Kind regards
  11. Thank you! As a small addition to your kind words, for you and all the readers interested in practical examples to set up permanent Network Lock rules with nft and MUCH more, you can: observe rules while Hummingbird is connected to some VPN server with network lock set to "nftables" mode examine the Bourne Again Shell scripts by @nwlyoc (yes, again 👏 ) https://airvpn.org/forums/topic/46717-interactive-wrapper-for-hummingbird-with-boot-script-and-default-network-lock/ Kind regards
  12. @nwlyoc @iwih2gk Good to know you solved the issue! Eddie "frontend" and "backend" communicate. If you block lo or even just localhost, you not only block Eddie communications, but even any other communication of your system with itself (i.e.any process with any process), with all sorts of bad consequences. Kind regards
  13. Hello, nobody likes a missing closing bracket. Kind regards
  14. @kaassouffle Hello! Eddie 2.18.9 does not run in Mojave, because of Apple notarization, we're sorry, Your alternative is good (Eddie 2.16.3 is not notarized), or you may consider even Eddie 2.19.4 beta (which runs just fine in Mojave). We provide Eddie 2.19.4 in two builds: one for Catalina, and one for Mavericks, Yosemite, El Capitan, Sierra, High Sierra and Mojave. Please see the Mac download page and click the button just below "If you run older than macOS Catalina systems, please download latest Eddie 2.19 beta version" - then download and install as usual. Kind regards
  15. @monstrocity Hello! Yes, of course, it might, but currently it does not. See by yourself each server's stats: open https://airvpn.org/status and click servers in Tokyo for insight including packet loss history and much, much more. Kind regards
  16. @Jamertol Hello! You can't but it's irrelevant. Make sure you have nothing listening to that port in any "other" system and it's not a security risk (something that does not exist is not a security risk by itself). Kind regards
  17. @bookth We don't understand what you mean. Maybe the following article helps? https://serverguy.com/kb/change-dns-server-settings-mac-os/ Kind regards
  18. Hello! In Android 9 and 10 you can enable traffic leaks prevention at system level (i.e. through the proper Android settings) and disable "VPN Lock" option. You will get much more flexible traffic leaks prevention than that which "VPN lock" option provides you with, as you will not need manual intervention in order to re-connect when an unrecoverable connection error comes into play. In Android 11 Eddie is untested, we're sorry. Kind regards
  19. @NaDre Thanks, very interesting information for everyone. Kind regards
  20. @NaDre Hello! So, out of curiosity, if you need your own DNS to resolve names in some specific "namespace" that's not ICANN's (OpenNIC and Namecoin come to mind, for example) you can't do it? If you need to tunnel traffic in a custom protocol over DNS queries to some service (different than a DNS server) to port 53 you are unable to reach it because that traffic is hijacked to some Mullvad DNS server? Kind regards
  21. Hello! It is possible. About two or three years ago, as a consequence of two requests by very advanced customers, we changed completely OpenVPN daemons subnets to make them unique across the whole infrastructure. That deep change main purpose was making multiple connections from the same system easier by preventing any chance of address conflicts. Connecting the same machine to multiple VPN servers is very beneficial for load balancing, failover and bandwidth aggregation. Please check for example the following, excellent guide: https://nguvu.org/pfsense/pfsense-multi-vpn-wan/ Kind regards
  22. Hello! We host about 29% of our infrastructure in M247 owned datacenters, approximately the same amount we had in 2019, 2018 and 2017. Cloudflare does not block M247 (although the settings can change during time). So you have the remaining 71% of AirVPN servers not on M247. On the Internet, without counting hidden services etc., you have 1.5 billion web sites. Cloudflare provides services to about 13 millions of them, i.e. 0.8% of all the known Internet web sites. However, Cloudflare provides services to more than 12% web sites of the top 10M (estimated amount of visitors). In general, stay away from services that don't accept access from VPN services or Tor or I2P, for obvious reasons. We have no plans to increase our presence in M247, as we showed you in the last 4 years (the latest, slight 1% increase is due to cancellation of Hong Kong servers, none of them were with M247). Kind regards
  23. @bigdaddy Hello! Because we need it. What you say about "rooting" :) is impossible because packets to exit-IP address port 89 are processed by a server service and are never forwarded to any client, moreover why should they be forwarded to your specific client instead of any other client? Same thing for any other port lower than 2048, there are simply NO rules to forward any such port to a specific client. Kind regards
  24. @Hotgloblin Hello! Check out latest builds, hopefully the issue will be fixed soon. Kind regards
  25. Hello! You did (for Firefox) here: https://airvpn.org/forums/topic/25140-the-issue-your-browser-is-avoiding-ipv6/?do=findComment&comment=81717 Quite the contrary, please re-read. Our IPv6 handling is fully compliant to RFC (including ULA choice). It's the setup of some Linux systems that's not compliant to RFC 3484 and that can be easily fixed. Additionally it's the default setup of Chrome and Firefox that makes them prefer IPv4 when possible. In our opinion, it is a good thing currently, because of the poor status of IPv6 infrastructure nowadays. Anyway browsers' setup can be fixed too, but it's outside the scope of our service. We don't see a valid reason to change our setup at the moment. We get 10/10 in https://test-ipv6.com from FreeBSD. It is anyway OT, the problem of the OP @Hotgloblin is related to apparent lack of OpenVPN IPv6 tunneling in certain firmware, even when IPv6 routes are pushed. Kind regards
×
×
  • Create New...