there are situations where stateful firewalls can forget about the wireguard session, but one or more of the peers remember it. Even wireguard’s keepalive wont fix that situation.
my “bandwidth is basically free” solution: I have a script that basically pings an endpoint over a tunnel, and restarts that tunnel if said endpoint cant be reached twice in a row. This has worked well for a little over four years now across multiple tunnels. (I’d share my script but its in a form that pulls in libraries from a common library at work - which I definitely cant share. I can rewrite the functions it uses and publish a public variant of the script, maybe I will someday. Back to your world, I also suspect that this functionality might already exist in some form, e.g. scripted in via ifstated) > On Nov 15, 2024, at 9:12 AM, Will <bulk.m...@xhci.com> wrote: > > I’m struggling to resolve an issue where some wg peers aren’t reconnecting. > All wg clients have no open incoming ports, and the wg server facilitates ssh > access among peers. This is my solution for all the clients having dynamic > IPs rather than using something like dynamic DNS. > > I have a wg debian server with a pretty straightforward config. I have a mix > of linux and openbsd clients connecting to it. > > [Interface] > Address = 192.168.10.1/24 > Address = fd22:eb0c:420d::1/64 > ListenPort = 51820 > PrivateKey = xxx > > [Peer] > PublicKey = xxx > PresharedKey = xxx > AllowedIPs = 192.168.10.2/32, fd22:eb0c:420d::2/128 > > ... > > > > For the OpenBSD clients, the hostname.wgX looks similar to: > > inet 192.168.10.2 255.255.255.0 > inet6 fd22:eb0c:420d::2 64 > wgkey xxx > wgpeer xxx wgendpoint [serverip] 51820 wgaip 192.168.10.0/24 wgaip > fd22:eb0c:420d::/64 wgpka 25 wgpsk xxx > up > > > > Just for comparison, here is a linux client: > > [Interface] > PrivateKey = xxx > Address = 192.168.10.3/32, fd22:eb0c:420d::3/128 > > [Peer] > PublicKey = xxx > PresharedKey = xxx > AllowedIPs = 192.168.10.0/24, fd22:eb0c:420d::/64 > Endpoint = [serverip]:51820 > > > > Restarting the wg interface or rebooting the OpenBSD machine fixes the issue. > I believe the connection is dropping when the route to the server is > unavailable for some period of time (like after a brief internet outage). I > would expect “wgpka 25” to reconnect automatically, but manual intervention > is required when a client gets into this state. I have not experienced this > issue with the Linux clients on the same network, and I haven’t seen anything > in /var/log/daemon or /var/log/messages. > > I know I have seen this behavior on OpenBSD 7.5 and 7.6. Also just for > clarity - this configuration works really well for some number of days/weeks > until the OpenBSD clients get stuck in whatever error state I’m encountering. > > Thanks! > Will >
