Leaderboard

@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

@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

As you can probably see, the error message is different. Ergo, open your own thread or simply search before you post. If you'd done the latter, you would probably find a post like this:

They explain a problem you will encounter and then (if you follow more links) ways of solving the problem. As I said in the same post, I DO this! It IS possible. If you want me to provide a customized recipe just for you here in this thread, I am going to disappoint you. UPDATE: ======= I changed my mind. Here is a recipe. I did not actually explain the problem above. The problem is that the default gateway gets changed by OpenVPN, and that breaks your current SSH connection unless you set up appropriate routes before you start OpenVPN. It is assumed here that the default gateway interface before OpenVPN is started is "eth0". This is the usual convention for Linux systems. It should ensure that when a connection to eth0 is made, even if eth0 is not the default gateway interface anymore, response packets for the connection go back on eth0 again. # set "connection" mark of connection from eth0 when first packet of connection arrives sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234 # set "firewall" mark for response packets in connection with our connection mark sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321 # our routing table with eth0 as gateway interface sudo ip route add default dev eth0 table 3412 # route packets with our firewall mark using our routing table sudo ip rule add fwmark 4321 table 3412=== UPDATE to UPDATE: The above works fine for me on Debian Jessie. But on an older Wheezy system I have just found that I need to add "via" to the routing table entry: # our routing table with eth0 as gateway interface sudo ip route add default dev eth0 via 12.345.67.89 table 3412There "12.345.67.89" must be the original non-VPN gateway.

Probably because they decided not to use women and children as suicide bombers, or fire rockets indiscriminately into civilian areas. But this isn't really the place to discuss it.