Is it helps in your case?

set interfaces wireguard wg0 disable 
commit
del interfaces wireguard wg0 disable 
commit

There is no any native command for reset wireguard interface in Linux (as I know). Also, we don't use any daemons which we can restart to "re-establish" session.
Is one host behind nat?

In T3640#96759, @Viacheslav wrote:

Is it helps in your case?

set interfaces wireguard wg0 disable 
commit
del interfaces wireguard wg0 disable 
commit

There is no any native command for reset wireguard interface in Linux (as I know). Also, we don't use any daemons which we can restart to "re-establish" session.
Is one host behind nat?

Disabling and enabling the Wireguard interface didn't bring it back, In other Linux distro, doing a wg-quick down and wg-quick up bringing up the connectivity back, and yes, the host is behind NAT

We don't use any configuration file for it, so I think we can't use wg-quick
We use "wg set"

$ sudo wg set --help
Usage: wg set <interface> [listen-port <port>] [fwmark <mark>] [private-key <file path>] [peer <base64 public key> [remove] [preshared-key <file path>] [endpoint <ip>:<port>] [persistent-keepalive <interval seconds>] [allowed-ips <ip1>/<cidr1>[,<ip2>/<cidr2>]...] ]...

In T3640#96771, @Viacheslav wrote:

We don't use any configuration file for it, so I think we can't use wg-quick
We use "wg set"

$ sudo wg set --help
Usage: wg set <interface> [listen-port <port>] [fwmark <mark>] [private-key <file path>] [peer <base64 public key> [remove] [preshared-key <file path>] [endpoint <ip>:<port>] [persistent-keepalive <interval seconds>] [allowed-ips <ip1>/<cidr1>[,<ip2>/<cidr2>]...] ]...

wg-quick actually is just a bash script for wg commands, the way wg-quick down command done is by removing the interface, we can replicate this by bringing down the interface by removing it, then reconfiguring it back up

If your host is behind NAT, could it possibly be that the NAT translation entry expired?

Does the following work:

ip link set dev wg0 down; ip link set dev wg0 up

In T3640#96876, @c-po wrote:

If your host is behind NAT, could it possibly be that the NAT translation entry expired?

Does the following work:

ip link set dev wg0 down; ip link set dev wg0 up

No, the interface stays inactive and no handshake happens still

vyos@vyos:~$ sho int wireg wg0
interface: wg0
  address: 10.0.69.3/32
  public key: (hidden)
  private key: (hidden)
  listening port: 46092

  peer: ldp
    public key: (hidden)
    latest handshake: 0:06:50
    status: inactive
    endpoint: (hidden)
    allowed ips: 0.0.0.0/0
    transfer: 21 KB received, 1 MB sent
    persistent keepalive: every 25 seconds

    RX:    bytes  packets  errors  dropped  overrun       mcast
           21904      220       0        0        0           0
    TX:    bytes  packets  errors  dropped  carrier  collisions
         1069072     7345       0     5765        0           0
vyos@vyos:~$ sudo ip link set dev wg0 down; sudo ip link set dev wg0 up
vyos@vyos:~$ sho int wireg wg0
interface: wg0
  address: 10.0.69.3/32
  public key: (hidden)
  private key: (hidden)
  listening port: 46092

  peer: ldp
    public key: (hidden)
    latest handshake: 0:07:08
    status: inactive
    endpoint: (hidden)
    allowed ips: 0.0.0.0/0
    transfer: 21 KB received, 1 MB sent
    persistent keepalive: every 25 seconds

    RX:    bytes  packets  errors  dropped  overrun       mcast
           21904      220       0        0        0           0
    TX:    bytes  packets  errors  dropped  carrier  collisions
         1069664     7349       0     5788        0           0

Wireguard has no link states on the interface, the ip command just does an 'administrative' up down, which won't start a renegotiation. The policy description (remove peer) needs to be removed from the wg interface and re-added, otherwise you need to wait until wg tries to rekey which will then eventually renegotiate the entire connection.
The removal was as far as I recall part of the original vyos code, so it may have been removed at one point, I haven't looked into the code yet.

For NAT, try setting persistent-keepalive, that is supposed to keep the NAT entry active, even if you have no traffic for the tunnel.

In T3640#96937, @hagbard wrote:

Wireguard has no link states on the interface, the ip command just does an 'administrative' up down, which won't start a renegotiation. The policy description (remove peer) needs to be removed from the wg interface and re-added, otherwise you need to wait until wg tries to rekey which will then eventually renegotiate the entire connection.
The removal was as far as I recall part of the original vyos code, so it may have been removed at one point, I haven't looked into the code yet.

For NAT, try setting persistent-keepalive, that is supposed to keep the NAT entry active, even if you have no traffic for the tunnel.

I do have persistent-keepalive set to 25 seconds as shown on that show interface output and it still unable to bring back the connection back upon inactivity

I think it will be enough to remove the peer and add again.
@hagbard what do you think?
https://github.com/vyos/vyos-1x/blob/d48dddab0509e562209adfb115b0e691b8e47f54/python/vyos/ifconfig/wireguard.py#L197

In T3640#96973, @Viacheslav wrote:

I think it will be enough to remove the peer and add again.
@hagbard what do you think?
https://github.com/vyos/vyos-1x/blob/d48dddab0509e562209adfb115b0e691b8e47f54/python/vyos/ifconfig/wireguard.py#L197

Looks good to me, but I can't merge anything anymore into the vyos repo. sorry.

There is a link to the existing code for configuration mode, not pr.
So we can to add the op-mode function to re-add/reset with a similar logic. Only thoughts

There's something weird happening with this. If you change simply persistent-keepalive from 25 to 30 or 30 to 25 will reactivate the peer. At least thats my experience. Doing anything else didnt work for me including:

set interfaces wireguard wg0 disable
commit
del interfaces wireguard wg0 disable
commit