The rdr-to in the FAQ is distinctly different from your initial test in one key way: the rdr-to and nat-to are both on the same interface. This is used on an internal network as part of a redirection/reflection solution.
I think what your seeing is related to this restriction discussion in the Redirection and Reflection section of the FAQ, where I've highlighted:
Quote:
|
Adding a second redirection rule for the internal interface does not have the desired effect either. When the local client connects to the external address of the firewall, the initial packet of the TCP handshake reaches the firewall through the internal interface. The redirection rule does apply and the destination address gets replaced with that of the internal server. The packet gets forwarded back through the internal interface and reaches the internal server. But the source address has not been translated, and still contains the local client's address, so the server sends its replies directly to the client. The firewall never sees the reply and has no chance to properly reverse the translation. The client receives a reply from a source it never expected and drops it. The TCP handshake then fails and no connection can be established.
|
If you outline what the operational problem is that you're trying to solve, perhaps an alternative solution can be devised.