Jump to content
Not connected, Your IP: 3.226.72.118

Staff

Staff
  • Content Count

    8916
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1290

Everything posted by Staff

  1. @tOjO Hello! We're glad to know that the problem is resolved. However, can you please send us Bluetit log taken just after the problem has occurred (login failure at bootstrap)? We can't understand how Bluetit could download the "manifest file" (according to the log) if you had no connectivity. In such a case Bluetit should read the last available "manifest" file from the local storage, and print the fact on the log. sudo journalctl | grep bluetit Thank you in advance. Kind regards
  2. Hello! This is incorrect, Tor Browser has been protecting you against this attack since years ago. Currently, Brave and Firefox are quite effective, according to the paper itself. However, the author considers Firefox ability to make the attack fail as a side effect of a bug. The attack itself is quite well known, although in the recent past it focused on big LSOs spread throughout various HDD locations and not trivially erasable by the average user to be more effective, because Flash was used by the majority of users. Kind regards
  3. Hello! Just use Brave, Firefox or the Tor Browser (Tor browser appears as the best choice): https://tor.stackexchange.com/questions/21940/will-tor-block-favicons-by-default EDIT: also avoid to browse via Thunderbird. See also the previous message. Kind regards
  4. Hello! Well, saying that favicons are "undeletable" is a tiny overstatement. They are not written once and for all in a PROM. 😋 Check where your browser keeps favicons and delete them, when it's not possible to reject them trivially in browser's settings. For example, latest Firefox releases can't be configured to not to ask for favicons (in the past, that was possible). Firefox and Thunderbird keep an SQLite db for them in your profile. For example: $ find ~ -type f -name '*avicon*' /home/myuser/.mozilla/firefox/blabla.default-release/favicons.sqlite /home/myuser/.mozilla/firefox/blabla.default-release/favicons.sqlite.wipemeoutbeforeyougogo /home/myuser/.mozilla/firefox/blabla.default-release/favicons.sqlite-wal /home/myuser/.thunderbird/blabla.default/favicons.sqlite /home/myuser/.thunderbird/blabla.default/favicons.sqlite-wal But check the cache too just in case (and incidentally remember that Tor browser does NOT block favicons and that Firefox actually issues requests to re-fetch favicons that are already present in the cache.) to be clearer, currently you are already protected against favicons based tracking & fingerprinting if you run Firefox or the Tor browser https://tor.stackexchange.com/questions/21940/will-tor-block-favicons-by-default While Firefox and Thunderbird don't run, rename those files for your tests, nuke the cache, and you'll see that nothing breaks except favicons (but verify by yourself). You can also inspect the db to check more thoroughly, and you can to keep a script that "takes care" of them whenever you need it. A quick and dirty solution is also creating a new account, do what you need to do in single or selected web sites (with Tor browser or anyway without allowing scripts if necessary, and following identity separation and any other good practice), and wipe it out after usage. Kind regards
  5. Hello! We are almost ready to publish a public beta version, it's a matter of days. Kind regards
  6. @Unito_ Windows 7 has been abandoned since quite some time: mainstream support ended on January 13, 2015, while extended support ended on January 14, 2020. OpenVPN 2.5 does not have anymore a dedicated installer for Win 7. Download the proper OpenVPN 2.4.10 package for Windows 7, again in https://openvpn.net/community-downloads/ and repeat the procedure. Also consider seriously to upgrade to some supported system. Kind regards
  7. @nocturnaltabernacle Hello and thanks! The SERVFAIL error message suggests that Google infrastructure could not contact airvpn.org authoritative server. It seems it was a short period problem. Please feel free to warn us if you see it re-occurring. Kind regards
  8. $ drill @8.8.8.8 airvpn.org ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 32899 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; airvpn.org. IN A ;; ANSWER SECTION: airvpn.org. 347 IN A 5.196.64.52 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 17 msec ;; SERVER: 8.8.8.8 ;; WHEN: Sat Feb 13 10:59:57 2021 ;; MSG SIZE rcvd: 44
  9. Hello! Please try the following: make sure to download the correct package for your system here: https://openvpn.net/community-downloads/ make sure you can gain administrator privileges uninstall OpenVPN, disable any antivirus/antimalware/anti* and all that jazz and reboot the system (remember to re-enable them later) install OpenVPN and make sure to authorize drivers installation If the driver installation still fails, you can be sure that the problem is not Edde related. Check carefully the error message you get during installation and report it. Kind regards
  10. @Tazhill Thanks! In order to understand the cause of the issue we need to know whether the problem occurs when some network interface has IPv6 disabled (problem is then expected and explained) or not (problem is then unexpected). The system report will show that. We also ask you to generate the system report while the system is still connected to the VPN (thanks to IPv6 layer block), so that we can see even the properties of the tun virtual network interface used by OpenVPN. Kind regards
  11. @grammarye Hello! Please try with WantedBy= and combine udev and systemd, as detailed here: https://superuser.com/questions/851846/how-to-write-a-systemd-service-that-depends-on-a-device-being-present A much simpler solution, worth a test, is reported here: https://unix.stackexchange.com/questions/360214/systemd-service-run-when-network-interface-up-down-eth0 Kind regards
  12. Hello! There is no way to do that, but it's irrelevant. Just make sure that the port does not exist on the devices where you don't want to receive packets. Kind regards
  13. @Aronos Hello! By disabling IPv6 in your Wireless LAN adapter Wi-Fi you made Eddie and OpenVPN unable to connect. The IPv6 layer combo box has not been set to "Block", according to the system report you kindly included. We see that you set "Internet protocol for connection" to "IPv4 only", but that's a different thing. Please open "Preferences" > "Networking" window and set the "IPv6 layer" combo box to "Block", then click "Save" and try again. Alternatively, make sure that IPv6 is enabled in your network interfaces. Kind regards
  14. @Tazhill Hello! Are you 100% sure that your system as well as all network interfaces have IPv6 enabled? If so, can you open a ticket to investigate the matter more thoroughly? Please include a system report ("Logs" > LIFE BELT icon > copy all icon > paste into your message) generated while the system is still connected successfully thanks to the "blocked" IPv6 layer. Kind regards
  15. Hello! Yes, that's plausible. The outcome we and our customers had with Wireguard can have been capped by server bandwidth availability (which may become more significant with WIreeguard than OpenVPN, according to your report) and other factors. Anyway it's a real world/real life test performed between different providers and on equal ground with OpenVPN. On the other end, your OpenVPN findings are low when compared to our customers' and ours.. With weaker CPUs (old i7) our clients achieve much higher performance than yours, up to 700 Mbit/s, with a single instance, while on the server side, with a slightly weaker CPU than yours (but maybe stronger on a per.-core basis, which is crucial with OpenVPN), we could manage to beat 700 Mbit/s on a single OpenVPN daemon connected to about 200 clients. Another factor that comes to mind is the SSL library, which you don't need to worry about when you run Wireguard, but which is vital for OpenVPN performance. Did you compile the library with high optimization for your own server? We recommend OpenSSL currently in x86-64 systems, because it is now remarkably faster than mbedTLS which lacks asm. NOTE: we have never tested LibreSSL and we don't know whether it's a pain to link OpenPVN against LibreSSL. If you need to beat the current performance you report, on top of OpenVPN and OpenSSL optimizations for your system when you build them, the most obvious way is running multiple instances, each one with a different CPU affinity. With the large cores amount you have, you can even aim to saturate your 10 Gbit/s line. Currently our VPN servers Xuange and Ain work around 2-3 Gbit/s with a very low load (around 11 on 32 "CPU" systems). Kind regards
  16. Hello! The actual official cause is lack of IPv6 support either at system level or in any of the network interfaces, including the tun/tap one. It has been verified several times. Should you find cases for which IPv6 layer needs a block inside Eddie preferences even when IPv6 is fully supported by the system and is enabled on all network interfaces, including TAP-Windows or wintun, please report to Clodo. Kind regards
  17. Yes I know this, but can you tell Eddie to only activate Network Lock when connected to VPN, and disconnect when disconnected? Hello! No, Network Lock needs activation BEFORE a VPN connection starts. Anyway Eddie allows "events", check "Preferences" > "Events". You can have a command/script when each event takes place. For security reasons, events linked items are NOT launched with root privileges, so if you need some operation needing root privileges you need take care yourself of it. Only with an operator's input, by default. If you order a disconnection, Eddie will remain disconnected. But if the connection is lost for any reason other than explicit operator's order, Eddie will try to re-connect continuously in any case. You can modify this behavior only through events. For example, if you define an event at VPN disconnection that kills Eddie itself, you will have an approximation of what you want, i.e. "tell Eddie to disconnect when disconnected". However, if you kill Eddie, make sure to reset firewall rules too, because Eddie might fail to restore previous firewall rules (signal handling needs some improvement). You will need to gain root privileges in your script in order to kill Eddie backend and manipulate firewall rules. Kind regards
  18. Hello! && means the logical and in various shell languages, bash (Bourne Again Shell) included, therefore: if (and only if) a command (in this case sleep) is executed and exits successfully, then the command following && will be executed too. This is a short-circuit evaluation. About sleep, enter the following command in a terminal man sleep for more information. In our previous messages we never talked about auto running Eddie. Please re-read at your convenience. You can tell Eddie to activate Network Lock or not when Eddie itself is launched. You can tell Eddie to connect to some VPN server at startup. Kind regards
  19. @Terry Stanford Hello! If you run Eddie GUI, you can configure Eddie to activate Network Lock at startup, check "Activate Network Lock at start" in "Preferences" windows. You can also configure Eddie to connect when it is launched. If you run Eddie CLI, in a screen or tmux session run something like "sleep n && eddie-cli <options here>" where n is in seconds. Kind regards
  20. @frpergflf Hello! SELinux correctly prevents systemd to delete the lock file. That's an illegal operation that systemd wants to perform and that tells something on how systemd is designed. Bleutit crash is caused by the fact that systemd bombards with SIGTERM Bluetit (and in general any real daemon). Under specific circumstances, i.e. when 2 or more SIGTERM signals are sent to Blueit almost simultaneously, Bluetit crashes, because the promise object has been already depleted when the 2nd or nth SIGTERM is received. Again, this incomprehensible behavior tells something about how systemd is designed, but at least it made us find a bug which might cause crashes in any other similar circumstance (imagine if you manage to send SIGTERM from two "kill" commands synced to be executed almost simultaneously). Fix will be of course implemented in the next, imminent version. Kind regards
  21. @Shiloh @Tazhill Hello! The most common cause of the issue is that IPv6 is not supported by system OR some network interface (virtual tun included). In both cases you have two options: 1) Enable IPv6 2) Tell Eddie to "block" IPv6 layer, i.e. the solution aopplied by Shiloh. Kind regards
  22. @harryhoudini Hello! 1) You can use the ListenAddress option in the configuration file. Read the manual for details. Consider whether binding it to any interface (ListenAddress *) in order to make your system accessible even when it's not connected to the VPN. Restart sshd to apply the change. Your current ssh session will not be reset and you will remain connected. 2) We're sorry, maybe we don't understand the question, feel free to elaborate. Consider that if your machine is in a VPN, it's in it, regardless of the exact connection procedure. 3) AirVPN servers exit-IP addresses might change only under exceptional circumstances. Make sure that your machine connects always to the same VPN server, or the same defined range of servers, so you can rely on the same IP address to reach the ssh daemon. Check also https://airvpn.org/faq/servers_ip Note that there is no catch 22. Configure and re-start sshd, see answer 1, then connect the VPN through a terminal multiplexer (consider using screen for example https://linux.die.net/man/1/screen or tmux https://linux.die.net/man/1/tmux.). Once the connection is established, your ssh socket is reset, and you must re-connect, (via the VPN server exit-IP address this time). screen or tmux will have detached the OpenVPN or Eddie process which will continue to run flawlessly even though your previous session is killed for the disconnection (if needed you can of course re-attach OpenVPN/Eddie to your own future session). See also: https://www.shell-tips.com/linux/disown-a-running-shell-process-and-reattach-it-to-a-new-screen/ For a more general approach, check Nadre's articles: https://github.com/tool-maker/VPN_just_for_torrents/wiki/Maintaining-SSH-Access-Using-a-VPN-on-a-Remote-Linux-Server Kind regards
  23. @frpergflf Thank you, the log entry showing a crash problem "Process 133092 (bluetit) of user 0 dumped core." and its previous and following entries seem very relevant. The problem will be soon under investigation. Kind regards
  24. @frpergflf Hello! Allowing access to those directories to group "airvpn" is a choice of each superuser. For security reasons, by default the installer sets them belonging to root user and root or wheel group to comply to the best security practices consolidated in UNIX in the last 30 years. In general, as an optimal security solution, we want that Bluetit files can be edited only by root and sudo-ers, while Goldcrest files (but not Goldcrest binary) can be changed only by users belonging to airvpn group. The lock file removal failure after Bluetit clean stop order by systemd is unexpected. When the problem re-occurs, would you be so kind to send us Bluetit log? sudo journalctl | grep bluetit @asdfasdfasdfasdfasdf No, it is not. If you proceed to implement, don't forget that Bluetit is a daemon. @dL4l7dY6 @airvpnclient A source of Bluetit instability in OSMC and Raspbian 32 bit has been detected, and it's libcurl . The linked library explodes now and then. The problem has been resolved with specific libcurl linking. Development is now focused on a new Network Lock approach, to make the whole environment more secure especially during a system bootstrap. Once it is implemented (a matter of just a few days) we will be ready for testing and soon after a new release will follow, perfectly compatible with OSMC too. Kind regards
  25. @Maggie144 Hello! Since Network Lock is enforced via pf rules, which act directly on the kernel filtering table, it is not plausible that Apple services can bypass them. Leaks observed on Catalina and Big Sur with other software (not our software) take place because filtering rules are enforced via specific network API. The specific network filtering exceptions (for Apple programs) hard coded in macOS Catalina and Big Sur filtering API, which caused a lot of controversies (and rightly so), allow the horrendous behavior. Actually, lack of traffic leaks when Eddie or Hummingbird Network Lock is active on Intel Mac has been thoroughly verified by us through external network sniffers. We confirm that nothing, including Apple services and apps, is able to bypass the firewall (pf) rules. We can perform the same verification on Mac M1 in the near future. The problem in iOS is worse and can't be resolved, because in iOS devices you are not in control of the device filtering table (and you are not in control of the device in general). Anyway we do not write software for iOS, as you know. Should, in the future, "Apple Silicon" platforms evolve in iOS-like system which the user can not control, then they will be unsuitable for purposes where privacy and a layer of anonymity are a priority. We doubt anyway that Apple will expel its own customers from administrative device control like it did with iOS, but let's wait and see. Kind regards
×
×
  • Create New...