Wireguard keeps generating a new keypair on one client - wireguard

Question

Client 2 successfully maintains a wireguard connection.
Client 1 repeatedly creates/destroys keypairs.
Both profiles work fine on Client 2 (Android, mobile connection)
Both profiles don't work properly even though they did in the past, on Client 1 (Windows, cloud VM)
I've restarted the wg0 interface. Constant pings to the wireguard server do not show any issues from Client 1, I just can't load any pages I suspect because the keypairs constantly change. No other device is using Client 1's profile. One odd thing is how 2 keypairs seem to be created at the same time, which is likely the cause of them perpetually being destroyed.
How can I troubleshoot what is causing the keypair to need to be recreated so frequently?
2022-07-25 07:21:25.332: [TUN] [client1] Keypair 11 created for peer 1
2022-07-25 07:21:25.332: [TUN] [client1] Sending keepalive packet to peer 1 (:51820)
2022-07-25 07:21:25.518: [TUN] [client1] Receiving keepalive packet from peer 1 (:51820)
2022-07-25 07:21:41.666: [TUN] [client1] Receiving handshake initiation from peer 1 (:51820)
2022-07-25 07:21:41.666: [TUN] [client1] Sending handshake response to peer 1 (:51820)
2022-07-25 07:21:41.667: [TUN] [client1] Keypair 10 destroyed for peer 1
2022-07-25 07:21:41.667: [TUN] [client1] Keypair 12 created for peer 1
2022-07-25 07:21:41.882: [TUN] [client1] Receiving keepalive packet from peer 1 (:51820)
2022-07-25 07:22:28.060: [TUN] [client1] Receiving keepalive packet from peer 1 (:51820)
2022-07-25 07:22:52.214: [TUN] [client1] Retrying handshake with peer 1 (:51820) because we stopped hearing back after 15 seconds
2022-07-25 07:22:52.214: [TUN] [client1] Sending handshake initiation to peer 1 (:51820)
2022-07-25 07:22:52.385: [TUN] [client1] Receiving handshake response from peer 1 (:51820)
2022-07-25 07:22:52.385: [TUN] [client1] Keypair 11 destroyed for peer 1
2022-07-25 07:22:52.385: [TUN] [client1] Keypair 13 created for peer 1
2022-07-25 07:22:52.385: [TUN] [client1] Sending keepalive packet to peer 1 (:51820)
2022-07-25 07:22:52.571: [TUN] [client1] Receiving keepalive packet from peer 1 (:51820)

Answer 1

I've stumbled upon this exact issue (or very similar?) so here is what worked for me:
if the client is unable to finish the handshake - I'd suggest to try to regenerate the keys - as suggested here:
https://serverfault.com/questions/1040165/wireguard-not-completing-handshake
this however did not solve my issue..
1st verify if reported WAN IP address in wireguard server log matches the one of the client. Mine was off in the last octet - which is very strange.
Since my client is hosted on ISP network that shares one public IP address for many hose holds - it's possible that UDP packets were ending up on some other wireguard instance (?speculation) - unable to tell exactly as I have almost no visibility into ISP internal networking.
2nd if the WAN IP of client (you can verify like curl -s ipinfo.io/ip or by typing "what is my IP" into google) does not match - you may want to change client wg0.conf to listen on a different port than ListenPort = 51820 - I've adjusted it like so:
root#wg-client2:~# cat /etc/wireguard/wg0.conf
[Interface]
PrivateKey = ###MODERATED###
Address = ###MODERATED###/24
ListenPort = 51810
this client conf change does not need any server conf change.
I did wg-quick down wg0 && wg-quick up wg0 on both server and client and the comm was then established. (possible that only client needs to be restarted).
to check for wireguard kern. logs:
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control
dmesg -wT | grep wireguard
to dump all clients on server: wg show all dump
good article on wireguard logging: https://www.procustodibus.com/blog/2021/03/wireguard-logs/

Answer 2

Never came back with an update, but the issue turned out to be packets being fragmented somewhere in the path of the host. I believe on their end since it worked for years then suddenly stopped. I reduced the MTU in the wireguard config and the problem was resolved.
Just in case someone else runs into similar...