I have a double-natted setup on one side (don't ask). I have port-forwarding working all the way through into a linux box behind the double-nat. Can connect great.
But certain things seem to make the ssh connection "pause", for like 2-3 mins. It usually recovers and I can continue like nothing ever happened.
What triggers it seems to be sudden medium-large output, like if I run an ll or start top. Commands with little output don't seem to affect it, but sometimes they do, especially if the connection has been idle. It'll show me typing the command and then pause when I hit enter.
Rang bells, so I look at mss/mtu in past firewall setups and get the iptables magic to clamp the mss. If I install the rule on the box then it seems to make the pause problem go away, mostly. But often after idling the problem will return.
As always, I'm hazy on the mss/mtu, and usually solve these with trial and error -- if indeed this is another mss/mtu problem. (The gear involved is all very old.)
Instead of just shooting random clamp mss rules in the dark, I thought I'd hit up MUUG for ideas. I'd love to know how you can tell what the mss/mtu has been chosen on a given connection. Also, do I need to run a clamper on both sides? Or maybe other ideas that have nothing to do with mss/mtu?
What I've tried so far: iptables -A INPUT -i eth1 -m tcpmss --mss 1397: -p tcp --dport ssh --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1396
You can (only?) tell what the MTU/MSS *appears* to be from each devices' perspective by performing a packet capture on both ends simultaneously.
Even if it's not MTU or MSS related, I would capture just the ssh connection to file on both ends, with high-res time-stamping (may not be the default if the system is really old), and then you can literally eyeball them side-by-side in wireshark afterwards.
One other thing to check for: duplex mismatches. They're so rare nowadays we don't always remember to check for them. Not quite a textbook case, but worth looking.
-Adam
Get Outlook for Androidhttps://aka.ms/AAb9ysg ________________________________ From: Roundtable roundtable-bounces@muug.ca on behalf of Trevor Cordes trevor@tecnopolis.ca Sent: Friday, March 15, 2024 1:51:40 AM To: MUUG RndTbl roundtable@muug.ca Subject: [RndTbl] double-natted ssh weirdness
I have a double-natted setup on one side (don't ask). I have port-forwarding working all the way through into a linux box behind the double-nat. Can connect great.
But certain things seem to make the ssh connection "pause", for like 2-3 mins. It usually recovers and I can continue like nothing ever happened.
What triggers it seems to be sudden medium-large output, like if I run an ll or start top. Commands with little output don't seem to affect it, but sometimes they do, especially if the connection has been idle. It'll show me typing the command and then pause when I hit enter.
Rang bells, so I look at mss/mtu in past firewall setups and get the iptables magic to clamp the mss. If I install the rule on the box then it seems to make the pause problem go away, mostly. But often after idling the problem will return.
As always, I'm hazy on the mss/mtu, and usually solve these with trial and error -- if indeed this is another mss/mtu problem. (The gear involved is all very old.)
Instead of just shooting random clamp mss rules in the dark, I thought I'd hit up MUUG for ideas. I'd love to know how you can tell what the mss/mtu has been chosen on a given connection. Also, do I need to run a clamper on both sides? Or maybe other ideas that have nothing to do with mss/mtu?
What I've tried so far: iptables -A INPUT -i eth1 -m tcpmss --mss 1397: -p tcp --dport ssh --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1396 _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
Also if you want to be sure of avoiding all MSS issues, aim low, like 1024, instead of "just low enough" like 1396. You won't likely be able to measure the difference. -Adam
Get Outlook for Androidhttps://aka.ms/AAb9ysg ________________________________ From: Roundtable roundtable-bounces@muug.ca on behalf of Trevor Cordes trevor@tecnopolis.ca Sent: Friday, March 15, 2024 1:51:40 AM To: MUUG RndTbl roundtable@muug.ca Subject: [RndTbl] double-natted ssh weirdness
I have a double-natted setup on one side (don't ask). I have port-forwarding working all the way through into a linux box behind the double-nat. Can connect great.
But certain things seem to make the ssh connection "pause", for like 2-3 mins. It usually recovers and I can continue like nothing ever happened.
What triggers it seems to be sudden medium-large output, like if I run an ll or start top. Commands with little output don't seem to affect it, but sometimes they do, especially if the connection has been idle. It'll show me typing the command and then pause when I hit enter.
Rang bells, so I look at mss/mtu in past firewall setups and get the iptables magic to clamp the mss. If I install the rule on the box then it seems to make the pause problem go away, mostly. But often after idling the problem will return.
As always, I'm hazy on the mss/mtu, and usually solve these with trial and error -- if indeed this is another mss/mtu problem. (The gear involved is all very old.)
Instead of just shooting random clamp mss rules in the dark, I thought I'd hit up MUUG for ideas. I'd love to know how you can tell what the mss/mtu has been chosen on a given connection. Also, do I need to run a clamper on both sides? Or maybe other ideas that have nothing to do with mss/mtu?
What I've tried so far: iptables -A INPUT -i eth1 -m tcpmss --mss 1397: -p tcp --dport ssh --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1396 _______________________________________________ Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On 2024-03-15 Adam Thompson wrote:
Also if you want to be sure of avoiding all MSS issues, aim low, like 1024, instead of "just low enough" like 1396. You won't likely be able to measure the difference. -Adam
I did try lowering it a bit more. It turns out there were 2 problems (as usual): the mtu issue *and* some intermediate router in the double-nat had a really short conntrack keepalive. The latter was the fine-now-pauses-later problem and was overcome by setting stricter keepalive settings on sshd. (Should have remembered this, as I'm sure I've seen that before.)
All works great now!
-
Adam Thompson -
Trevor Cordes