> Then I tried *this*:...> Yes, that's eight times the *same* algorithm (the one that would get > picked if there were no problem at all). Now let's try giving it only > *seven* thumbs-up:...> [ ... continue to successful connection]Yeah, that smells like MTU.> Still possible that it's a pMTU detection problem or something alike > it, though, will have to look into the tcpdumps I now have to see > whether that's the case ...When you have the blocking case, run "ss -i" to see the PMTU; and/or run "tracepath -p 22 <host>" to diagnose. Furthermore, you could try to set your own VM's MTU smaller to see whether that solves the problem.> (Both VMs are CentOS 7.9, the client a "free-range" one, the server a > cloud provider's sub-flavor. There's a handful of VLANs, leased line > uplink to a colo, then an IPsec VPN through the Internet into the > cloud, and finally the usual cloud networking between the two.)Yeah, lots of PMTU trouble points here inbetween. If that's the case, you could either run one of the VMs with a smaller permanent MTU, or set a route-specific MTU ("ip route via mtu"). Good luck!
On 17.11.21 18:48, Philipp Marek wrote:> Yeah, that smells like MTU.Ayup, at least *this* instance turned out to have had a pMTU discovery issue as its root cause (*#%!! legacy firewall). Not sure that the two previous instances of the problem had the same cause, though, as they fixed themselves before I could nail down the details. Neither went over that same FW and one did not go across *any* connections where I'd expect MTUs to change without *our* physical intervention ...> When you have the blocking case, run "ss -i" to see the PMTU; > and/or run "tracepath -p 22 <host>" to diagnose.Not sure that those two actually showed any telltale signs, but I admit I'm not used to them ... :> tcp ESTAB 0 0 $CLIENT:44006 $SERVER:ssh > cubic wscale:9,7 rto:226 rtt:25.756/18.351 ato:40 mss:1448 > rcvmss:1386 advmss:1448 cwnd:10 bytes_acked:16274 > bytes_received:17929 segs_out:365 segs_in:336 send 4.5Mbps > lastsnd:21559 lastrcv:21548 lastack:21509 pacing_rate 9.0Mbps > rcv_rtt:140 rcv_space:29200> # tracepath -p 22 $SERVER -n > 1?: [LOCALHOST] pmtu 1500 > 1: $B0RKEN_FW 0.760ms > 1: $B0RKEN_FW 0.505ms > 2: $NEW_EDGE_FW 2.523ms > 3: $NEW_EDGE_FW 2.617ms reached > Resume: pmtu 1500 hops 3 back 2However, good ole fat ping> # ping -M do -s $SIZE $SERVERshowed pongs up to SIZE=1410, "too long"s from SIZE=1473 upward, and no replies in between (because the NEED TO FRAGMENTs came from transfer net IPs and $B0RKEN_FW doesn't do proper ESTABLISHED,RELATED). Thanks again, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3449 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20211117/33947d9c/attachment-0001.p7s>