Messages

I already tried that, but it does not provide the same information.

I have a cpu n100 and 16gb of ram, keeping the unbound dns log active is detrimental for performances?

Is it possible to get a log as in

reporting -> unbound -> details

but extended to much more than 1000 lines and to be able to download it?

The log under services -> unbound dns -> log file seems to be more related to check it is probably working than to get a clear log of the queries.

Thank you.

I did tests for almost 2 years without identifying solution...but honestly I think that the cause lies both on proton side but also on opnsense side: while I am not able to restore the handshake with server A (using opnsense), instead I can do using exactly the same keys&parameters but using the wireguard app on a computer.

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.

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.

Generally speaking (AFAIK) you can redirect flow going inside an interface, but not a flow that only exit (in this case originated by the firewall itself and leaving through the wan)

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.

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

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.

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

Please double check, but I am pretty sure that with the new release, the firewall rules shall be manually handled.

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?

Can you confirm if for you it is the peer or the gateway that is marked offline?

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.

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.