Jump to content
Not connected, Your IP: 216.73.216.134

All Activity

This stream auto-updates     

  1. Past hour
  2. Today
  3. Yesterday
  4. I wish I knew myself. Don't really know how to troubleshoot this, either. Might be comparable, but probably not better. From the roadmap I surmise that OpenVPN 2 will still be a single-core application as multithreading is not found in the feature list, so this bottleneck will persist. Conclusive tests must be done once 2.7 is stable and rolled out to some test servers. For now, I lost interest in finding out why DCO <> non-DCO doesn't work as my OpenVPN setup is now DCO <> DCO. Still using Wireguard primarily, though.
  5. So you weren't able to connect to an AirVPN server and test even yet? I wish I knew why no data flows if I try DCO on my end. I can connect to another VPN provider and it works well. I think it's expected that once DCO rolls out to server and client the speed is as good or better than wireguard.
  6. I cannot for the life of me figure out how to get QBT ACTUALLY listening on my open port on airvpn. I have my docker compose setup for a wireguard protocol. QBT is in network mode: "service:gluetun" has a vpn ip during testing but will not download ubuntu or any other test torrents. My network interface is set to tun0 all ipv4 addresses and trackers still time out and port test on airvpn says connection refused (111) any ideas would be much appreciated, i can pastebin my compose and logs if needed, starting to think home servers arent for me lol
  7. Hello! Actually what you say is plausible, although puzzling. Please try to generate a new key in your AirVPN account "Devices" panel, adjust the "device" linked to the forwarded port accordingly and connect with the new key. Check whether the problem gets resolved or not. The new key will give you a different VPN IP address and this test could provide some clue. Kind regards
  8. Well well, look at that, OpenVPN 2.7_beta3 (which apparently is rc1 according to --version) on both server and client with DCO enabled works.. the speedtest results are a bit inconclusive, though. OpenVPN v4 DCO: $ speedtest Retrieving speedtest.net configuration... Testing from Unknown (x)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Starry, Inc. (New York, NY) [5888.13 km]: 109.055 ms Testing download speed................................................................................ Download: 44.17 Mbit/s Testing upload speed...................................................................................................... Upload: 6.76 Mbit/s $ speedtest Retrieving speedtest.net configuration... Testing from Unknown (x)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Pilot Fiber (New York, NY) [5888.13 km]: 103.502 ms Testing download speed................................................................................ Download: 29.70 Mbit/s Testing upload speed...................................................................................................... Upload: 14.09 Mbit/s $ speedtest Retrieving speedtest.net configuration... Testing from Unknown (x)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Pilot Fiber (New York, NY) [5888.13 km]: 104.789 ms Testing download speed................................................................................ Download: 17.22 Mbit/s Testing upload speed...................................................................................................... Upload: 10.08 Mbit/s Wireguard v4: $ speedtest Retrieving speedtest.net configuration... Testing from Unknown (x)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by PVDataNet (New York, NY) [5888.13 km]: 110.869 ms Testing download speed................................................................................ Download: 6.73 Mbit/s Testing upload speed...................................................................................................... Upload: 30.61 Mbit/s $ speedtest Retrieving speedtest.net configuration... Testing from Unknown (x)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by PVDataNet (New York, NY) [5888.13 km]: 109.895 ms Testing download speed................................................................................ Download: 21.84 Mbit/s Testing upload speed...................................................................................................... Upload: 33.43 Mbit/s $ speedtest Retrieving speedtest.net configuration... Testing from Unknown (x)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Pilot Fiber (New York, NY) [5888.13 km]: 104.929 ms Testing download speed................................................................................ Download: 21.62 Mbit/s Testing upload speed...................................................................................................... Upload: 44.56 Mbit/s So, uuh.. my VPN server is maybe not the best benchmark. OpenVPN measured the highest download throughput in one test, but otherwise Wireguard seems to have higher and more consistent upload throughput. Latency is comparable.
  9. Have a working wireguard client AirVPN connection from my host and I set up port forwarding in order to allow incoming connections to a specific port. When I press "Test open" I get the result: No route to host (113) I think this error message hasn't anything to do with my setup specifics (open ports, firewall rules etc) but with the fact that the VPN peer I connect to cannot route traffic to the internal allocated address 10.x.x.x. Am I missing something here? (I can provide specifics but would prefer not to do it in public)
  10. Last week
  11. @tranquivox69 Hello! This timing is mainly up to the system, anyway we ask for a log (Log -> Paper plane icon), just in case. Thanks in advance. Kind regards
  12. The 32 bit Linux build has been deprecated with 2.24.0, and a stable Eddie for x86 Linux was never built. You may try building it yourself, or simply continue using 2.21.8 for the time being. But please consider reinstalling a 64 bit LMDE, CPUs from around 2010 or even a bit earlier support this.
  13. i have an an old linux mint debian edtion 32 bit computer with eddie version 2.21.8 It says update available for a while but it doesnt update in the Update Manager and if i try to download straight from the website there is only arm 32 bit which gives a wrong architecture message. I have an intel processor. should i do something or can i continue using this eddie version?
  14. I tried investigating on the timing a bit more, rebooting once more, in case it could help. The machine got to launcher's homescreen at xx.29.56. A different app that has an autolaunch setting (not a VPN app) got launched in the foreground at xx.30.04. Eddie connected to the wireguard VPN at xx.30.37. Inspecting the log, the first entry happened at xx.30.15. Eleven seconds after the other app got autolaunched. The wireguard connection was established 22 seconds later.
  15. And now, apparently, it works. What could have tripped me in thinking it wasn't working is the incredibly long time before the connection happens, once the launcher has started after reboot. I timed 53 seconds, which was enough for me to think it wasn't working, entering the app and seeing it connect to due settings (autoconnect when launching the app).
  16. Yeah, this gets asked over and over..
  17. Hello! Thank you very much. Yes, we ask again for a new log (Log -> Paper plane icon), thanks! Kind regards
  18. Spaces were wrong, due to horrible copy/paste functionality on Android TV. The commands had been issued correctly. The fact that the device doesn't allow that operation does not stop WG Tunnel to work correctly, every time. Every reboot, every resume from sleep. Let me know if there's specific debug functionality I could activate. Because regular log just shows Eddie doing nothing until I launch it, and then it connects automatically (as I previously explained). If there's more detail I can provide somehow, just let me know. Were it not for WG Tunnel I could conclude that "at boot" VPN was not doable on the device. But it is doable and WG Tunnel is open source, so I really, *really* would like Eddie to work correctly. I am a client of yours till 2029, as a minimum. I don't know what more I could provide as a vote of confidence in what you're doing. Keeping up hope. Thanks.
  19. Not really, go ahead. But maybe you shouldn't, anyway, since you cannot guarantee good throughput. Any circuit is getting needlessly delayed, what with the traffic entering the server, encrypted, being sent to you and you sending it out via the VPN server encrypted again and then on to the next node. But the most pressing problem are the requirements: Being able to handle 7000+ concurrent connections, 100k for 100 Mbit+ nodes, and 100 GB/month, better yet, 2+ TB/month of traffic. While a VPN server may be able to handle it, those are resources which will be missing for any other user of that server. Guard nodes aka entry nodes have a similar requirement. obfs4 bridges don't have any of these requirements; you can run one with a small footprint.
  20. If you view some live stream from TelemundoPR while the Network tab is open in the Developer Console of your browser (accessible via Ctrl-Shift-I), do you get 403 errors for any request?
  21. Hello! We're very glad to inform you that a new 1 Gbit/s full duplex server located in Singapore is available: Azelfafage. The AirVPN client will show automatically the new server. If you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts OpenVPN connections on ports 53, 80, 443, 1194, 2018 UDP and TCP, and WireGuard connections on ports 1637, 47107 and 51820. Just like every other Air server, Azelfafage supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/Azelfafage Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team 
  22. Hello! We're very glad to inform you that a new 1 Gbit/s full duplex server located in Auckland (NZ) is available: Mothallah. The AirVPN client will show automatically the new server. If you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts OpenVPN connections on ports 53, 80, 443, 1194, 2018 UDP and TCP, and WireGuard connections on ports 1637, 47107 and 51820. Just like every other Air server, Mothallah supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/Mothallah Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team 
  23. @meatloafmondays Hello! Yes, please, the Bluetit log may help understand the cause of the problem indeed. You can extract it from the systemd journal if your system is based on systemd: sudo journalctl | grep bluetit > bluetit.log or from syslog (typically in /var/log) in other systems not based on systemd. Kind regards
  24. I have a kinda 2 prong issue here. 1. The bluetit service does not autoconnect at boot, even with autoconnect enabled in the config file. I currently have to have goldcrest --air-connect set as a cronjob to get it up at boot. 2. Despite trying to set a preferred server (Sarin) in both the goldcrest and bluetit config files, it refuses to connect to them. Most of the time it's connecting to low-bandwidth slow EU servers. The only setting I was able to get something out of was banning CAN servers. I've gone through the readme for AirVPN suite multiple times and I can barely even find anyone online who uses suite. Any ideas for how to fix this? I can post whatever logs are needed.
  25. It's the Cochran's formula. When you want a 95% confidence with an error margin of 5%, you need 383 samples out of 322 millions or infinite population. With 1009 samples you get a confidence of 95% with an error of +/-3.1%, which is accurate and acceptable for our business and for this conversation to show that your claim must be incorrect. However the Cochran's formula assumes that there's no bias in picking the sample and the above is based on an optimistic estimate of p=0.5 variability. Therefore, let's compare other surveys. An important source is GWI as it covers 2.7 billion Internet users through various tools. You must pay for their reports and insights but we found that Meltwater / We Are Social / Kepios published for free some GWI data here: https://learn.meltwater.com/rs/814-WJU-189/images/2025_Kepios_Digital_Global_Overview_Report.pdf Another source (using different tools) such as Anlyzify / Shopify publishes a few data here: https://analyzify.com/statsup/vpn You may notice that all of the above show consistent data within the confidence and error margins and they all agree to compute the amount of Internet users connecting to VPNs to 1.7 billion persons globally. There are even more surveys confirming this. They are reserved to paying companies but you can trust us, they show the same within a 5% error margin. Your estimate of 10-15% therefore lacks credibility as it is outside the error margin of many other reputable surveys which are consistent with each other. You may have a problem in how you picked your sample, it could have been unintentionally biased. On the other hand, if your sample amount is n0=40 with a high variability then you have a confidence level of 90% on an error margin of 13%, which would explain the discrepancy with no need to assume a bias. Thus VPN usage is indeed mainstream, if we agree to consider "mainstream" the usage of something with an agreed frequency by 1.7 billion people out of 6.4 billion people (26.5%). It's a design choice based on community feedback and a few considerations. The main consideration is preventing lock out from remotely administered machines, whereas community considered a permanent system modification too invasive for a program that has the responsibility to run with admin privileges. Anyway, it's true that the the previous considerations have been partially ignored by the new "persistent network lock" implemented in the AirVPN Suite for Linux daemon (Bluetit). The daemon, when this option is enabled (anyway it's off by default), sets network lock as soon as the machine has a default gateway, emulating therefore your request (as long as the daemon is allowed to start during the system bootstrap), but avoiding at the same time to set permanent changes to the system. It must also be said that implementing permanent "block all outgoing Internet traffic" rules by default on a system is a trivial task. Then, when the Network Lock comes in, the traffic towards VPN servers is re-allowed, permitting VPN connections... thus the matter does not seem relevant at all: the idea behind the whole matter is that if you know how to use a firewall, you need 30 seconds or so to set proper permanent rules; if you don't know, it's preferable that a software does not modify permanently your system in a way that you might not be able to roll back on your own. The type of double hop you suggest is a client side feature that you can easily achieve by yourself (feel free to open a ticket if in doubt). It may be integrated on our software, no rocket science here, but remember that double hopping on servers administered by the same entity is not an optimal solution and could potentially provide a false sense of security. As suggested, running Tor over a VPN connection is a much, much more robust solution for privacy purposes. The VPN hides Tor usage to your ISP and snoopers, while at the same time helps build a circuit outside a potential cage you might have been put inside by your country regime. At the same time Tor hides from the VPN servers any information related to your Internet usage. With that said, double hop for marketing reasons and for specific needs tied to jurisdictional monitoring could make sense, so we will re-consider its integration in the future. Kind regards
  26. Ah, yes, it's the DDoS protection mechanism. I analyzed it a little once:This part really needs JavaScript, otherwise you're a bot to the software. I see. I might check that out later myself.
  27. Well, there you have it. The primary goal was to prepare the network for further abuse, not to end some VPN process. Collateral damage, yes, VPN connections were dropped, but not what I'm gunning for as an attacker.
  28. I've been having the same thing on Arch Linux since ovpn-dco-dkms was available, but since OpenVPN's documentation itself says that a non-DCO server can serve DCO clients and vice versa, I think it's got something to do with my client config somewhere. Anyway, since I've got an OpenVPN server running myself, I'll think about compiling 2.7 there and on the client and test a "full" DCO setup this way.
  29. Hello! You polluted both commands with syntax errors (note the spurious spaces). Please re-check. If you enter the correct commands and you still get the other errors you reported then your device is probably customized in a way that doesn't allow this operation, unfortunately. Kind regards
  1. Load more activity
×
×
  • Create New...