WireGuard - Experimental support for connecting via FQDN not IP

    Regular ConnMan contributor and SailfishOS maintainer Jussi Laakonen has been working on improvements to WireGuard support in ConnMan. Specifically, the ability to define 'Host' (the remote WireGuard server) as a hostname/FQDN instead of an IP address. This eases long-term WireGuard use with servers self-hosted from dynamic IP address ranges, and commercial WireGuard services where each node has multiple IP addresses in DNS that are rotated reguarly to avoid IP blocking. The changes should also perform periodic re-resolving of the connection hostname to ensure connectivity is maintained when an IP changes. However, I can't test that as my own WireGuard server is on a static address, so we'd like to crowdsource some further testing :)

    The following image for RPi5 contains the changes:

    RPi5: https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.0.tar

    To test, update to the test image then edit your WireGuard .config file to define 'Host' with a hostname/FQDN then reboot. On reboot check the WireGuard connection is up and that traffic is routed down the tunnel by running curl icanhazip.com .. it should return the WAN address of the remote side.

    For reference, Jussi's changes can be seen here: https://github.com/LaakkonenJussi…pn_association/ and I've build the LE image with this change: https://github.com/chewitt/LibreE…0a2da07a27919da.

    EDIT, the RPi5 image in my test share will be updated as other changes/refinements are made to Jussi's codebase upstream. You will need to check commits in https://github.com/chewitt/LibreELEC.tv/commits/rpi-13.0 for latest githash/changes to build with LE.

    heya! this sounds great, and something i need, since i only have a server without a static IP, but i also don't have a pi5 - only a pi4. i haven't had time yet, but i guess there's only minor differences between the pi4 and pi5 images? i will try to copy the fat partition configs/dtbs from the stable pi4 image to the one you posted. and let you know how it works.
    i assume as well that connman generates a stable service name from an FQDN peer, rather than the current config name which encodes the peer's static IP?
    also i assume that i will still need some sort of a script to periodically restart the connection in order to continue to stay connected when my peer's IP cycles?
    thank you!

    i had some more time today to look into this again and it seems (tentatively) working nicely with an FQDN wireguard server!

    of course what i suggested didn't work since there seems to be quite a big difference between the pi4 and pi5 images, even in their overlay FS, which is a bit surprising. i haven't used a filesystem like libreelec before so that was some fun exploring, same with debugging afterwards.
    so i instead built an image with the deleted connman patch from your commit and the latest commit from that connman upstream branch (464e464e2e24692ce02f21d0ddf5d95768d5edcc).
    this was a painful process for me (read: wasted hours) as i am using podman instead of docker (and building on macos), and i could not figure out how to get the volume mounts working in podman. i even tried on my linux box (which is less powerful - so i wanted to do it on my macbook), and also couldn't get the mounts working in podman or docker on debian. eventually i just gave up and bit the bullet and worked from within the container interactively, and then at the end rsynced the image out of the container, ha. it built relatively quickly though - just shy of 30mins - with 12 cores and 32GB ram assigned to the podman virtual machine, on an M4 pro.

    the connman service name is friendly (something like vpn_subdomain_domain_tld) so it's easy to continue with the documented systemd unit approach in the wiki docs.

    i will have to run it longer to check if the periodic re-resolving of the IP works, since i cannot predict when my dynamic ip will change.

    i noticed that on the version of connmanctl i'm using, when i enter interactive mode i don't get any echo - so typing blind there. i'm not sure if that's a known bug, and i currently don't have a second stable libreelec deployment to it compare to, unfortunately.

    but thanks for pointing me towards this, it was fun! and without this new feature i would have had to use debian (or whatever) + kodi instead.
    if there's anything in particular that i should test LMK, i guess that this has to wait on that connman branch from upstream being released first, anyway?


    yup wireguard is like a nice simple alternative to openvpn. it's lighter and better integrated into linux (generally). it's really fast at connecting and creates very little overhead, so you generally get great speeds with it. give it a go, it's fun! (unlike openvpn)

    i am actually having some stability issues with my build - the vpn just fails at some point and i can't see any insightful error messages in the connman journald, so i've now started the service running with:

    Code
    # cat /run/libreelec/debug/connman.conf
CONNMAN_DEBUG='-d'

    since the connman.service defines:

    Bash
    EnvironmentFile=-/run/libreelec/debug/connman.conf
ExecStart=/bin/sh -c ". /usr/lib/connman/connman-setup; exec /usr/sbin/connmand -nr $CONNMAN_MAIN $CONNMAN_DEBUG"

    i also noticed that there's a connman-vpnd job though, so i'm not sure if that's the daemon i should be turning on debug output for, but after a quick search i couldn't find anything about debugging the deamon, and also i don't know how i can override the connman-vpn.service file when it's read only? is there a way around that?

    I've used OpenVPN for over a decade and never had any issues other than a hefty speed decrease. Not so much of an issue now with 300mbps but at slower starting connections a real issue. Very interested in giving it go on one of my builds. I've several LE builds of different flavor hardware and maybe the RPi5 might be a good starting platform.