On Sat, Mar 8, 2025, at 1:02 PM, Dan Langille wrote: > On Sat, Mar 8, 2025, at 11:15 AM, Marek Zarychta wrote: >> W dniu 8.03.2025 o 13:07, Dan Langille pisze: >>> Hello, >>> >>> I am getting errors when transferring data over my VPN. I'm not sure why. >>> I've recently replace the gateway / firewall device. Previously, this VPN >>> was stable and these types of transfers worked without error. >>> >>> Here is an example. mydev is behind the firewall. r720-02 is accessed over >>> the VPN >>> >>> [12:04 mydev dvl ~/tmp] % time scp -r >>> d...@r720-02.vpn.unixathome.org:bacula.dump . >>> bacula.dump 0% 0 0.0KB/s --:-- >>> ETAFssh_ssh_dispatch_run_fatal: Connection to 10.10.0.217 port 22: message >>> authentication code incorrect >>> scp: Connection closed >>> scp -r dvl@r720-02:bacula.dump . 0.14s user 0.01s system 21% cpu 0.665 >>> total >>> >>> If I try the scp direct, without using the VPN, the copy succeeds. >>> >>> Ideas please? >> >> Hello Dan, >> >> I'm not sure what type of VPN it is, but if it's OpenVPN, you might need >> to add "tun-mtu 1400" on the server side. Please refer to PR 276838. > > Yes, this is OpenVPN 2.6.13 on FreeBSD 14.2 > > I just tried "tun-mtu 1400" on the server side. I restarted all > clients. Problem persists. > > I also added "mssfix" to the server, restarted server, restarted all > clients. Problem persists. As I read the PR again, it mentions "As of > today, kernel openvpn does not seem to support `mssfix` - I'm not sure > what "kernel openvpn" is. > > The server configuration contains 'disable-dco'. > > PR 276838 mentions DCO, so given it is disabled, wtf? > > I notice that the problem exists on all the OpenVPN client except one. > That client is on FreeBSD 14.2, the failing clients are all on FreeBSD > 14.1 - hmmm. That is curious. Perhaps I should update one of the > clients and try again.
I updated one host (tallboy) from FreeBSD 14.1 to FreeBSD 14.2 - initial tests are good. Not seeing the problem on an scp which previously failed. Now doing the real test: Bacula backup over OpenVPN - about 8-9GB. I should know more by about 2145 UTC today - that's about how long that backup should take, based on the February full backup. -- Dan Langille d...@langille.org
