When the Red connection is broken and chomes back all Wireguard connections are green, but there is no connection to the opposite point.
I tried to restart the Service with a Script, but it is not working.
/usr/local/bin/wireguardctrl S
Wireguard is a kernel service so the wireguard initscript is not starting wireguard as a service.
It is setting up the firewall requirements, restarting the firewall and setting up the interfaces.
When the red connection came back did you confirm that you could then access the internet via your IPFire?
What message do you get if you run the command
/etc/rc.d/init.d/wireguard start
If it says
Starting WireGuard VPN... [ OK ]
then that means that the wireguard interface and firewall rules were set up and the firewall reloaded so there must be some an issue elsewhere.
On my vm testbed that had working wireguard connections between two vm ipfire systems, I disconnected the red interface for 5 minutes. Confirmed that no connection via wireguard could be made but also no connection to the network on the red interface as would be expected.
I then re-instated the red interface. After a few seconds the connection was remade. I could then access the internet again via that vm IPFire system. Tested the wireguard connection and I was able to connect to the other vm IPFire via wireguard.
So with the above sequence I have not been able to reproduce your effect.
If you run the command ip address show do you see any wg interface lines?
I will check this next time the Internet Connection was broken.
To Restart the Connection i have to disable one of the Tunnels, wait 5 Sekonds and reenabel it. After 5 Sekonds the Connection is up again, to all.
The opposite Points are AVM Fritz Boxes
Today my DSL Connection was broken again.
After i did /etc/rc.d/init.d/wireguard start all Tunnels where up again.But ther came some Errors:
Error: any valid prefix is expected rather than “xxxx.dyndns.org”.
This message sounds to me like the IP has not been updated yet for the DDNS FQDN.
When your DSL connection is broken do you end up with a new IP after the connection is resumed.
In that case the DDNS update is done every 5 minutes via fcron so after the IP is updated and the connection remade there could be a delay of up to 5 minutes before the DDNS is updated with the new IP.
If your IP is not updated and stays the same then I have no idea why that error message would be shown or why disabling one of the tunnels and re-enabling it would fix whatever is causing that error message.
But why are all the Tunnels shown green in the GUI, is there no mechanism to check whether they are realy up?
Yes there is. Wireguard runs a handshake every 120 seconds and if this number is reset then the connection has an endpoint and is connected.
I just tested this and disconnected the red interface on my vm IPFire and after a period of time the connection was show as red Disconnected.
You can check this out next time your red connection is disconnected.
Run the command
/usr/local/bin/wireguardctrl dump
This will give you the status of your WG connections. Here is the output from my vm system for the connection I was testing with the dump command ran at three different times.
Public Key PSK Endpoint Allowed IP's latest handshake TXFR RX TXFR TX Persistent Keepalive
xxxxxxxxx yyy 192.168.26.40:42026 10.10.27.1/32 1777457945 32160 55616 off
xxxxxxxxx yyy 192.168.26.40:42026 10.10.27.1/32 1777458154 32160 55616 off
xxxxxxxxx yyy 192.168.26.40:42026 10.10.27.1/32 1777458763 106572 141364 off
The first line was the status when the connection was working and it was showing as Green Connected.
I also checked the output after two lots of 120 secs and each time after the 120 seconds was up the handshake value was updated. Basically the number is the Linux Epoch Number. The code takes the current time in Epoch and subtracts the latest handshake value from the dump command. If the difference is less or equal to 120 then it shows the connection as Connected in Green.
The second line was after I had disconnected the red interface on the vm IPFire. after a period of time the connection showed as red Disconnected and from then on the latest handshake value did not get reset so it stayed at 1777458154
I then reconnected the red interface and waited and after a period the connection went back to Green Connected. The dump command showed that the latest handshake value was again being updated every 120 seconds to the latest Epoch number.
When your system loses its red connection again then wait for at least 120 seconds and refresh the wireguard browser page and use the dump value to see if the latest handshake value is updated every 120 seconds.
I would be surprised if it is being updated if the red connection is not working. You can also look at the Transfer RX and TX numbers to see if there is actual traffic going through the tunnel.
In my case when the red connection was removed then the TXFR RX and TXFR TX numbers stopped changing.
If your wireguard RW tunnel continues to pass traffic and update the latest handshake then I would not expect the red connection to be disconnected.