Static Bi-directional Source NAT not working on incoming traffic

Showing results for 
Show  only  | Search instead for 
Did you mean: 
Please sign in to see details of an important advisory in our Customer Advisories area.

Static Bi-directional Source NAT not working on incoming traffic

L2 Linker

I've users on subnet A that needs to communicate to a service over a vpn on subnet B.

This subnet B already knows a subnet A, and therefore we're doing a source NAT for subnet A to C.

A server in subnet B needs to print to a printer in subnet A, thus we made the NAT bi-directional.

However when trying to print from B to C, traffic gets dropped at the firewall. (We would expect C to be translated to B.)

Subnet A lives in Zone A, but traffic from B to C goes to zone untrust.

I added Zone untrust to the bi-directional NAT, but the reverse NAT is still not happening.

I also have both IP's for B and C in the inbound security rule for B and only destination zone A. (Zone untrust should not be needed as this is after NAT zone determination.)

(For confidentiality reasons I cannot show actual config data.)

(Traffic from A to B is working.)


Has anyone come across this issue?


L6 Presenter

This sounds like U tyrn NAT please follow the articles as without a picture it is hard to imagine the traffic path :




Also sometimes destination U turn nat is needed:






If you are still blocked by the security policy or you need to check if you are matching the correct nat policy or a global counter follow the article below to discover the issue:

Cyber Elite
Cyber Elite

@CHKlomp I must say... it is very difficult to assist (for me at least) without putting in some bogus information, beside generic subnet type info.


Here is my interpretation of what I understood.

Traffic from A to B goes across a VPN, and therefore, it would not require a NAT rule at all.

Now, I got confused at your next statement, when you say you are doing a Source NAT for subnet C.

Ok, what I got from this, is now "When A needs to talk to B, then SNAT to C, and keep the original destination of B"

Sure, I guess if you need to do that...

But now I am confused, because if A knows B, and B knows A... why would be need to even include a subnet C?  That is where I start to need to understand the need/requirement to do this.  Something that was working OK (i guess) is now being broken.  But again, sometimes a little detail can help us to determine if this is the best solution, or maybe there is an alternative way... i digress....


Then you state that Subnet A is Zone A (you could have some test-zone or something... but again, whatever.  :P)

Here is where I believe the issue lies.... A is in Zone A and C is ALSO in Zone A.  It should not need to hit your internet zone.

At least, I cannot make a reason.


What I see is this:

When traffic from (VPN Zone) SrcB needs to talk to (remote zoneA) SrcC, then DNAT to original SrcA address

granted this is a DNAT rule... so let's try bi directional now.


When traffic from ZoneA (SrcA) talks to VPN Zone (DestB),  then SNAT SrcAtoSrcC and enable bidirectional on it.


In my mind, there is no Untrust coming into play. Why would the network think to get to C I need to through the Internet?  To do this, is to create (potentially) an async session.  (Sure, let's have the 3 way handshake go from Internet to A, then from A across the VPN (which different zone) and then have return back, come across the Internet?)  Bad juju in my book.  😛


There should a routing table entry at RemoteB knowing, that to send traffic to C, it needs to go across the VPN.  That routing statement will be in their remote FW.


Perhaps, if you can provide some additional detail (i.e) a scrubbed traffic log, showing the SrcNAT column and DNAT column) that would be great.   I ask for this, because you can export your logs to CSV and scrub them, and then you can remove columns not needed (we would need to see SrcZone, SrcIP, DstZone, DstIP, SrcNAT IP, DestNAT IP, NAT Applied.   That is it.... Scrub it, change the SrcA to be 192.168.x.x (leave the last 2 octects), Make DstIP a 10.0.x.x (again, leave last 2 octect) and make the NATSrcofC be a 172.16.x.x (leaving last 2 octects).


Now we should be able see from 192.168. to 10.0., translate to 172.16. with BiDir enabled.


Then, with your logs, we can watch/see when 10.0 (from VPN) should be hitting (ZoneA)172.16 to DNAT to 192.168.


Put this log file as an attachment and we can see what is going on.


Help the community: Like helpful comments and mark solutions

Thanks for your time Steve,

This is a new connection. Network B already has a routing to a network A for another customer.
Therefore we need to source NAT A to C, as C is new to B and therefore can be routed back over the VPN tunnel.
However as network C does not really exists in the environment traffic originating from B to C is not flowing back to A as it goes into the untrust zone in stead of zone A.
Though my source NAT rule was setup bi-directional, I had to setup a reverse destination NAT for traffic from B to C NATed to A, to get this all to work. It kind of defeats the purpose of making a rule bi-directional.


Here is the traffic log before and after the destination NAT rule (B to A):

TypeThreat/Content TypeGenerate TimeSource addressDestination addressNAT Source IPNAT Destination IPRuleSource ZoneDestination ZoneInbound Interface
TRAFFICend25-10-2021 12:13B.122.99C.77.24B.122.99A.10.24VPN from 3rdPartyvpnAtunnel.6
TRAFFICdrop22-10-2021 15:30B.122.99C.77.144  VPN from 3rdParty Blockvpnuntrusttunnel.6


Security Rules

NameSource Zonesource AddressDest ZoneDest AddressAction
VPN from 3rdPartyvpnB.122.96/28zoneAA.10.0/24 C.77.0/24Allow
VPN from 3rdParty BlockvpnB.122.96/28anyanyBlock



NAT Rules

NameOrg.Source ZoneOrgDest ZoneOrg.Source AddressOrg.Dest AddressOrg.ServiceSource TranslationDest Translation
B to AvpnuntrustB.122.96/28C.77.0/24any address A.10.0/24
A to BzoneA untrustvpnA.10.0/24B.122.96/28anystatic-ip C.77/24 bi-directional

L0 Member

Please read this URL, it explains the reason.


You have mentioned - "However as network C does not really exists in the environment", so on the firewall which does the source NAT from A to C, it doesn't have a route entry for subnet C.


The Palo Alto firewall uses its routing table to decided the destination zone of a connection.


When the inbound traffic hits the firewall, the traffic to subnet C will only match the default route.

The default route will point to your zone "untrust".


The inbound traffic to subnet C will then be classified as "destination zone - untrust" in your case.


So your inbound traffic will become -


Source Zone: vpn

Destination Zone: untrust 




In the URL I have provided, please check the part "2.Destination NAT".

In your case, the Destination NAT rule created by "Bi-Directional NAT rule is -


Source-Zone: ANY

Destination-Zone: vpn



The reason is clear now, as destination-zone doesn't match, the inbound traffic will NOT be D-NATed.


The simplest way to resolve your issue is to add a static route for subnet C and point it to zone "vpn", it will resolve the issue.

After adding the static route for subnet C, your inbound traffic will match this route, so the destination zone will become "vpn".


In this way the issue will be resolved.





  • 4 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!