Tunnel disconnects with "peer ignored channel window"

[Damien Miller]

On Mon, 20 Oct 2025, valt aran wrote:

> Yeah I did that but it didn't change anything.
> With the patch and removing that part I don't get disconnects. But still the connection is buggy, gives handshake errors sometimes and failed downloads/connections.
> I get lots of
> 
> " channel 0: datagram length 1444 too big for window 476 or maximum packet 32768"
> 
> at the beginning. These messages stop after a while and instead I get a cycle with many
> 
> "debug1: enqueue packet: 93"
> 
> followed occasionally by
> 
> " SSH2_MSG_KEXINIT received
> debug1: kex: algorithm: mlkem768x25519-sha256
> debug1: kex: host key algorithm: ssh-ed25519
> debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
> debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
>  debug1: expecting SSH2_MSG_KEX_ECDH_INIT
> debug1: SSH2_MSG_KEX_ECDH_INIT received
> debug1: mm_answer_sign: hostkey ssh-ed25519 index 0
>  debug1: ssh_packet_send2_wrapped: resetting send seqnr 995525
>  debug1: ssh_set_newkeys: rekeying out, input 32943120 bytes 3626116 blocks, output 1077718012 bytes 134216627 blocks
> debug1: rekey out after 134217728 blocks
> "
> 
> followed by many
> 
> "dequeue packet: 93"
> 
> and occasionally a
> 
> "debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: ssh_packet_read_poll2: resetting read seqnr 982769
> debug1: SSH2_MSG_NEWKEYS received
> debug1: ssh_set_newkeys: rekeying in, input 32943132 bytes 3626117 blocks, output 1077732080 bytes 1443 blocks
> debug1: rekey in after 134217728 blocks
> "
> And then the cycle starts again.
> On the client side it looks similar but there are less messages and no "datagram length" messages.
> Could you maybe explain what is going on in general regarding the channel/windows stuff?
> Is there anything I can do or is this only a ssh problem? It seems to happen only under load/lots of traffic?

So each SSH channel (e.g. tun connection, terminal, command execution, sftp
session, etc) has a window count of how many bytes the remote end is willing
to accept. As the local side sends data, this window shrinks. As the remote
side consumes data (i.e. writes it out to its destination), it will send
window adjust messages that grows the window, permitting it to send more
data.

This is done to prevent a client from sending more data than a server
is prepared to deal with. OpenSSH uses a 2MB window by default.

At the SSH level alone, it's possible your client is sending data faster
than the server can effectively process it. This will lead to queuing in
the client and ultimately traffic being dropped.

Another complication happens if the traffic over the tunnel is TCP. TCP
implements its own windowing (which is more sophisticated than SSH's)
and it's possible for the two to "fight" [1] leading to more performance
problems.

OpenSSH's tun forwarding is pretty basic and naive - it doesn't implement
any proactive traffic control and it will do tail drop rather than head
drop, which can further hurt effective throughput. Of course, it's possible
there are actual bugs in there too.

Generally, I'd recommend using a VPN that is designed for the purpose.
tun forwarding is handy in a pinch but it simply doesn't compare in
reliability and throughput with OpenVPN, Wireguard, etc.

-d

[1] https://web.archive.org/web/20230228035749/https://sites.inka.de/~W1011/devel/tcp-tcp.html