Logic of Management behind NAT in R82

[akurtasanov]

Good day.

I have the following lab setup:

lab_sms — Internal: 172.21.56.2/24, Static NAT behind lab_gw1 to 192.168.1.252
lab_gw1 — Internal: 172.21.56.1/24 (Internal loopback MGMT: 10.255.255.254/32), External: 192.168.1.254
lab_gw2 — Internal: 172.21.56.3/24 (Internal loopback MGMT: 10.255.255.252/32), External: 192.168.1.250

When the option “Use the remote server's original / translated IP address based on the topology” is selected (this is also the default setting on the SMS NAT; I am explicitly mentioning it here so that it corresponds to the screenshot), lab_gw2 starts sending logs through its External interface.

Why does this happen? According to the setting description, the behavior should depend on the topology, while 172.21.56.0/24 is an Internal network.

When switching to “Use only the original IP address for the remote servers”, everything starts working correctly.

If we switch the setting back, the traffic immediately starts going through the External interface again.

In the screenshot, the blue highlight shows the exact moment when the log traffic changes from 172.21.56.3 to 192.168.1.250. So this does not appear to be related to already established sessions.

Could you please explain in more detail the logic used to select the source/translated IP address and the interface through which the log traffic is sent?

[PhoneBoy]

Is the traffic actually working when it's translated in this manner?

[akurtasanov]

Yes.
Fully restarted lab. Same behaviour.

[emmap]

When the NAT is configured it assumes you want to use it, I guess. I believe with that setting it will try the NAT IP first, if it works it will use it. If the NAT IP does not connect, it tries the original IP. 

[akurtasanov]

Will test. But initially, I assumed the logic would be the reverse, since management traffic uses the correct IP.

[akurtasanov]

Disabled External Interface, reinstalled policy with default option. No connection.

[emmap]

The screenshot shows the TCP connection established to the real IP there, what's showing a failure? 

[akurtasanov]

The connection highlighted in blue is the connection established under the old policy, before the External link was disabled.

The remaining connections are tests to verify whether a new connection is established after installing the policy with the default option and disabling the External link.

As you can see, the log connection was not established.

So, despite the fact that direct access to the SMS is available, the gateway for some reason does not establish the connection over the Internal path.

This is the main question: why does the gateway behave this way?

[emmap]

What's configured in the NAT settings on the SMS object?

[emmap]

Then I'm sorry but I don't know why it's behaving that way and I don't have the time to lab it up and investigate. TAC is probably the way forward here.