Wireguard difficulties [SOLVED]

Run ‘connmanctl services’ to see the services recognized by connman. If a vpn service is missing, it means that there is a .config file that is not configured correctly or is non-existent in the /storage/.config/wireguard directory.

Sigh. What this Thread showed me is that the current wg implementation is not acceptable. I will try to find some time to clean it up. We need to do it like common linux distros do it. I honestly never tried it in CE and it seems devastating.

connmanctl can only be called after network is up and running and autostart service can run before if wait for network service is not used. That’s why autostart.sh is not recommended if you need reliable services.

…the 20 second timeout is to make sure the network is enabled, this may not be professional, neither am I, and for me this has been working great for years :rofl:

1 Like

Whatever works for you. Not judging. Whatever works.

I repeat again, I am not a computer professional just a hobbyist retired who graduated in engineering (= things are good if they work good) 46 years ago :wink: when mathematical operations were done with a slide rule.

Never doubted you. Sorry if that came out wrong.

Well @cubimol, the 20s sleep did it and now the VPN is up and running at boot time but I don’t think Kodi takes the remote database into account. I have to enter Movies twice on the welcome screen to see the remote database populating the list. So, my question is when is Kodi started, is it after autostart.sh or at the same time? How can I make sure Kodi starts after autostart.sh?
Yes, there must be a more simple, straightforward way to do these things, like it is done on Ubuntu. Unfortunately I will be of little help to make that happen, sorry. But I’m learning stuff along the way and that is always a bonus.

With remote devices I don’t have to do anything, each device manages its database and each device is responsible for updating this database.

The answer to your question is that Kodi starts immediately because autostart.sh terminates immediately because the commands are enclosed in parentheses followed by the ‘&’ symbol (= continues without waiting for the completion of the commands). At the same time that Kodi starts up, the commands in parentheses continue to execute.

If you use a single remote database for all devices, the only solution I can think of is to run the command systemctl restart kodi after the last command in autostart.sh, this will result in the screen turning off for a few seconds. In this case try to adjust the initial waiting seconds more precisely.

My case is different, the reboot time is around seven o’clock in the morning, the TV is off and nobody is using CE, the remote devices must be turned on because they also execute server tasks (continuous recording of surveillance camera in the LE server and TV channel forwarding). These devices have the shutdown command locked so that I can remotely monitor them at any time.

The LE/CE wireguard connman implementation is pretty messy imho

It’s not too difficult to DIY though, basically doing the same thing as wg-quick, and without having to resort to using Docker

I use my CE box as a relay/server/vpn to my home network. There may be some additional config required for port forwarding and ddns and IPv6, but the same approach can be used if you are using it as a remote peer/client.

systemd service:

# systemctl enable /storage/.config/wireguard/wireguard.service

Description=WireGuard VPN Service
After=network-online.target nss-lookup.target time-sync.target
Wants=network-online.target nss-lookup.target time-sync.target

ExecStart=sh /storage/.config/wireguard/start_wireguard.sh
ExecStop=sh /storage/.config/wireguard/stop_wireguard.sh


startup script:


IN_FACE="eth0"                   # NIC connected to the internet
WG_CONF="/storage/.config/wireguard/server.conf"    # Location of wg conf file
WG_FACE="wg0"                    # WG NIC
SUB_NET=""         # WG IPv4 sub/net aka CIDR
WG_PORT="51820"                  # WG udp port

ip link add dev $WG_FACE type wireguard
ip address add dev $WG_FACE $SUB_NET
wg setconf $WG_FACE $WG_CONF
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -I POSTROUTING 1 -s $SUB_NET -o $IN_FACE -j MASQUERADE
iptables -I INPUT 1 -i $WG_FACE -j ACCEPT
iptables -I FORWARD 1 -i $IN_FACE -o $WG_FACE -j ACCEPT
iptables -I FORWARD 1 -i $WG_FACE -o $IN_FACE -j ACCEPT
iptables -I INPUT 1 -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT
ip link set up dev $WG_FACE

shutdown script:


IN_FACE="eth0"                   # NIC connected to the internet
WG_FACE="wg0"                    # WG NIC
SUB_NET=""         # WG IPv4 sub/net aka CIDR
WG_PORT="51820"                  # WG udp port

sysctl -w net.ipv4.ip_forward=0
iptables -t nat -D POSTROUTING -s $SUB_NET -o $IN_FACE -j MASQUERADE
iptables -D INPUT -i $WG_FACE -j ACCEPT
iptables -D FORWARD -i $IN_FACE -o $WG_FACE -j ACCEPT
iptables -D FORWARD -i $WG_FACE -o $IN_FACE -j ACCEPT
iptables -D INPUT -i $IN_FACE -p udp --dport $WG_PORT -j ACCEPT
ip link delete dev $WG_FACE

remote peer config:

Address =
PrivateKey = <wg_peer_private_key>

Endpoint = <wg_server_ip:port>
PublicKey = <wg_server_public_key>
PresharedKey = <wg_preshared_key>
AllowedIPs =, ::/0,

server (CE) config:

ListenPort = <wg_server_port>
PrivateKey = <wg_server_private_key>

AllowedIPs =
PublicKey = <wg_peer_public_key>
PresharedKey = <wg_preshared_key>

There is a systemd service sample included btw in CoreELEC:

It is worth a shot editing: /storage/.config/system.d/wireguard.service.sample

Wow, thx to all for your help. Will read carefully but I can already mark my problem as solved, whichever way I decide to go, autostart.sh or systemd service. Again thanks a bunch, and keep up the amazing work you devs

I was able to get your solution working in one direction forcing routes to interface wg0, from client to server and not the other way around (*), but with modifications to the config file and your startup script. Thanks to zerotier I have not lost control of my remote test-client. In the end I have returned to leave wireguard using connman.

The general problem seems to be in the initial bad implementation of wireguard where the ‘wg’ command requires configuration files which have been abandoned with the appearance of the ‘wg-quick’ script-command. This command has CE/LE compatibility issues where the ‘resolveconf’ and ‘iptables-restore’ dependencies are not well implemented. So CE/LE has chosen to use ‘connman’, which itself requires different configuration files and does not support DDNS. A disaster! although using IP addresses works fine even with clients behind a CG-NAT.

The solution could be to solve the compatibility problems of ‘wg-quick’ with CE/LE but this work is beyond my abilities.

(*) My server has a dynamic IP and is accessible from the internet, but almost all my clients are behind a CG-NAT and are not accessible from the internet.

We will abandon this ridiculous implementation and use wq-quick. It will require more changes cause we have to do something that is already overdue and that is adding a full Bash shell into CE. It will take a little bit of time and testing and we might not get it before the next RC release but all in all this thread was very helpful to show me that the connman implementation that we inherited is just poo.


Hmm… I wouldn’t have thought that would be an issue. Once the wireguard connection is established it should work both ways. Bear in mind that if the “client” is running CE you will also need to apply similar iptables rules as found in the “server” startup script, otherwise it will just drop any incoming connections depending on what firewall rules have been used.

Regardless getting it to work is not as easy as it should be. Unfortunately with the workarounds required for the connman implementation not working out of the box with ddns, and also messing up routes, doing it manually was a more robust option for my use case.


Sorry to have bothered you with my problems but in the end it’s gonna be for the best I guess. Maybe I will have a go at the sample wireguard service file and see if it’s usable. Again, thanks for your patience and, overall, for your dedication.

You didn’t bother me at all. I jumped into the thread and I recently only do it if there’s an interesting problem. So thank you.


Got a little time to tinker with the wireguard.service.sample file in /storage/.config/system.d and the service runs as expected, yay!
I renamed the file wireguard.service and edited it like so:

Description=WireGuard VPN Service
After=network-online.target nss-lookup.target connman-vpn.service time-sync.target
Wants=network-online.target nss-lookup.target connman-vpn.service time-sync.target

ExecStart=/usr/bin/connmanctl connect vpn_<Public_IP_of_WG_server>
ExecStop=/usr/bin/connmanctl disconnect vpn_<Public_IP_of_WG_server>


Then I enabled the service:

systemctl enable wireguard.service

Finally I removed the VPN entry in autostart.sh. The pre-requisite is to have a correct /storage/.config/wireguard/wireguard.config
That way the service is indeed started at boot time and Kodi is aware of the remote database.

1 Like

You could also add


I certainly will, just to make sure Kodi starts last. Thx @vpeter

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.