restart wireguard service

[FredFresh]

In case of restart of wireguard service using the already available cronjob, are all the calculated keys / indexes calculated again?

I am facing a peculiar situation with the vpn provider and need to understand what he is using to keeping the ban on my request of connection. Keeping active the peer (and it costantly try to connect), the ban is never removed. If i change my ip or disable the peer for a long time, the ban is removed.

Trying also to add a second question: wireguard module used in OPNSENSE is developed by OPNSENSE team or it from FREEBSD team?

Thanks

Edit:
From my test, that can alway be relicated, after the wireguard is dropped (seems at at server/peer level because if does not reply anymore), if i disable the peer for a certain time (one hour but probably less), I re-enable that peer and restart the wireguard service, than the connection return online.

The strange things are that:
- if I do not restart the wireguard (so only working on disable/enable the peer) it si not enough;
-  if during the apparent ban time, I use the wireguard app on Windows with the same settings (ip, keys, etc...) the connection happens without problems.

Parsing the different situations, the only chaning things are the calculated keys....therefore it seems there is some key that is not properly renewed by the OPNSENSE.

[FredFresh]

Today I verified that it is enought to stop the peer for 10 minutes. Once it is enabled again, the connection is properly restored....therefore I think no more it is a ban from the vpn provider, but an issue related to the renewal of one (or more) of the key that is created with a new connection.

[chemlud]

https://forum.opnsense.org/index.php?topic=51381.msg265443#msg265443

https://www.youtube.com/watch?v=pAyKJAtDNCw

:-(

[FredFresh]

I have seen something similar in the past, here a few questions:
- what is the top priority gateway (wan or wireguard gateway?;
- dynamic gateway option is enabled?
- when you say it does not start, you referring to the wireguard peer or to the wireguard gateway monitoring?

[FredFresh]

Hello,

I am not netirely sure about the root cause behind this but, I connecto to an external VPN provide and sometime the connections is dropped.

The best solution I found is to stop for at least 5 minutes that specific instance (I think I shall stop to query the server for some time) and after to enable again the instance.

The only way I found is to create script to be used through Cron, everything seems to work fine but the problem is to find a command that does not need the Administrator rights, anyone can help me on this?

Here below the script: it checks if the handhshake is older than 5 minutes and in that case it disable the interface for the needed time.

Code Select Expand

#!/usr/local/bin/bash

# --- PARAMETERS ---
INTERFACE="wg1"             
PEER_IP="10.4.0.1"           
THRESHOLD=300               
DOWNTIME=360                
WAIT_AFTER_UP=60             

LATEST_HANDSHAKE=$(wg show "$INTERFACE" latest-handshakes | awk '{print $2}')


CURRENT_TIME=$(date +%s)
ELAPSED=$((CURRENT_TIME - LATEST_HANDSHAKE))


if [ "$ELAPSED" -gt "$THRESHOLD" ]; then
   

    ifconfig "$INTERFACE" down
   
    sleep "$DOWNTIME"
   
    ifconfig "$INTERFACE" up
   
    sleep "$WAIT_AFTER_UP"

    traceroute -n "$PEER_IP"

else

    exit 0
fi

[meyergru]

There is an existing cron job for doing exactly that, it is called "Renew DNS on stale Wireguard connections", you only have to enable it.

Matter-of-fact you need it because Wireguard does retries, but never resolves a given DNS name after it was started.

[FredFresh]

Hi thanks, for the reply. Unfortunately renew dns does not work, already tried that (without specifying parameters)

Also tried restart wireguard, both trying with the UUID or "-a".
Also tried to manually disable and re- enable immediately the wireguard whole service.

The only two things working are: changing the public ip seen on Wan or to stop the retries for 5 minutes.

I am connecting to Proton Vpn, so I am connecting to the IP of their entry point.

[chemlud]

Have this cron job for DNS-resolution for stale WG tunnels for years, working fine in general. But not in this case. Only wa to resolve after reboot: Obtain a fresh WAN IP (DHCP) by changing MAC of WAN interface. Otherwise this one specific tunnel won't come back after reboot. Very, very, very annoying. Had been doing fine for years.

[FredFresh]

@chemlud did you try to traceroute to the proton peer ip? (10.2.0.1). Usually that solve your issue.

[FredFresh]

Posting here the solution found (while the cause will never be confirmed) for whoever could face the same problem:

- ssh the opnsense and create an script.sh (or the name you prefer). Thisperiodically verify the timing of the last handshake and if it older than 5 minutes, it disable the interface for 5 minutes and than it restores the interfaces (this way the handhsake is restored)

Code Select Expand

#!bin/sh

# --- CONFIGURAZIONE ---
INTERFACE="wg4"              # Nome della tua interfaccia WireGuard
PEER_IP="10.2.0.1"            # IP del peer da testare con traceroute
THRESHOLD=300                # Soggetto di timeout in secondi
DOWNTIME=360                 # Tempo di disattivazione (6 minuti = 360 secondi)
WAIT_AFTER_UP=60              # Secondi di attesa dopo riattivazione

# --- LOGICA ---

# 1. Recupera l'ultimo handshake (timestamp Unix)
# 'wg show' restituisce il timestamp dell'ultimo handshake riuscito
LATEST_HANDSHAKE=$(wg show "$INTERFACE" latest-handshakes | awk '{print $2}')

# 2. Calcola il tempo trascorso
CURRENT_TIME=$(date +%s)
ELAPSED=$((CURRENT_TIME - LATEST_HANDSHAKE))

# 3. Verifica se supera la soglia
if [ "$ELAPSED" -gt "$THRESHOLD" ]; then
   
    # Disattiva l'interfaccia
    sudo ifconfig "$INTERFACE" down
   
    sleep "$DOWNTIME"
   
    # Riattiva l'interfaccia
    sudo ifconfig "$INTERFACE" up
   
    sleep "$WAIT_AFTER_UP"

    # Esecuzione Traceroute
    traceroute -g 127.0.0.1 "$PEER_IP"

else

    exit 0
fi

After this, you have to allow the script to run using

Code Select Expand

chmod 755 script.sh
Next step is to create a dedicated cron job (for details you can search on this forum):

Code Select Expand

[START]
command:/usr/local/opnsense/service/conf/actions.d/SCRIPT_10_2_0_1_HANDSHAKE.sh
parameters:
type:script
message:Check WG handshake time and renew
description:Check WG handshake time and renew
Now the issue is that the script need to be executed by super user and the only workaround I found is to allow the two commands to be run without sudo - here I used visudo and added the following lines:

Code Select Expand

[put-your-user-here-without-brackets] ALL=(ALL) NOPASSWD: /sbin/ifconfig wg0 down
[put-your-user-here-without-brackets] ALL=(ALL) NOPASSWD: /sbin/ifconfig wg0 up
in my case wg0 is the involved wireguard interface

Because with my connections, sometime the gateway monitor does not bring back online the gateway, I also added a cron job that trace route to 10.2.0.1

This is running since 25 days and I had no more problems.

[Bob.Dig]

If you talk about ProtonVPN, I would just disable gateway monitoring altogether. Technically there shouldn't be any leaks because the gateway is considered as always up. And if it is not up, you probably will notice anyway.

[FredFresh]

Hi, the issue is that proton is not aleays online, periodically and randomically the handshake cannot be restored.

The only ways to restore it are: restart modem (changing the ip) or stop the calls to the VPN entrypoint IP for at least 5 minutes. This script use the second option.

[Bob.Dig]

Never ever had this problem. But maybe your servers are just fully utilized and then maybe showing this behavior. Looks like I had luck so far.

[FredFresh]

I think this is somehow related to my connection: I am using an LTE modem with CGNAT.

I have 3 connections, each one back up the previous one...I started using this configuration because of the connection problems with just one.