1. SSH login to the outside interface of the standby firewall (FW2) failed because the forward and return paths were inconsistent and the ACK packet was not retransmitted by the SSH client. As a result, the three-way handshake was not completed and the SYN session expired.
2. Telnet login succeeded when the forward and return paths were inconsistent because the Telnet client sent a Telnet data (Push+ACK) after sending the ACK packet and the Telnet data packet was retransmitted. When the SYN+ACK session state on the standby firewall (FW2) was synchronized to the active firewall (FW1) by the aging thread, the retransmitted Telnet data packet sent to FWs completed the three-way handshake and the TCP connection was established.
3. In the test, Telnet login does not always succeed and SSH login does not always fail. It depends on the implementation of the client. The result varies with the client, such as SecureCRT, XShell, and PuTTY. Therefore, the problem must be analyzed based on the actual environment.
1. The best solution is not to manage the standby firewall via the active firewall. If you need to manage the standby firewall from a public network, log in to the outside interface of the firewall. If you need to manage the standby firewall from a private network, log in to the inside interface of the firewall.
2. If you must manage the standby firewall via the active firewall, enable quick session backup.
[USG] hrp mirror session enable