RSH connections fail when Destination NAT is configured for the RSH server

Product: Security Gateways
Version: R81.20, R82, R82.10
Last Modified: 2026-07-23

Symptoms

• The rsh command fails when Destination NAT (DNAT) is configured for the RSH server.

Note: The command works correctly when DNAT is removed.

• The client successfully establishes the initial TCP control connection (TCP/514) to the server. However, the secondary reverse TCP connection (server → client) does not complete.

• Packet captures show that the Cleanup rule drops the server-to-client TCP SYN packet.

• The reverse connection is not recognized as part of the existing session.

• The client may display an error similar to:

rsh: Didn't receive NULL byte from server: Connection reset by peer

Cause

The RSH protocol uses two TCP connections:

• Primary control connection: Client → Server (TCP/514)
• Secondary reverse connection: Server → Client (client-side high port)

The Security Gateway uses an RSH protocol handler to dynamically create an anticipation entry, allowing the reverse connection as part of Stateful Inspection.

When Destination NAT is configured for the RSH server:

• The protocol handler creates the anticipation entry using the pre-NAT server IP address.
• After DNAT translation is applied, the reverse connection parameters no longer match the stored anticipation entry.
• The Security Gateway treats the reverse connection as a new session.
• If no explicit Access Control rule matches this traffic, it reaches the Cleanup rule and is dropped.

Solution

We're here for you

NOTE

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.