Solved - SSH & Cockpit stopped responding via 44net Connect VPN

OS : Debian GNU/Linux 12 (bookworm)
OS Kernel : 6.12.87+rpt-rpi-v8

Asterisk : 22.9.0+asl3-3.9.3-1.deb12
ASL [app_rpt] : 3.9.3

Finally solved a strange problem I've been chasing for over a week on my ASL3 node (Rpi4+Shari Bookworm). Thought I would share what happened in case it is helpful to others. I'm using a 44net Connect VPN to get around the Echolink & IAX port issues with my ISP (T-Mobile). All had been working for months but about a week ago a power outage cased the node to reboot but after this reboot I could no longer SSH into the node or bring up the Cockpit web page (both stalled and eventually timed out). The node was functioning correctly (registering, connecting to other nodes, etc) otherwise including allowing incoming IAX & Echolink connections. All necessary ports were still showing open. Tried dropping the wireguard VPN and rebooting the node and then SSH, Cockpit, etc worked just fine over the LAN (but not IAX & Echolink of course). After hours of debugging and pulling what was left of my hair out, I finally tried an AI suggestion to reduce the MTU max size from the MTU = 1380 statement in the wireguard client configuration file 44net Connect generates when you set up your tunnel to 1360 and voila Problem Solved. I'm not sure what changed (ie root cause) but suspect when the reboot re-established the VPN the MTU max was too large to facilitate additional packet header information or something similar. Maybe someone more familiar with recent changes has more insight but if you suddenly loose SSH & Cockpit access via your 44net Connect VPN, try reducing the MTU max size.

I would go ahead and reduce the MTU to 1280 in the wireguard config file. That'll make sure you don't have issues. I had the same issue. Googling it with Allstar in the mix didn't help me find anything, when i googled it using the words Debian 13, i came up with the answer you had, MTU being too large.

Agree. 1280 is exactly what I ended up using to help "future proof" this from happening again. I couldn't find any way on the 44net Connect website to provide feedback but did send an Email to ARDC pointing out the issue and suggesting that they reduce the max MTU to 1280 in the cut & paste Wireguard wg0.conf file they generate when you create a tunnel.

I don't use 44net, but I do use Wireguard extensively for some things. I ran into this a couple of weeks ago when I migrated a node from a fiber ISP to a mobile provider. The previously working Wireguard suddenly became unusable because the MTU was too large for that mobile provider. Changing it from 1420 to 1280 fixed it.