Temporary Crypto Glitches ... ??

[Philipp Marek]

>> 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).

Ack.


> 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.

Well, perhaps some routing changed.


>> 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

Grrr, the "mtu" field was cut out on your end because of the long lines.


>> # 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 2

Ok, so no ICMPs are returned...


> However, good ole fat ping
> 
>> # ping -M do -s $SIZE $SERVER
> 
> showed 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).

Well, there you are.