0

I have a device connected to my home network that wants to SSH via WireGuard VPN Peer. The VPN subnet is 10.0.0.x/24.

The issue is:

  • I can successfully connect to the device via SSH.
  • The SSH session works fine initially but disconnects after about 1 minute.
  • After the disconnect, I have to reconnect manually.

What I’ve tried so far

  1. Lowered the MTU on the WireGuard interface (Ubuntu server side) to 1280 → no effect.
  2. Checked /etc/ssh/sshd_config for any timeout-related flags. I also tried adding:
    ClientAliveInterval 30 ClientAliveCountMax 3 
    Rebooted the server → no effect.
  3. Verified that the WireGuard client has PersistentKeepalive = 25 configured.
  4. General network connection seems stable (no packet loss outside of SSH).
  5. Tried to get verbose logs via ssh -vv but it just freezes the terminal without handing any log value

Question

How can I prevent SSH sessions from dropping after ~1 minute over?

5
  • You should run tcpdump -i ifname -n tcp port 22 on both sides (in tmux / screen) to see what is going on. Is the SSH connection from one wireguard endpoint to the other or are more (logical) network sections involved? Setting the MTU would be enough only from endpoint to endpoint. Otherwise you need MSS rewrite in nft / iptables. Commented Aug 31 at 1:58
  • I’ll read your words as: the disconnect happens approx 1 minute after connection regardless of what you are doing on ssh, not 1 minute after leaving the ssh terminal idle. If so then this is not a keep-alive issue and unlikely to be ssh related. This smells like something is not stable woth your wireguard setup. I would keep a ping running while testing to be sure. Commented Aug 31 at 2:19
  • Not an answer to your question, but a comment on your procedure: You do not need to reboot the server to restart sshd or any other daemon. Just restart the daemon, e.g. systemctl restart sshd. Rebooting is for upgrading kernels or device driver modules. Or for when the kernel's got itself into a weird state due to hardware errors - e.g. stuck re-reading bad sectors on a disk, or spurious pci bus errors from a dodgy wifi card or similar. Or when you've locked yourself out of a remote system due to user error (like killing sshd or fail2ban-ing your SRC IP). Commented Aug 31 at 2:29
  • I suggest setting ServerAliveInterval in the client rather than bothering with the ClientAlive settings in the server. There are network devices that will still break your connection, but it's fairly rare. Are you sure something on the server isn't noticing the login and killing the processes after a minute? Commented Aug 31 at 4:23
  • Thank you all for the input! I tried the suggestions from HaukeLaging and SottoVoce. From the tcpdump traces I can see that I’m not exceeding the receiver’s advertised window or the path MSS, so it doesn’t look like I need MSS rewriting. That points more towards @PhilipCouling guess — likely something unstable or mismatched in my WireGuard configuration. The SSH disconnect happens regardless of activity, and the packet capture shows the packets are well within size limits, so I’ll keep digging into the WireGuard setup itself. Commented Aug 31 at 10:44

1 Answer 1

3

After digging deeper into the issue, I realized the problem wasn’t with SSH itself or with WireGuard’s MTU/keepalive settings, but with how my network routing was set up.

Setup

Laptop (192.168.100.111) -> Gateway/Firewall (192.168.100.1) -> Server hosting WireGuard (192.168.100.115) -> WireGuard Peer (10.0.0.8) 

Root Cause

The problem was caused by asymmetric routing.

  • Packets went through the firewall initially, which created a state entry and sent back an ICMP redirect.
  • Replies from the WireGuard peer bypassed the firewall, so the firewall never saw the full handshake.
  • When its state expired, packets fell back through the firewall and were dropped.
  • This caused the SSH session to disconnect.

See explanation of asymmetric routing for more details.

Solution

Added a direct route from my Laptop to the WireGuard Hosting Server into so traffic always goes through the WireGuard server and not the firewall from the router:

sudo ip route add 10.0.0.0/24 via 192.168.100.115 

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.