On Thu, Jul 08, 2021 at 12:18:09PM -0400, Brian Brombacher wrote: [..] > Are you changing the default TCPKeepAlive setting? It defaults to yes. It > exists as options in sshd_ and ssh_config. Additionally, ClientAliveInterval > and ServerAliveInterval might be handy. A sysctl also exists to turn TCP > keep alive on for all connections by default. >
I didn't change that setting but I have this on pod's sshd_config: #TCPKeepAlive yes > Not sure it???ll help. Does your download crawl to a halt, then after a > period of time, you get the FIN? So what I'm doing is 'scp pod:Backup/*gz .' to the local directory on arda (local host). In the tcpdump the packets go by fairly rapidly in fact there is a lot of packets before the FP (fin packet) even makes it through to arda (because there is at least a dozen packets in flight). One note here: I applied the IPSEC to escape any in-band attacks, however when I did that last week, the very first time I tried to scp my backups the connection did indeed crawl to a halt. It was just sitting there. I worried back then that someone spoofed WIN 0's into the IPSEC'ed stream somehow but I applied anti-spoof rules on IPSEC so that can't happen and the fear was probably unfounded in retrospect. I still don't have an explanation for myself for that though. Perhaps it was the missing scrub to lower the MTU on enc0 which isn't adjustable? Anyhow last week then I did manage to download the 4 GB of backups, but doing so this week proved to not work. > (Note: I don???t have any Hetzner hosts and I???m just guessing based on my > experience with Azure) > > -Brian Thanks. I looked over my firewall rules on enc0 a little and did notice I have a scrub rule that changes the mss to 1240 I'm not sure tough if that will cause this behaviour. It wasn't used anyhow when I just did the plain scp without wrapping IPSEC around it, and then it still FIN'ed and subsequent RST'. Best Regards, -peter
