Posts by Doemela

  • WireGuard VPN Manager

    📢 Important Developer Update: LibreELEC 12 vs. LibreELEC 13 (LE13)

    Hi everyone,

    The current release of the WireGuard VPN Manager Add-on is fully optimized for LibreELEC 12 and is working perfectly.

    Behind the scenes, I am already preparing the backend code for LibreELEC 13. LE13 brings a massive system change: LibreELEC is permanently replacing the old network engine (ConnMan) with the industry-standard NetworkManager.

    This change has a direct impact on our add-on. Here is a quick overview of what this means for us:

    🟢 The Advantages (Why LE13 is great news)

    • Rock-Solid Routing: No more random VPN disconnects when your router refreshes its DHCP lease. NetworkManager handles traffic routing intelligently in the background.
    • Stable Handshakes: The add-on will no longer crash due to system-level proxy or WPA Wi-Fi re-keying bugs.
    • Cleaner Backend Code: NetworkManager natively understands WireGuard. This allows me to remove messy "ip route" and terminal hacks from the Python code, making the add-on much faster and lighter.

    🔴 The Disadvantages & Impact

    • Potential Breaking Change: As LibreELEC shifts its network architecture toward NetworkManager in LE13, the current ConnMan-based routing functions of the add-on may break or become unstable on newer test builds until updated.
    • Backend Transition: I am proactively preparing a code migration to ensure the core functions can seamlessly talk to NetworkManager (nmcli) alongside the existing ConnMan (connmanctl) implementation.

    📅 What is the plan?
    Enjoy the current release on LE12 for now—it works great. I will take care of the heavy lifting for LE13 in the coming period so we can transition smoothly without losing any of our advanced features.

    Stay tuned for the first LE13 test builds!

  • WireGuard VPN Manager

    Quote from Fabbz

    What you describe is not the case, I even flushed the main routing table and rebooted. Everything in the logs is fine.

    This must be something else.

    You can do:

    Shell session
    grep -Ei "error|warning" /storage/.kodi/temp/kodi.log | pastebinit
    Shell session
    journalctl -b 0 --no-pager | grep -iE "timeout|fail|network|waiting" | head -n 50 | pastebinit
    Shell session
    systemd-analyze; systemd-analyze blame | head -n 25 | pastebinit
    Shell session
    journalctl -p err..alert | pastebinit
    Shell session
    (journalctl -u vpn-watchdog.service; grep -i "service.wireguard.manager" /storage/.kodi/temp/kodi.log) | pastebinit
    Shell session
    (echo "=== CONNMAN SERVICES ==="; connmanctl services; echo "=== CONNMAN STATE ==="; connmanctl state) | pastebinit
    Shell session
    journalctl -u connman | pastebinit

  • WireGuard VPN Manager

    Quote from Fabbz

    Hi,

    Thank for the update; I tried what you said but it didn't fix the route.

    Any other suggestions to check ?

    If the split routing did not override the table, ConnMan is likely aggressively caching your old network state under a temporary session. To see exactly what is going on under the hood, please run these two commands in your terminal while the VPN is active and paste the output back here:

    Shell session
    route
connmanctl services

    Without seeing your active routing table flags, it is impossible to see which interface is currently trapping your traffic. Paste those logs, and we will try to get it sorted.

    Code
    grep -i "service.wireguard.manager" /storage/.kodi/temp/kodi.log | pastebinit

    What happens: It pushes the filtered data straight to LibreELEC's default pastebin server and prints a clean link right inside your terminal window. Please share that link directly in this thread. Do not post full raw logs here!

  • WireGuard VPN Manager

    I looked into your routing table, and your analysis is 100% correct. The problem is a known ConnMan DNS routing conflict. Look at this specific line in your VPN routing table:

    Code
    10.2.0.1        192.168.101.254 255.255.255.255 UGH   0      0        0 wlan0

    Because you declared WireGuard.DNS = 10.2.0.1 inside your config file, ConnMan mistakenly generated a hardcoded Host route (UGH) that traps your DNS traffic. Instead of sending DNS requests inside the secure wg0 tunnel, it is forcing them out over your Wi-Fi card (wlan0) to your local router (192.168.101.254). Your local router has no idea what 10.2.0.1 is, so it drops the packets. This is why you can ping public IPs like 8.8.8.8 perfectly (via the VPN), but your DNS lookup times out, making your traceroute and reverse-DNS lookups extremely slow.

    Force the internal DNS into the tunnel you need to force the Linux kernel to override ConnMan's broken Wi-Fi route. You can do this by splitting the internet route into two smaller halves. Open your .config file and change the AllowedIPs line:

    1. Remove: WireGuard.AllowedIPs = 0.0.0.0/0
    2. Add: WireGuard.AllowedIPs = 0.0.0.0/1, 128.0.0.0/1

    Because a /1 netmask is more specific than a /0 default gateway, the kernel will ignore the Wi-Fi card and force your 10.2.0.1 DNS requests straight into the wg0 tunnel. Make sure to clean the network cache, restart ConnMan, and reconnect:

    Shell session
    rm -f /storage/.config/vpn-services/*
ip route flush cache
systemctl restart connman

  • WireGuard VPN Manager

    Quote from Fabbz

    OK, I thought something like it was missing!

    I only have routing issues with wireguard; normally no issues on other systems. Have you experienced this ?


    Thanks so far; maybe this needs to be added to your Wiki including the config template ?

    Routing issues is not wireguard if your wireguard config file has settings for a VPN provider it is OK. It is connman that handles the routing. Do this cmd in ssh before connecting to a VPN:

    Shell session
    route

    Then connect to your VPN and do that "route" command again provide that here so I can see. And provide the wireguard file note edit your WireGuard.PrivateKey = ******* we do not need that!

  • WireGuard VPN Manager

    Quote from Fabbz

    Hi,

    As my OpenVPN with Proton just stopped to work yesterday I needed to see if I could use wireguard. Can i just load an Wireguard from Proton and it should be able to connect or is it not supported yet ?

    Yes if you make/download a wireguard config name it like country.config you can import it in the add-on make sure the begin of the file is:

    [provider_wireguard]
    Type = WireGuard
    Name = Custom_Country

    Rest of Proton wireguard conf...


    Salute.

  • WireGuard VPN Manager

    Quote from Reddirt

    https://paste.libreelec.tv/nephrotoxic-derrick.log

    I tested 3 locations and only one had traffic US West optimized. Might be useful to auto update/Regenerate locations after a change.

    First do:

    Bash
    rm -f /tmp/pia_token_cache.json /tmp/pia_name_map.json

    To get rid of "2026-05-30 23:50:13.420 T:1372 error <general>: service.wireguard.manager v1.4.6~beta.4: Password decoding failed, using raw password: 'utf-8' codec can't decode byte 0xe0 in position 2: invalid continuation byte"


    On every connection, the add-on gets all data live from PIA API to request local server WireGuard configurations before handing control over to ConnMan. This auto-update/Regenerate locations on every new connection. What does

    Bash
    curl http://ip-api.com | grep country

    say about the connection?

  • WireGuard VPN Manager

    That is a known issue with PIA. Dynamic, load-balanced auto-regions frequently establish a local connection link but fail to route internet traffic due to two infrastructure conflicts:

    • Virtual IP Assignment Conflict: These regions often enforce a static fallback placeholder (WireGuard.Address = 10.0.0.1/32). When ConnMan mounts this address locally, it conflicts directly with the remote server's internal gateway path. This confuses local routing tables and locks traffic into an infinite loop.
    • Un-Synchronized Gateway Balancers: Front-end balancers accept the cryptographic public key handshake and report a valid interface link status. However, they fail to sync the authentication session instantly down to the backend nodes handling live traffic. The local system brings up the wg0 interface, but the backend server drops data packets, resulting instantly network timeout.

    WireGuard Provider Architecture & Video Mapping Constraints


    But for the rest you can connect?


    Salute.

  • WireGuard VPN Manager

    The Libreelec info shows only the local network IP, the IP shown in WireGuard app is the IP from the server it connected to.

    In terminal (ssh) you can do:

    Bash
    curl http://ip-api.com | grep country

    This tells the country / region you connected to.

  • WireGuard VPN Manager

    Quote from Reddirt

    I disconnected and tried again:

    https://paste.libreelec.tv/jerkwater-keenan.log

    Shows connected but no connectivity. My test is speedtest to show new ip and speed but no connection.

    Code
    2026-05-30 19:00:57.068 T:2672     info <general>: CAddonMgr::FindAddon: service.wireguard.manager v1.4.6~beta.1 installed
2026-05-30 19:00:57.197 T:2778     info <general>: service.wireguard.manager v1.4.6~beta.1: Hardware timings loaded for Raspberry Pi 5
2026-05-30 19:00:57.197 T:2778     info <general>: service.wireguard.manager v1.4.6~beta.1: Monitor Service Initialized & Ready
2026-05-30 19:01:21.075 T:2676     info <general>: CAddonMgr::FindAddon: service.wireguard.manager v1.4.5 installed
2026-05-30 19:01:21.238 T:2829     info <general>: service.wireguard.manager v1.4.5: Hardware timings loaded for Raspberry Pi 5
2026-05-30 19:01:21.238 T:2829     info <general>: service.wireguard.manager v1.4.5: Monitor Service Initialized & Ready

    Did you uninstall v1.4.5 first? Because I see service.wireguard.manager v1.4.6~beta.1: installing (2026-05-30 19:00:57) and minute later service.wireguard.manager v1.4.5 getting installed again (2026-05-30 19:01:21).

  • WireGuard VPN Manager

    Try this one service.wireguard.manager-1.4.6~beta.1. Did you import or fill in username / password?


    Salute.

  • WireGuard VPN Manager

    Quote from Reddirt

    I'd like to test out your work and Thank You. I hoped someone might tackle this issue. I have an RPI5 and 4. Is there any specific LE build I need to use or should this work out of the box on LE12.0.2?

    It runs on the stable LibreELEC 12.2 and @deepee runs it on Raspberry Pi 5 and Pi 4 with LibreELEC nightly builds. If you have trouble with it just send debug logs.

    Salute.

  • OpenVPN Config Problem (PIA)

    Quote from chewitt

    WireGuard does not depend on OpenSSL so it will not have the same issue with bad CRL certs (as they are not used). If it has issues they will be entirely WireGuard issues.

    Wireguard not but PIA with nightly build system is using a very new version of OpenSSL. These newer version strictly enforce web standards (RFC 5280) and instantly drop connections if a Certificate Authority (CA) certificate has formatting flaws. Private Internet Access (PIA) signs their local node handshake API (:1337/addKey) using an internal root certificate that violates this strict new rule (its Basic Constraints are not marked as critical). Stable LibreELEC 12.2.1 is forgiving and ignores this, but the nightly build instantly drops the connection to protect you, resulting in the CERTIFICATE_VERIFY_FAILED crash.

    The Wireguard VPN Manager add-on will still try to run a strict, fully verified connection first. However, if it detects that nightly build's strict SSL rules are tripping over PIA's certificate formatting, it will automatically fall back to a bypassed SSL context specifically for that local PIA handshake. This allows the connection to succeed without crashing the get_live_config function in the code.