NAT on ClusterXL in HA mode

[Olga_Kuts]

Are there any nuances for configuring Static NAT on a cluster?
We configure the Automatic Static NAT on the single gateway - everything works fine (we natted internal source address X to external source address Y). After that we change address Y to address Z - everything works, NAT works correctly (NAT: address X to address Z).
When we configured the same NAT on a cluster in HA mode (NAT: X to Y), firstly all works. We change adresses in NAT rule (NAT: address X to address Z), but the address X still natted to the address Y.

Can you help me with this question?

[Timothy_Hall]

Clustered vs. non-clustered shouldn't matter for NAT configuration unless possibly you have NAT templates (fwaccel stat) enabled.

NAT determination is made at the start of the connection (receipt of the TCP SYN packet) right after an Accept action by the Firewall/Network policy layer, and cannot change for the life of that connection, even if the NAT configuration is changed and policy installed.  This can be particularly vexing for continuous pings that are started, left running, then have the relevant NAT configuration changed.  Once the NAT has been changed, a ping running between the same source and destination IPs must be stopped for at least 30 seconds (ICMP virtual session timeout) for that virtual connection to "let go" of the previously determined NAT address and apply a new one.  Obviously pinging a different destination IP for which there is no virtual ICMP connection will cause the new NAT setup to be applied immediately.

Bottom line is make sure that a new connection is really starting to properly apply the new NAT, web browsers in particular can be very bad about this with speculative downloading and persistent connections.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Vladimir]

Please check your NAT policy on ClusterXL.

There may be a manual rule in there that looks something like: Source (Y) to Destination(???), Original, Original.

If it supercedes the automatic (or manual) rule you are trying to enforce, you'll get the result you are looking at.

Also, check the log for the NEW session you expect to get translated and see what Nat rule is being applied.

[Olga_Kuts]

The situation has cleared up a bit:
We tested NAT with a ping: pinged some resource, changed source address for NAT, applied policies (Connection Persistence: Re-match connections) and watched the result.
Ping shows an ambiguous result, I can not explain why it uses old addresses for NAT even after policies installing. TCP sessions established correctly and with correct NAT address.

[Timothy_Hall]

Hi Olga,

Did you stop the test ping for at least 30 seconds (or alternatively ping a different destination address) as I mentioned above so the virtual ICMP connection can time out and apply the new NAT?

Also keep in mind that ICMP traffic is never accelerated by SecureXL and always goes F2F, while TCP-oriented connections can potentially be accelerated.  That may also explain some of what you are seeing.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com