(Many to One Source NAT with Bi-directional ) Convert Cisco ASA FW NAT to Palo Alto FW NAT

[AceTeamSecurity]

Hi All, 

I have been trying to find an Palo Alto article for Many to One Source NAT with Bi-directional but cannot find the exact article. Most of it, just for Destination NAT. When I tried to understand the concept, it quite confusing. Below is the screenshot from Cisco ASA FW ASDM. When configure Cisco ASA FW, it is not that hard for this Many-to-One Source NAT since it just straight forward configuration.

10.1.25.0 is configured as 10.1.25.0/24

10.20.56.240 is configured as 10.20.56.240/28

For Palo Alto, I'm not quite sure it will reflect as it supposed. Can anyone help me on this? I'm not quite sure the bi-directional rule since from what I understand for destination translation (Dynamic-destination-translation is suitable just for fqdn) based on this article.  https://docs.paloaltonetworks.com/ngfw/networking/nat/destination-nat.

If I followed this article (https://docs.paloaltonetworks.com/ngfw/networking/nat/destination-nat-exampleone-to-many-mapping), I need to break down each of destination translation to each IP since 10.1.25.0 is configured as 10.1.25.0/24 and 10.20.56.240 is configured as 10.20.56.240/28. It will takes hundred of polices just to configure the reverse rule.

[BradleyStrider]

I think rules 46/47 aren't doing what you think, and you don't actually need them on the Palo.

On the ASA, when source PAT translates 10.1.25.0/24 and 10.20.56.240/28 behind 10.218.22.13, the firewall builds an entry in the xlate table for each active flow. That entry stores the original source, translated source, protocol, and ports. When return traffic arrives destined to 10.218.22.13, the ASA does a lookup against the xlate table — not against a NAT rule — to figure out which internal host the session belongs to. The "reverse" rule ASDM shows you for source PAT is essentially a display artifact; the actual un-translation is driven by session state.

Palo Alto works the same way conceptually. NAT policy is only evaluated on the first packet of a flow (c2s direction). Once the session is installed, the reverse mapping lives in the session table, and return traffic (s2c) is un-NATted based on that session entry — no second policy lookup, no need for a reverse NAT rule.

This is also why PAN-OS won't let you enable Bi-directional on dynamic-ip-and-port. Bi-directional only makes sense for static source NAT (1:1), where the inverse is deterministic and PAN can auto-generate an implicit destination NAT. With DIPP, the inverse isn't deterministic — if a new inbound session hits 10.218.22.13 with no existing session to reference, there's no way to know whether it should map back to a host in 10.1.25.0/24 or 10.20.56.240/28.

So the config collapses to just rule 45. Drop 46 and 47 — they're not the inverse of source PAT. They're attempting dynamic destination translation distributed across your original subnets, which is a different feature (load-balancer-style inbound distribution) and won't behave the way you want.

If you separately need inbound access to specific internal hosts via 10.218.22.13, that's a per-host/per-service destination NAT rule, not a translation of the source pool.