Posted: Fri Sep 11, 2020 9:56 Post subject: [REOPEN] "unstable" SSH connection with Wireguard
Hi,
recently I switched from openvpn to wireguard to connect multiple debian and android clients. Im using an ASUS RT-ACU68U as wireguard server (oet2) for my clients and the router itself is a client to a commercial VPN provider (oet1). All traffic (local and wireguard clients) is routed through the commercial VPN. The endpoint for my wireguard clients is the ISP IP (wireguard client > ISP network > router > commercial wireguard VPN > internet).
Everything is working as before with openvpn and all clients can connect and communicate with each other with top speed. I'm using SSHFS to mount my data storage (a mini PC connected via ethernet) and here is the issue. It seems that the connection is unstable. While copying large files or "streaming" a movie from the storage, the connection is sometimes interrupted. Every Peer is affected. This is really annoying because my daily backup (borgbackup via SSH) fails almost every time.
So I tried different MTU settings (1460, 1420, 1400, 1300). With a MTU of 1460 the speed is very low. 1420 and lower is working fine expect the packet losses or whatever this is.
Here is an example:
Code:
user@10.0.1.40:~$ scp user@10.0.0.2:/data/test/* .
File1.test 100% 472MB 2.6MB/s 03:05
File2.test 100% 363MB 2.7MB/s 02:14
File3.test 15% 76MB 3.5MB/s 01:58 ETA
ssh_dispatch_run_fatal: Connection to 10.0.0.2 port 22: message authentication code incorrect
lost connection
Just after the "lost connection" i can rerun the command and it is working like nothing happend - and maybe it is interrupted at another time.
Ping with 0.1s interval = 83% packet loss to Server
Those are not the newest versions especially form theWG tools.
Consider upgrading to the latest.
But is smells like an MTU problem remember also the client MTU settings often need to be adapted
Okay, done. But the problem remains.
Per Yngve Berg wrote:
To find the largest MTU, ping with the no fragmentation switch set.
ping -4 <host> -M do -s 1420
When set to large, the packets will no longer go through.
I've seen this many times, but I have trouble understanding how it helps. If I set the MTU on the server and client side to 1400 bytes and try to ping 1420 bytes it doesn't work, and when I try ping 1372 bytes it works. No surprise in that. Can you please explain how to find the right MTU for the server and client? Does the size for server and client have to be the same or does the client have to be 28 bytes smaller?
The ping method didn't work for me. I got several good results with high MTU, but the packet lost with SSH was still there. So I tried more settings and it seems that an MTU of 1300 bytes on both sides is stable. I thought I had already tried this.
Wireguard is only UDP, there are no mechanisms to resend pakets available compared to TCP/IP.
If a hop between "you" and "target" suffers from overload, it might also result in a lossy connection.
Does a mtr between "you" and "target" show any oddities?
I often use this syntax to force mtr to resolve AS names and doing udp:
Wireguard is only UDP, there are no mechanisms to resend pakets available compared to TCP/IP.
If a hop between "you" and "target" suffers from overload, it might also result in a lossy connection.
Does a mtr between "you" and "target" show any oddities?
I often use this syntax to force mtr to resolve AS names and doing udp:
mtr -4 your.target.xyz -u -b -z
(run it without VPN enabled ofc.)
I have no packet loss without a VPN. Everything seems to be fine. I've been using OpenVPN over UDP with the same setup for many years and haven't had any such problems. So I would like to rule out configuration or hardware problems - except Wireguard of course
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Tue Sep 15, 2020 14:32 Post subject:
You may need a lower mtu for oet2 than for oet1. After all, its packets via oet1 and your commercial provider pass through a different network than oet1 itself sees. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
You may need a lower mtu for oet2 than for oet1. After all, its packets via oet1 and your commercial provider pass through a different network than oet1 itself sees.
This is already the case, but it is also unimportant as it is the client-to-client connection via Wireguard running over the ISP network. The commercial VPN is not involved.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Thu Sep 17, 2020 22:41 Post subject:
Ah! Sometimes I just hope my ignorant ramblings will trigger someone else to have a thought that's actually useful! _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
