Eddie reports SSL missing and other errors

[alphastep 0]

I use Manjaro XFCE as my OS, and I downloaded Eddie from airvpn.org (the version for Arch linux). Every time I start Eddie, I get several notifications that don't look normal to me. Here is copy/paste from the today's log:
 

Quote

. 2020.07.25 18:51:45 - Eddie version: 2.18.9 / linux_x64, System: Linux, Name: Manjaro Linux \r  (\n) (\l), Version: Linux majoran 5.6.19-2-MANJARO #1 SMP PREEMPT Wed Jun 17 22:24:52 UTC 2020 x86_64 GNU/Linux, Mono/.Net: 6.8.0 (makepkg/1d0d939dc30 Mon 29 Jun 2020 01:21:28 PM -03); Framework: v4.0.30319
. 2020.07.25 18:51:45 - Command line arguments (2): path.resources="/usr/share/eddie-ui" path.exec="/usr/bin/eddie-ui"
. 2020.07.25 18:51:45 - Raise system privileges
. 2020.07.25 18:51:51 - Profile path: /home/majoran/.config/eddie/default.profile
. 2020.07.25 18:51:51 - Reading options from /home/majoran/.config/eddie/default.profile
. 2020.07.25 18:51:52 - Tun Driver - /dev/net/tun
. 2020.07.25 18:51:52 - OpenVPN - Version: 2.4.9 - OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10 (/usr/bin/openvpn)
. 2020.07.25 18:51:52 - SSH - Version: OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020 (/usr/bin/ssh)
W 2020.07.25 18:51:52 - SSL - Not available
. 2020.07.25 18:51:52 - curl - Version: 7.71.1 (/usr/bin/curl)
. 2020.07.25 18:51:52 - Recovery. Unexpected crash?
W 2020.07.25 18:51:52 - Routes, add 64.42.179.59 for gateway 10.22.254.1 failed: Exception: Cannot find device "tun0"
W 2020.07.25 18:51:52 - Routes, add 2605:9f80:6000:80:fc8c:43ee:267e:97ab for gateway fde6:7a:7d20:12fe::1 failed: Exception: Cannot find device "tun0"
I 2020.07.25 18:51:53 - Ready
. 2020.07.25 18:51:54 - Collect information about AirVPN completed
! 2020.07.25 18:52:42 - Activation of Network Lock - Linux iptables
[/quote]

and then, when I connect to Hercules server, this is the rest of the log:
 

[OpenSourcerer 1435]

1 minute ago, alphastep said:

W 2020.07.25 18:51:52 - SSL - Not available

I see only this. Install stunnel to fix.

Rest of the log is missing, check your post.

[alphastep 0]

There's something wrong with this forum editor, so the rest of my message (although it's completely fine) is missing and I can't add anything new to the first message when I try to edit it.

so here is the rest of the log:
 

I 2020.07.25 18:53:34 - Session starting.
I 2020.07.25 18:53:34 - Checking authorization ...
! 2020.07.25 18:53:35 - Connecting to Hercules (United States of America, Atlanta, Georgia)
. 2020.07.25 18:53:35 - OpenVPN > OpenVPN 2.4.9 [git:makepkg/9b0dafca6c50b8bb+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 20 2020
. 2020.07.25 18:53:35 - OpenVPN > library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10
. 2020.07.25 18:53:35 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
. 2020.07.25 18:53:35 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
. 2020.07.25 18:53:35 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
. 2020.07.25 18:53:35 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
. 2020.07.25 18:53:35 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]64.42.179.61:443
. 2020.07.25 18:53:35 - OpenVPN > Socket Buffers: R=[212992->212992] S=[212992->212992]
. 2020.07.25 18:53:35 - OpenVPN > UDP link local: (not bound)
. 2020.07.25 18:53:35 - OpenVPN > UDP link remote: [AF_INET]64.42.179.61:443
. 2020.07.25 18:53:36 - OpenVPN > TLS: Initial packet from [AF_INET]64.42.179.61:443, sid=d429985f 1431e03f
. 2020.07.25 18:53:36 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2020.07.25 18:53:36 - OpenVPN > VERIFY KU OK
. 2020.07.25 18:53:36 - OpenVPN > Validating certificate extended key usage
. 2020.07.25 18:53:36 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2020.07.25 18:53:36 - OpenVPN > VERIFY EKU OK
. 2020.07.25 18:53:36 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Hercules, emailAddress=info@airvpn.org
. 2020.07.25 18:53:36 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
. 2020.07.25 18:53:36 - OpenVPN > [Hercules] Peer Connection Initiated with [AF_INET]64.42.179.61:443
. 2020.07.25 18:53:38 - OpenVPN > SENT CONTROL [Hercules]: 'PUSH_REQUEST' (status=1)
. 2020.07.25 18:53:38 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.22.238.1,dhcp-option DNS6 fde6:7a:7d20:12ee::1,tun-ipv6,route-gateway 10.22.238.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:12ee::1089/64 fde6:7a:7d20:12ee::1,ifconfig 10.22.238.139 255.255.255.0,peer-id 0,cipher AES-256-GCM'
. 2020.07.25 18:53:38 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp'
. 2020.07.25 18:53:38 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2020.07.25 18:53:38 - OpenVPN > OPTIONS IMPORT: compression parms modified
. 2020.07.25 18:53:38 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2020.07.25 18:53:38 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2020.07.25 18:53:38 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2020.07.25 18:53:38 - OpenVPN > OPTIONS IMPORT: peer-id set
. 2020.07.25 18:53:38 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625
. 2020.07.25 18:53:38 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified
. 2020.07.25 18:53:38 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM'
. 2020.07.25 18:53:38 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2020.07.25 18:53:38 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2020.07.25 18:53:38 - OpenVPN > ROUTE_GATEWAY 192.168.8.1/255.255.255.0 IFACE=wlp8s0 HWADDR=9c:2a:70:ce:90:eb
. 2020.07.25 18:53:38 - OpenVPN > GDG6: remote_host_ipv6=n/a
. 2020.07.25 18:53:38 - OpenVPN > ROUTE6: default_gateway=UNDEF
. 2020.07.25 18:53:38 - OpenVPN > TUN/TAP device tun0 opened
. 2020.07.25 18:53:38 - OpenVPN > TUN/TAP TX queue length set to 100
. 2020.07.25 18:53:38 - OpenVPN > /usr/bin/ip link set dev tun0 up mtu 1500
. 2020.07.25 18:53:38 - OpenVPN > /usr/bin/ip addr add dev tun0 10.22.238.139/24 broadcast 10.22.238.255
. 2020.07.25 18:53:38 - OpenVPN > /usr/bin/ip -6 addr add fde6:7a:7d20:12ee::1089/64 dev tun0
. 2020.07.25 18:53:43 - OpenVPN > /usr/bin/ip route add 64.42.179.61/32 via 192.168.8.1
. 2020.07.25 18:53:43 - OpenVPN > /usr/bin/ip route add 0.0.0.0/1 via 10.22.238.1
. 2020.07.25 18:53:43 - OpenVPN > /usr/bin/ip route add 128.0.0.0/1 via 10.22.238.1
. 2020.07.25 18:53:43 - OpenVPN > add_route_ipv6(::/3 -> fde6:7a:7d20:12ee::1 metric -1) dev tun0
. 2020.07.25 18:53:43 - OpenVPN > /usr/bin/ip -6 route add ::/3 dev tun0
. 2020.07.25 18:53:43 - OpenVPN > add_route_ipv6(2000::/4 -> fde6:7a:7d20:12ee::1 metric -1) dev tun0
. 2020.07.25 18:53:43 - OpenVPN > /usr/bin/ip -6 route add 2000::/4 dev tun0
. 2020.07.25 18:53:43 - OpenVPN > add_route_ipv6(3000::/4 -> fde6:7a:7d20:12ee::1 metric -1) dev tun0
. 2020.07.25 18:53:43 - OpenVPN > /usr/bin/ip -6 route add 3000::/4 dev tun0
. 2020.07.25 18:53:43 - OpenVPN > add_route_ipv6(fc00::/7 -> fde6:7a:7d20:12ee::1 metric -1) dev tun0
. 2020.07.25 18:53:43 - OpenVPN > /usr/bin/ip -6 route add fc00::/7 dev tun0
. 2020.07.25 18:53:43 - DNS of the system updated to VPN DNS (Rename method: /etc/resolv.conf generated)
. 2020.07.25 18:53:43 - Routes, added a new route, 64.42.179.59 for gateway 10.22.238.1
. 2020.07.25 18:53:43 - Routes, added a new route, 2605:9f80:6000:80:fc8c:43ee:267e:97ab for gateway fde6:7a:7d20:12ee::1
. 2020.07.25 18:53:43 - Flushing DNS
. 2020.07.25 18:53:43 - Flush DNS - nscd
I 2020.07.25 18:53:43 - Checking route IPv4
I 2020.07.25 18:53:44 - Checking route IPv6
I 2020.07.25 18:53:46 - Checking DNS
! 2020.07.25 18:53:47 - Connected.
. 2020.07.25 18:53:47 - OpenVPN > Initialization Sequence Completed

The connection to Hercules seems to be working fine, but I want to be sure that SSL is on, i.e. that my connection is encrypted.
Having a strong encryption is crucial, and that's one of the primary reasons I use VPN in the first place. Could somebody help me with this please?

[alphastep 0]

20 minutes ago, giganerd said:

I see only this. Install stunnel to fix.

Rest of the log is missing, check your post.

I installed stunnel using Pamac and now when Eddie is started those error messages don't appear anymore. It seems that that fixed the issue, thanks!

But I am still concerned whether my connection was SSL encrypted until now? I've been using this setup (Manjaro and Eddie) for quite a long time now. It would be bad if my connection wasn't encrypted thus far.

[Staff 9972]

@alphastep

Hello!

AirVPN allows only OpenVPN encrypted connections. You can see that here for example (respectively for Control and Data channels):

. 2020.07.25 18:53:36 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA

. 2020.07.25 18:53:38 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2020.07.25 18:53:38 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

If you don't have stunnel you can't add an additional TLS tunnel (which might be useful only in very exceptional circumstances) on top of OpenVPN connection, nothing else.  It has nothing to do with OpenVPN encryption.

Kind regards
 

[OpenSourcerer 1435]

What Staff wrote.

Your connection is ready to be used. Enjoy!

[alphastep 0]

On 7/25/2020 at 9:57 PM, giganerd said:

What Staff wrote.

Your connection is ready to be used. Enjoy!

Thank you and thanks to Staff. The SSL issue has been resolved.

However, there are two more potentially problematic things that I'd like to ask about. One just happened for the first time this morning when I started Eddie (it didn't happen before). Eddie displayed a large window on top of which I could read something like "Unexpected error... contact your administrator..." and then a lot of data, numbers etc. I wanted to copy/paste it from the log, but Eddie had already closed down (the error message was all that was left). When I restarted Eddie, this error didn't occur again, but I couldn't find that error anywhere in the logs.

The second strange thing is that ever since I installed this latest Manjaro XFCE and Eddie on it, Eddie would ask me first for the admin password (in 100% of cases), and then in just about 20% of cases it would also ask me for the password for my keyring. This keyring password was set up when I started Eddie for the first time on this installation. On my previous Manjaro installation, I used some Eddie from their AUR repository and that Eddie never asked me for the keyring pass (although some other programs did, such as Chromium, Opera etc.).

But the strange thing with this new setup is that Eddie asks me for this keyring password only sometimes, not always as one would expect. How is that possible? When it doesn't ask me for the keyring pass, no other program will ask me this keyring pass either, and everything seems to be working normally. Eddie and other programs work seemingly fine even if they don't ask for this keyring pass.

Does anyone have any idea about how to find out what's happening with this?

 

[OpenSourcerer 1435]

12 minutes ago, alphastep said:

But the strange thing with this new setup is that Eddie asks me for this keyring password only sometimes, not always as one would expect. How is that possible? When it doesn't ask me for the keyring pass, no other program will ask me this keyring pass either, and everything seems to be working normally. Eddie and other programs work seemingly fine even if they don't ask for this keyring pass.

Could be because in Eddie Preferences > General, Profile data protection is set to Linux secret-tool. If you use KDE, kdewallet might be asked to save profile data then and this can be viewed with KWalletManager. Once you unlock the wallet, it will stay unlocked for some time, so maybe that's why.
I might be an idiot because you wrote you were on XFCE Though the GNOME Keyring serves the same purpose.
 

12 minutes ago, alphastep said:

However, there are two more potentially problematic things that I'd like to ask about. One just happened for the first time this morning when I started Eddie (it didn't happen before). Eddie displayed a large window on top of which I could read something like "Unexpected error... contact your administrator..." and then a lot of data, numbers etc. I wanted to copy/paste it from the log, but Eddie had already closed down (the error message was all that was left). When I restarted Eddie, this error didn't occur again, but I couldn't find that error anywhere in the logs.

Seems like a temporary error. If it does so again, write it again. Edited ... by giganerd

[alphastep 0]

10 minutes ago, giganerd said:

Could be because in Eddie Preferences > General, Profile data protection is set to Linux secret-tool. If you use KDE, kdewallet might be asked to save profile data then and this can be viewed with KWalletManager. Once you unlock the wallet, it will stay unlocked for some time, so maybe that's why.
I might be an idiot because you wrote you were on XFCE Though the GNOME Keyring serves the same purpose.
 
 

I only know that my Manjaro is officially XFCE, not sure about KDE. I am relatively new to linux in general, so please bear with me.
I just went into Eddie's preferences, and under General the option "Linux secret-tool (no password asked)" is selected.
If I select the option "Password", a message pops up saying "Password is empty or doesn't match". There is also the 3rd option "Plain (no password asked)".

So, which one of these three should I choose?  I don't think I have KWalletManager installed here.
 

[OpenSourcerer 1435]

11 minutes ago, alphastep said:

So, which one of these three should I choose?  I don't think I have KWalletManager installed here.

Nono, it's KDE-specific. Another desktop environment entirely, looks and feels more Windows-ey.

secret-tool is probably good enough, you should keep it and enter the Keyring password every time to unlock it. Built-in feature of your desktop, something Windows doesn't have. Biggest advantage is that all content of the keyring is encrypted by itself, and if you so desire, with your own PGP key, but that's more advanced.
Password simply encrypts the profile file with… I'm actually not sure with what exactly. The password logically decrypts it.
Plain is, well, plain. Unencrypted. Most compatible, but least secure.

[alphastep 0]

6 minutes ago, giganerd said:

Nono, it's KDE-specific. Another desktop environment entirely, looks and feels more Windows-ey.

secret-tool is probably good enough, you should keep it and enter the Keyring password every time to unlock it. Built-in feature of your desktop, something Windows doesn't have. Biggest advantage is that all content of the keyring is encrypted by itself, and if you so desire, with your own PGP key, but that's more advanced.
Password simply encrypts the profile file with… I'm actually not sure with what exactly. The password logically decrypts it.
Plain is, well, plain. Unencrypted. Most compatible, but least secure.

The problem is, if I leave that setting at "secret-tool", Eddie will continue to work, but will ask for the keyring password only occasionally. I am not in the position to "enter it every time to unlock it", because I'm not asked for it every time I start Eddie. I think I installed this Manjaro about 3 weeks ago, and Eddie has asked me for the keyring password only about 7 or 8 times (I turn on my laptop at least once a day). So, although I don't have any visible issues with Eddie's performance, the fact that I am asked for the keyring password only from time to time doesn't look quite normal to me. 

This Manjaro behaves differently when it comes to keyring in general. In my previous Manjaro installation it was Chromium that always asked me for the keyring pass. Now with this new installation, when Eddie doesn't ask me for the keyring pass, no other program asks for it either, but everything seems to continue to work normally nevertheless. Weird, isn't it?
 

[OpenSourcerer 1435]

2 hours ago, alphastep said:

The problem is, if I leave that setting at "secret-tool", Eddie will continue to work, but will ask for the keyring password only occasionally. I am not in the position to "enter it every time to unlock it", because I'm not asked for it every time I start Eddie. I think I installed this Manjaro about 3 weeks ago, and Eddie has asked me for the keyring password only about 7 or 8 times (I turn on my laptop at least once a day). So, although I don't have any visible issues with Eddie's performance, the fact that I am asked for the keyring password only from time to time doesn't look quite normal to me. 

It's normal. You should take a look at the secret-tool settings. I believe you can set how often you would like to ask for authentication, maybe even per-application, at least it's the case with KWalletManager.
 

2 hours ago, alphastep said:

This Manjaro behaves differently when it comes to keyring in general. In my previous Manjaro installation it was Chromium that always asked me for the keyring pass. Now with this new installation, when Eddie doesn't ask me for the keyring pass, no other program asks for it either, but everything seems to continue to work normally nevertheless. Weird, isn't it?

Nope, just a different default setting, I guess. And yes, Chromium is one of the few applications really using secret-tool and kdewallet to its fullest. Chromium always saves its sensitive data there. And it's kinda cool; that is, if you take the time to configure these applications to make them more secure than simply typing in your login password to unlock.

[alphastep 0]

21 hours ago, giganerd said:

It's normal. You should take a look at the secret-tool settings. I believe you can set how often you would like to ask for authentication, maybe even per-application, at least it's the case with KWalletManager.
 
Nope, just a different default setting, I guess. And yes, Chromium is one of the few applications really using secret-tool and kdewallet to its fullest. Chromium always saves its sensitive data there. And it's kinda cool; that is, if you take the time to configure these applications to make them more secure than simply typing in your login password to unlock.

Thanks for the explanation. I won't worry about that anymore, then.

Since I installed stunnel, Eddie didn't display any error notifications upon starting it. This lasted for a couple of days, and today again I was greeted with two notifications about Eddie being unable to find "tun0" device. Stunnel is still installed. Here is the log from today:

 

. 2020.07.28 16:24:36 - Eddie version: 2.18.9 / linux_x64, System: Linux, Name: Manjaro Linux \r  (\n) (\l), Version: Linux majoran 5.6.19-2-MANJARO #1 SMP PREEMPT Wed Jun 17 22:24:52 UTC 2020 x86_64 GNU/Linux, Mono/.Net: 6.8.0 (makepkg/1d0d939dc30 Mon 29 Jun 2020 01:21:28 PM -03); Framework: v4.0.30319
. 2020.07.28 16:24:36 - Command line arguments (2): path.resources="/usr/share/eddie-ui" path.exec="/usr/bin/eddie-ui"
. 2020.07.28 16:24:36 - Raise system privileges
. 2020.07.28 16:24:42 - Profile path: /home/majoran/.config/eddie/default.profile
. 2020.07.28 16:24:43 - Reading options from /home/majoran/.config/eddie/default.profile
. 2020.07.28 16:24:44 - Tun Driver - /dev/net/tun
. 2020.07.28 16:24:44 - OpenVPN - Version: 2.4.9 - OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10 (/usr/bin/openvpn)
. 2020.07.28 16:24:44 - SSH - Version: OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020 (/usr/bin/ssh)
. 2020.07.28 16:24:44 - SSL - Version: stunnel 5.56 (/usr/bin/stunnel)
. 2020.07.28 16:24:44 - curl - Version: 7.71.1 (/usr/bin/curl)
. 2020.07.28 16:24:44 - DNS of the system restored to original settings (Rename method)
. 2020.07.28 16:24:44 - Recovery. Unexpected crash?
W 2020.07.28 16:24:44 - Routes, add 82.102.27.195 for gateway 10.12.42.1 failed: Exception: Cannot find device "tun0"
W 2020.07.28 16:24:44 - Routes, add 2001:ac8:38:21:2473:6fcc:942d:eb92 for gateway fde6:7a:7d20:82a::1 failed: Exception: Cannot find device "tun0"
. 2020.07.28 16:24:44 - Routes, removed an existing route, 82.102.27.195 for gateway 10.12.38.1
. 2020.07.28 16:24:44 - Routes, removed an existing route, 2001:ac8:38:21:2473:6fcc:942d:eb92 for gateway fde6:7a:7d20:826::1
! 2020.07.28 16:24:44 - Deactivation of Network Lock
I 2020.07.28 16:24:45 - Ready
. 2020.07.28 16:24:46 - Collect information about AirVPN completed

Is this tun0 error normal, and if it isn't, can it be fixed?
 

[OpenSourcerer 1435]

5 hours ago, alphastep said:

. 2020.07.28 16:24:44 - Recovery. Unexpected crash?

I'd ask how you usually quit Eddie. It seems to "think" it crashed, so it tries to access the previously used interface tun0 to try restoring NetLock, it seems. But there is none anymore, so this error is thrown and NetLock disabled.

[alphastep 0]

59 minutes ago, giganerd said:

I'd ask how you usually quit Eddie. It seems to "think" it crashed, so it tries to access the previously used interface tun0 to try restoring NetLock, it seems. But there is none anymore, so this error is thrown and NetLock disabled.

Well, I usually don't exit (close) Eddie by selecting the Exit option from its menu. I just press the shut down button in Manjaro and I suppose it closes Eddie down before shutting the OS. Yeah, that would probably explain the "Recovery: Unexpected crash?" message. But what shall we make out of:

W 2020.07.28 16:24:44 - Routes, add 82.102.27.195 for gateway 10.12.42.1 failed: Exception: Cannot find device "tun0"
W 2020.07.28 16:24:44 - Routes, add 2001:ac8:38:21:2473:6fcc:942d:eb92 for gateway fde6:7a:7d20:82a::1 failed: Exception: Cannot find device "tun0"

What is tun0 anyway?

 

[OpenSourcerer 1435]

16 hours ago, alphastep said:

I just press the shut down button in Manjaro and I suppose it closes Eddie down before shutting the OS.

Eddie doesn't report a "clean" exit unless you confirm the exit dialog. If you want the errors to disappear, consider closing it gracefully now, as intended.

Bit of background: AFAIK, on shutdown systemd will first try to SIGTERM all processes (SIGnal to TERMinate, similar to closing a program by clicking X), and if it fails somewhere, those will be "murdered" after some time instead, meaning SIGKILLed. SIGKILL cannot be caught and processed by any program (while SIGTERM can), it's how it's designed in the kernel. Form a program's point of view it's like "the PC lost power while I was running" if it was SIGKILLed.
I can imagine this SIGKILL is what happens, since Eddie processes SIGTERM by showing the dialog to the user for him/her to confirm exiting. But the desktop is already down, so we find ourselves in a deadlock. Eddie blocks exiting itself and the user can't confirm the exit, until systemd hammers its fist on the table and murders the process. When you relaunch Eddie, it notices a previous unclean exit and tries to recover, notifying the user by writing that log line.
 

16 hours ago, alphastep said:

What is tun0 anyway?

A virtual network interface, provided by the tunnel kernel driver named "tun" and used by OpenVPN and other software where such a tunnel interface is needed. Adheres to the network interface naming scheme of older kernel versions: typeX, where type can be for example eth for ethernet, wlan for wireless, rmnet for GSM and many more, and X is a number starting with 0, incremented for every detected interface of the same type, so if you've got two ethernet ports, they'd be named eth0 and eth1.
OpenVPN, by using tun, basically emulates certain features of a network interface, but it can't do so directly on your physical card because its network is needed to "build the tunnel on" so to speak. So you create a virtual interface and configure that, then tell the system to route certain networks, or even all of it, over such a tun interface.