While debugging other issues I have seen occasional reports of "Remote port forwarding failed..."  At least some of them appear to be incorrect because forwarding was actually working.

Investigation revealed a probable cause:  SSH2_MSG_GLOBAL_REQUEST packets are being used for 2 purposes.  They are used to request/cancel port forwarding AND they are used as "keep alive" messages.  Problem is, the server ( server_input_global_request() ) sets type to FAILURE for any packet other than "tcpip-forward" or "cancel-tcpip-forward".  Thus, "keep alive" requests are always set to FAILURE.  When received by the Client, it can not differentiate a "keep alive" response from a forwarding request response.  If timing is such that a keep alive was sent just prior to a forwarding request, the keep-alive response may be read by the forwarding code as a failure.

2 notes:
1) I have not been able to reproduce this and document the packet traffic.
2) It appears that the server is expecting one of [SSH2_MSG_CHANNEL_FAILURE, SSH2_MSG_REQUEST_SUCCESS, SSH2_MSG_REQUEST_FAILURE ] as a keep alive message BUT the client _appears_ to be sending SSH2_MSG_GLOBAL_REQUEST in order to trigger a [SSH2_MSG_REQUEST_FAILURE |SSH2_MSG_REQUEST_SUCCESS] response which the client wants as a keep-alive.  Combining this pattern with packet_read_poll_seqnr() resetting "keep_alive_timeouts" for every packet, regardless of type, suggests that the keep-alive hand-shaking scheme may be broken.