LE 11 and Wireguard VPN to my Unifi Dreammachine

QBJack · October 11, 2023 at 12:59 PM

Hello guys,

I need help to get a working VPN connection from Rpi4 with LE 11 (latest as today) to my Unifi Dreammachine.

I used this instruction to setup the LE side: WireGuard - LibreELEC.wiki

On my Unifi DM I created a new WG client and downloaded the provided config file. This files contains most data for the config on LE side like privatekey, publickey, allowed-ips and so on. UDM version is the latest release as well.

From that information given I created the following wireguard.config file :

Code

[provider_wireguard]
Type = WireGuard
Name = myvpn
Host = <public ip of my UDM>
WireGuard.Address = 192.168.4.2/32
WireGuard.PrivateKey = <private key here>
WireGuard.PublicKey = <pubic key here>
# WireGuard.PresharedKey =
WireGuard.DNS = 192.168.4.1
WireGuard.AllowedIPs = 192.168.4.1/32,192.168.4.2/32,0.0.0.0/0
WireGuard.EndpointPort = 51820
WireGuard.PersistentKeepalive = 25

Display More

When starting the VPN connection I get:

Code

LibreELEC:~/.config/wireguard # connmanctl connect vpn_my_ip_here
Connected vpn_my_ip_here

but trying to ping the VPN gateway's private IP or anything else on my private network gives me this:

Code

LibreELEC:~/.config/wireguard # ping 192.168.4.1
PING 192.168.4.1 (192.168.4.1): 56 data bytes
ping: sendto: Required key not available

Simple ping is not possible and my UDM shows no VPN clients connected at all.

Using this exact config from my UDM on my Wireguard Windows Installation just works without issues and I can ping and access my network stuff.

Please help on that. Thanks in advance.

Best regards

Thomas

QBJack · October 11, 2023 at 2:12 PM

Of course I have already searched the forums and other discussions about that but did not found any working solution.

**chewitt** · October 11, 2023 at 9:50 PM

Code

WireGuard.Address = 192.168.4.2/24

What happens with /24 instead of /32 ?

QBJack · October 13, 2023 at 8:41 AM

Unfortunately the same behaviour - could not ping anything. My UDM does not see this VPN client connected anyway. When I connect my Windows client I can see this on my UDM. So I think the VPN connection is not really established at that moment.

Scritch · October 15, 2023 at 9:25 PM

This sounds very similar to the behavior which I observe with my Wireguard VPN server hosted on my Fritzbox.

Connections work 100% reliable when connecting other networks via Fritzbox or clients eg from my Android mobile device.

When connecting from LE on my Raspberry PI 3, the connection is reported to be established.

However, the connections is available only sporadically.

Using ping, I see that for 80% of the connection attempts, the connection is not available. Sometimes ping works after establishing the connection. But only for a limited time. After less than 5 minutes (exact timing is random) ping stops working, and never recovers afterwards.

Checking the connection on LE using "wg" command, the connection is reported as established, even though the connection obviously dropped.

Code

gaeste:~ # wg
interface: wg0
  public key: <edited - removed>
  private key: (hidden)
  listening port: <edited - removed>

peer: <edited - removed>
  preshared key: (hidden)
  endpoint: <edited - removed>
  allowed ips: (none)
  transfer: 444 B received, 1016 B sent
  persistent keepalive: every 25 seconds

Display More

In the Fritzbox connection details the connection sometimes even gets a green checkmark.

However, in contrast to the working connections, the LE connection never receives a timestamp in the "last negotiation" column:

QBJack · January 2, 2025 at 10:52 AM

Hello and a happy new year.

I have updated LE to 12.0.1 and gave that wireguard VPN a second chance. The behavior is the same, connection does not work - exactly the same as in LE 11 over a year ago.

Does somebody has any ideas how to make that work as it is an official supported method and described in LE wiki to be supported.

Thanks.

**chewitt** · January 3, 2025 at 9:55 AM

I've sent you a PM on the topic. In short, share a config for me to play with and I'll see if I can get a connection working.

Grasshopper · January 4, 2025 at 3:07 PM

QBjack, would be beneficial to see UDM created config file when you went to add libreelec device as a client and connman config file you created from that info.

QBJack · January 9, 2025 at 7:24 PM

After playing around a bit, I think that I have found the reason for that behavior. I used my VPN server's (public) hostname (fqdn) instead of it's public IP address. Using an IP makes the VPN connection work.

Great that it works that way but using an dynamic public IP (which can change from time to time) is not a great solution as you have to check and manually edit those config files again on every IP change.

Is that really so, that this wireshark implementation cannot handle hostnames (fqdn) and must use IPs instead?

**chewitt** · January 10, 2025 at 3:01 AM

WireGuard requires the host (server) to be an IP address and ConnMan does not implement logic to resolve an FQDN to an IP before configuring the WireGuard interface and bringing it up, or perform periodic validation of an FQDN to detect IP changes.

It's not an impossible problem to resolve [sic]. Create a script that resolves the FQDN against a trusted upstream DNS server (not a local one which caches results) and compares the IP to the current WireGuard conf IP, and if different, sed the value in the conf and then restart the WireGuard service to recreate the connection with new values. Use cron or a systemd timer (which is cron) to run the script at periodic intervals.

Scritch · January 10, 2025 at 7:54 PM

I can confirm that the problem I had posted above (Wireguard with Fritzbox host) works when I switch the config to an IP instead of a FQDN.

I think this limitation could be highlighted a bit more prominently in the wiki page. Yes, the wiki mentions only an IP address. However, by default one could assume that it could be easily replaced with an hostname. Adding one sentence to the known issue chapter stops people like me from going into the wrong direction. A direction which is well possible to take as VPN and Dyndns is a very common combination for many use-cases. (For me, I use it to connect to my tvheadend instance at home when travelling.)

**chewitt** · January 11, 2025 at 7:24 AM

The wiki is open to public contributions.

QBJack · January 13, 2025 at 10:42 AM

Thanks for adding the part regarding public IP for the VPN server.

QBJack · January 13, 2025 at 1:35 PM

Scritch Try this instructions:

Post

RE: Wireguard - changes the default route although not configured

After a few days I managed to solve default route issue. Below there are my scripts with descriptions.

WG configuration:

/storage/.config/wireguard/wg0.conf

(Code, 9 lines)

Wireguard startup script:

/storage/.config/wgconnect.sh

(Code, 15 lines)

Stop Wireguard connection:

/storage/.config/wgdisconnect.sh

(Code, 3 lines)

Systemd service:

/storage/.config/system.d/wireguard.service

(Code, 15 lines)

Then all traffic routes via default eth0 interface and several ip's via wg0. Routes look as follows:

(Code, 11…

knedlyk

September 26, 2022 at 12:58 PM

Worked for me perfectly and it has the benefit that you can use a FDQN / hostname for the VPN server.

**chewitt** · March 26, 2025 at 2:30 AM

Pinging this thread to raise awareness of new WireGuard capabilities that need testing:

Thread

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…

chewitt

March 25, 2025 at 12:59 PM