A utility engineer finds that outbound sessions from the field-crew subnet are being denied, even though a central SNAT policy exists that matches the subnet and specifies the correct overload pool. Reordering the central SNAT policy list makes no difference to the denies. What does this indicate about how central SNAT relates to the firewall policy's accept-or-deny decision?
Select an answer to reveal the explanation.
Short Explanation
Central SNAT doesn't get a vote on whether traffic is allowed at all — it only decides what address a session gets translated to once a firewall policy has already said yes. If sessions are being denied, the SNAT list was never even the thing standing in the way, so look at the firewall policy the traffic is supposed to match.
Full Explanation
Central SNAT policies exist purely to select and apply a translation, such as which IP pool a session's source address is rewritten to, and that selection only happens after a firewall policy has already evaluated the session and accepted it; central SNAT has no accept-or-deny authority of its own. This is why reordering the SNAT list changed nothing here: the block is happening at the firewall policy stage, before central SNAT is ever consulted, so no amount of SNAT rule reordering can touch it. The idea that central SNAT makes its own independent accept-or-deny decision reverses that relationship; if a session were being denied purely because of SNAT, no session would exist to reorder rules around in the first place, since the firewall policy decision comes first. Central SNAT ordering does not outrank firewall policy ordering for permission purposes, since permission is not something the central SNAT list decides at all, it is not a competing authority over accept-or-deny. A central SNAT match also cannot grant an implicit accept that overrides the matching firewall policy; the firewall policy's own action is what determines whether the session proceeds, and central SNAT is invoked only for sessions the policy has already permitted. A caveat: confirm the field-crew subnet's traffic actually matches an accept action in the intended firewall policy, checking source, destination, service, and schedule, since central SNAT configuration is unrelated to why a match there fails. Verify by reviewing the firewall policy hit count and log for that source subnet to see whether it is matching the intended accept policy at all.