suroh 1 Posted ... (edited) @Staff thanks for the help. The installation went well and systemd is reporting that bluetit is running. I'm not sure if this is intentional, but the airvpn user is making a home folder. The home folder is more or less empty, can safely I change this user to have no login, no home folder? Edited ... by suroh Quote Share this post Link to post
Staff 9972 Posted ... @suroh Hello! We're glad to know that the quick fix resolved the issue. Quote I'm not sure if this is intentional, but the airvpn user is making a home folder. The home folder is more or less empty, can safely I change this user to have no login, no home folder? Yes, it's intentional, as it is a more flexible and secure solution allowing exclusive aivpn user setup, place for its files etc., log into its own session to run Goldcrest or any other Bluetit client. Sure, you can do as you prefer, or you can even add your own user to the airvpn group, according to your security needs and preferences, but consider seriously not to run Goldcrest with root privileges and not to add airvpn user to the sudo-ers. By doing the above, you would jeopardize a portion of the security model offered by the client-daemon architecture. Kind regards Quote Share this post Link to post
airvpnclient 13 Posted ... Anyone else having instability of connection with bluetit? Jan 22 23:09:01 osmc bluetit[7060]: Updating AirVPN Manifest Jan 22 23:09:03 osmc bluetit[7060]: AirVPN Manifest successfully retrieved from server Jan 22 23:18:13 osmc bluetit[7060]: Tunnel Options:V4,dev-type tun,link-mtu 1524,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client Jan 22 23:18:13 osmc bluetit[7060]: Peer Info: Jan 22 23:18:13 osmc bluetit[7060]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.org, signature: RSA-SHA1 Jan 22 23:18:13 osmc bluetit[7060]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Alwaid/emailAddress=info@airvpn.org, signature: RSA-SHA512 Jan 22 23:18:13 osmc bluetit[7060]: SSL Handshake: peer certificate: CN=Alwaid, 4096 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD Jan 22 23:18:13 osmc bluetit[7060]: LZO-ASYM init swap=0 asym=1 Jan 22 23:18:13 osmc bluetit[7060]: Comp-stub init swap=0 Jan 22 23:24:03 osmc bluetit[7060]: Updating AirVPN Manifest Jan 22 23:24:07 osmc bluetit[7060]: AirVPN Manifest successfully retrieved from server Jan 22 23:30:06 osmc connmand[277]: (null) {RX} 1822320 packets 2098696279 bytes Jan 22 23:30:06 osmc connmand[277]: (null) {TX} 1351799 packets 121248981 bytes Jan 22 23:30:06 osmc connmand[277]: (null) {update} flags 4240 <DOWN> Jan 22 23:30:06 osmc connmand[277]: tun0 {newlink} index 3 address 00:00:00:00:00:00 mtu 1500 Jan 22 23:30:06 osmc connmand[277]: tun0 {newlink} index 3 operstate 2 <DOWN> Jan 22 23:30:06 osmc connmand[277]: (null) {del} route fe80:: gw :: scope 0 <UNIVERSE> Jan 22 23:30:06 osmc connmand[277]: (null) {del} address 10.8.135.23/24 label tun0 Jan 22 23:30:06 osmc connmand[277]: tun0 {dellink} index 3 operstate 2 <DOWN> Jan 22 23:30:06 osmc connmand[277]: (null) {RX} 1822320 packets 2098696279 bytes Jan 22 23:30:06 osmc connmand[277]: (null) {TX} 1351799 packets 121248981 bytes Jan 22 23:30:06 osmc connmand[277]: (null) {remove} index 3 Jan 22 23:30:06 osmc systemd[1]: bluetit.service: Main process exited, code=killed, status=6/ABRT -- An ExecStart= process belonging to unit bluetit.service has exited. Jan 22 23:30:06 osmc systemd[1]: bluetit.service: Failed with result 'signal'. -- The unit bluetit.service has entered the 'failed' state with result 'signal'. Quote Share this post Link to post
airvpnclient 13 Posted ... For the time being, I am going to stop testing this and go back to a hummingbird solution as suggested by @Staff earlier. For purposes of an always-on from boot-to-shutdown service, I just need something simple to set and maintain the tunnel, dns-switch, and firewall. I like where you are going with bluetit and its clients, but I will wait for the next release before testing further. Thanks, Quote Share this post Link to post
Staff 9972 Posted ... @airvpnclient Yes, every OSMC user must wait for Bluetit next version in any case. Bluetit 1.0.0 does not run properly in OSMC because of OSMC customization. Next Bluetit release will aim at full OSMC compatibility. Kind regards Quote Share this post Link to post
airvpnclient 13 Posted ... Thanks @Staff I may be onto something for OSMC. Found and followed these instructions and got eddie-ui cli working (it was not): There is no dns forwarder enabled by default in OSMC $ sudo apt-get install -y dnsmasq $ sudo nano/etc/dnsmasq.conf # uncomment the settings of “domain-needed” and “bogus-priv” $ systemctl enable dnsmasq $ systemctl start dnsmasq Quote Share this post Link to post
thewolfman8326 0 Posted ... Is there any plan to put these in the AUR/make a PPA for them for easier updates? Quote Share this post Link to post
airvpnclient 13 Posted ... 15 hours ago, airvpnclient said: Thanks @Staff I may be onto something for OSMC. Found and followed these instructions and got eddie-ui cli working (it was not): There is no dns forwarder enabled by default in OSMC $ sudo apt-get install -y dnsmasq $ sudo nano/etc/dnsmasq.conf # uncomment the settings of “domain-needed” and “bogus-priv” $ systemctl enable dnsmasq $ systemctl start dnsmasq Nah the tunnel comes up but -- times out with a bluetit abort signal at some interval. May put a watchdog script on it and just keep resetting it when it fails. Quote Share this post Link to post
Staff 9972 Posted ... @airvpnclient Thanks! The new issue you reported in OSMC is confirmed and under investigation too. Kind regards 1 airvpnclient reacted to this Quote Share this post Link to post
airvpnclient 13 Posted ... Still working on getting a secured Kodi box that is netlocked using software from the AirVPN Suite. I have, for the moment given up on OSMC and am working on an Xbian (highly custom Debian Buster distro). I am able to run the hummingbird application and it works great, but when/if hummingbird fails, the host goes back to default iptables rules and is effectively wide open so I can't count on it to lock the host to the AirVPN network like Eddie does on my desktop. What does hummingbird do with respect to network locking by default? Currently when I run hummingbird on the rpi the following iptables (and ip6tables which I haven't quoted) rules are set: # /usr/sbin/ip6tables-legacy -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all anywhere anywhere REJECT all localhost anywhere reject-with icmp6-port-unreachable DROP all anywhere anywhere rt type:0 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp router-advertisement HL match HL == 255 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-solicitation HL match HL == 255 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp neighbour-advertisement HL match HL == 255 ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp redirect HL match HL == 255 ACCEPT all fe80::/10 anywhere ACCEPT all anywhere ip6-mcastprefix/8 ACCEPT all anywhere anywhere state RELATED,ESTABLISHED ACCEPT all anywhere anywhere DROP all anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination DROP all anywhere anywhere rt type:0 ACCEPT all anywhere anywhere DROP all anywhere anywhere Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all anywhere fde6:7a:7d20:5e5::1 ACCEPT all anywhere anywhere DROP all anywhere anywhere rt type:0 ACCEPT all fe80::/10 anywhere ACCEPT all anywhere ip6-mcastprefix/8 ACCEPT all anywhere anywhere ACCEPT all anywhere anywhere state ESTABLISHED DROP all anywhere anywhere But when I run Eddie on my desktop, I get a very different set of rules using the network lock: # /usr/sbin/iptables-legacy -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- 255.255.255.255 anywhere ACCEPT all -- 192.168.0.0/16 192.168.0.0/16 ACCEPT all -- 10.0.0.0/8 10.0.0.0/8 ACCEPT all -- 172.16.0.0/12 172.16.0.0/12 ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere DROP all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere DROP all -- anywhere anywhere Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere 255.255.255.255 ACCEPT all -- 192.168.0.0/16 192.168.0.0/16 ACCEPT all -- 10.0.0.0/8 10.0.0.0/8 ACCEPT all -- 172.16.0.0/12 172.16.0.0/12 ACCEPT all -- 192.168.0.0/16 base-address.mcast.net/24 ACCEPT all -- 10.0.0.0/8 base-address.mcast.net/24 ACCEPT all -- 172.16.0.0/12 base-address.mcast.net/24 ACCEPT all -- 192.168.0.0/16 239.255.255.250 ACCEPT all -- 10.0.0.0/8 239.255.255.250 ACCEPT all -- 172.16.0.0/12 239.255.255.250 ACCEPT all -- 192.168.0.0/16 239.255.255.253 ACCEPT all -- 10.0.0.0/8 239.255.255.253 ACCEPT all -- 172.16.0.0/12 239.255.255.253 ACCEPT icmp -- anywhere anywhere icmp echo-reply ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere ec2-63-33-78-166.eu-west-1.compute.amazonaws.com ACCEPT all -- anywhere ec2-52-48-66-85.eu-west-1.compute.amazonaws.com ACCEPT all -- anywhere ec2-54-93-175-114.eu-central-1.compute.amazonaws.com ACCEPT all -- anywhere ec2-63-33-116-50.eu-west-1.compute.amazonaws.com ACCEPT all -- anywhere 106.19.9.185.in-addr.arpa ACCEPT all -- anywhere 108.19.9.185.in-addr.arpa ACCEPT all -- anywhere 109.19.9.185.in-addr.arpa ACCEPT all -- anywhere 110.19.9.185.in-addr.arpa ACCEPT all -- anywhere 37.120.155.178 ACCEPT all -- anywhere 37.120.155.180 ACCEPT all -- anywhere 37.120.155.181 ACCEPT all -- anywhere 37.120.155.182 ACCEPT all -- anywhere 194.127.64.217.in-addr.arpa ACCEPT all -- anywhere 196.127.64.217.in-addr.arpa ACCEPT all -- anywhere 197.127.64.217.in-addr.arpa ACCEPT all -- anywhere 198.127.64.217.in-addr.arpa ACCEPT all -- anywhere 90.251.187.194.in-addr.arpa ACCEPT all -- anywhere 92.251.187.194.in-addr.arpa ACCEPT all -- anywhere 93.251.187.194.in-addr.arpa ... ... and many more lines like this. I am not good at parsing these rulesets, but it seems to me that the hummingbird application rule set is not as extensive, and in any case they do not persist when the app stops. I am thinking of scripting something kludgy like this to run in rc.local and somehow trigger loading them again if the tunnel drops. #!/bin/bash /usr/sbin/hummingbird & /usr/sbin/iptables-legacy-restore < /etc/airvpn/airvpn.tables && /usr/sbin/ip6tables-restore </etc/airvpn/airvpn.6tables using my saved rules from an eddie desktop session with netlock on. Am I missing something? Thanks again! Quote Share this post Link to post
airvpnclient 13 Posted ... Eureka! Eddie-cli up and running with netlock on Xbian Buster with the same iptables setting as Eddie on my desktop. Looking forward to the OSMC friendly release and until then, I will stop bugging you guys. Though I note that when I kill Eddie, it kills the netlock which is not my preferred result. Great software. Thanks again. Quote Share this post Link to post
Staff 9972 Posted ... @airvpnclient Hello! Hummingbird sets the necessary rules only (maximum optimization), while Eddie opens traffic to every AirVPN node IPv4 address, therefore it needs some thousand rules. Hummingbird is designed in a way that when a disconnection takes place, Network Lock gets disabled, while Eddie keeps Network Lock until you explicitly tell it to disable Network Lock or exit. Therefore Hummingbird is not a suitable software if you need Network Lock while disconnected, but you can consider a "permanent" Network Lock with proper rules by default, so that traffic is blocked when Hummingbird restores default rules. Bluetit will have a safer behavior, more similar to Eddie's behavior, but you need to remember (as you noticed) that currently Bluetit will not activate Network Lock if an account login fails. We are working to fix this flaw as well, and quickly, in the next imminent release already. Kind regards Quote Share this post Link to post
airvpnclient 13 Posted ... Well, for what it is worth, Eddie-cli is working on Linux xbian 4.19.90+ #1 SMP PREEMPT Wed Dec 18 20:39:10 CET 2019 armv7l GNU/LinuxSpeedtest result given 15/10 connection that is not otherwise idleHere is resource use during speedtest download (and yes I have changed my password that I am flashing here): Quote Share this post Link to post
datastreams 0 Posted ... Anyone know of a tutorial or video demonstration/guide for the Airvpn Suite. I would be gratfull for any as i am more of a visual learner. thanks Quote Share this post Link to post
dL4l7dY6 3 Posted ... I have successfully installed the new Bluetit software on my Pi download box but it doesn't appear to be very stable although the last run was 22 hours. I'm not seeing anything significant in syslog except for: pi@pidown:~ $ sudo service bluetit status ● bluetit.service - AirVPN Bluetit Daemon Loaded: loaded (/etc/systemd/system/bluetit.service; enabled; vendor preset: enabled) Active: failed (Result: signal) since Thu 2021-02-04 09:09:00 GMT; 29min ago Main PID: 8552 (code=killed, signal=ABRT) Feb 04 08:50:42 pidown bluetit[8552]: Peer Info: IV_VER=3.6.6 AirVPN IV_PLAT=linux IV_NCP=2 IV_TCPNL=1 IV_PROTO=30 IV_CIPHERS=AES-256-GCM IV_LZO_STUB=1 IV_COMP_STUB=1 IV_COMP_STUBv2=1 UV_IPV6=no IV_GUI_VER=Bluetit - AirVPN OpenVPN 3 Service 1.0.0 IV_SSL=OpenSSL 1.1.1d 10 Sep 2019 Feb 04 08:50:42 pidown bluetit[8552]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.org, signature: RSA-SHA1 Feb 04 08:50:42 pidown bluetit[8552]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Atik/emailAddress=info@airvpn.org, signature: RSA-SHA512 Feb 04 08:50:42 pidown bluetit[8552]: SSL Handshake: peer certificate: CN=Atik, 4096 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD Feb 04 08:50:42 pidown bluetit[8552]: LZO-ASYM init swap=0 asym=1 Feb 04 08:50:42 pidown bluetit[8552]: Comp-stub init swap=0 Feb 04 08:58:28 pidown bluetit[8552]: Updating AirVPN Manifest Feb 04 08:58:40 pidown bluetit[8552]: AirVPN Manifest successfully retrieved from server Feb 04 09:09:00 pidown systemd[1]: bluetit.service: Main process exited, code=killed, status=6/ABRT Feb 04 09:09:00 pidown systemd[1]: bluetit.service: Failed with result 'signal'. Because Bluetit dies I have to run the --recover-network option before it will successfully reconnect. bluetit.rc is using all default values apart from username, password and airconnectonboot (which is set to quick). Bluetit Version Feb 4 09:44:34 pidown bluetit: Starting Bluetit - AirVPN OpenVPN 3 Service 1.0.0 - 7 January 2021 Feb 4 09:44:34 pidown bluetit: OpenVPN core 3.6.6 AirVPN linux arm 32-bit Other Info Raspberry Pi 4 Model B Rev 1.2 Linux version 5.4.83-v7l+ (dom@buildbot) (gcc version 8.4.0 (Ubuntu/Linaro 8.4.0-3ubuntu1)) #1379 SMP Mon Dec 14 13:11:54 GMT 2020 Happy to supply any other logs/info. D Quote Share this post Link to post
dL4l7dY6 3 Posted ... Just checking some more stuff. I see that the physical interface eth0 is set to Speed: 1000Mb/s but tun0 is set to Speed: 10Mb/s. D Quote Share this post Link to post
Staff 9972 Posted ... @dL4l7dY6 Hello! What is the operating system running in your Pi device? Kind regards Quote Share this post Link to post
dL4l7dY6 3 Posted ... 18 hours ago, Staff said: @dL4l7dY6 Hello! What is the operating system running in your Pi device? Kind regards pi@pidown:~ $ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=raspbian ID_LIKE=debian 32bit, Quote Share this post Link to post
frpergflf 8 Posted ... I installed AirVPN-Suite-x86_64-1.0.0.tar.gz on CentOS Stream using the install script and creating group airvpn. It installed fine, but I noticed a couple of things: 1. Dir /etc/airvpn was created as 660 - root:root I changed it to 750 - root:airvpn 2. /usr/local/bin/goldcrest was installed as 700 root:root I changed it to 750 - root:airvpn After I made the changes above no issues and all seems fine A couple of times, /etc/airvpn/bluetit.lock was not removed when I issued a 'sudo systemctl stop bluetit.service' but I was moving quickly trying to adjust permissions and config files after the install, so I cannot say for sure if it was me or not. I will keep an eye on that. Thanks for a nice work Quote Share this post Link to post
asdfasdfasdfasdfasdf 0 Posted ... Is there a Docker container for this software? Quote Share this post Link to post
Staff 9972 Posted ... @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 2 airvpnclient and frpergflf reacted to this Quote Share this post Link to post
frpergflf 8 Posted ... On 2/6/2021 at 5:13 AM, Staff said: @frpergflfThe 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 Hi, Today I started and stopped bluetit using systemctl to see if I can get the issue to occur. A couple of times it was unable to remove the lock file. Attached is the log you requested. I also executed 'sealert -l 38fc85ca-5938-44e9-b44b-03d4bcf794eb' output per the log and I attached that file also. Thanks bluetit-issue.txt selinux.txt Quote Share this post Link to post
Staff 9972 Posted ... @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 Quote Share this post Link to post
Staff 9972 Posted ... @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 1 frpergflf reacted to this Quote Share this post Link to post
grammarye 1 Posted ... Having set up the bluetit service to connect on boot, is there a recommended approach for After in systemd to launch a dependent service only once the VPN is connected? I tried After=sys-devices-virtual-net-tun0.device (and BindsTo) with less than stellar results. Thanks for the absolutely awesome tools! (and thank you for the Raspbian fixes, looking forward to that). Quote Share this post Link to post