- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
10-22-2021 01:39 PM
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?
10-23-2021 12:23 AM - edited 10-23-2021 02:48 AM
This sounds like U tyrn NAT please follow the articles as without a picture it is hard to imagine the traffic path :
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClXECA0
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClEiCAK
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cln3CAC
Also sometimes destination U turn nat is needed:
https://www.insecurewi.re/palo-alto-destination-u-turn-nat/
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:
10-23-2021 04:51 AM
@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.
10-27-2021 10:51 AM
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):
Type | Threat/Content Type | Generate Time | Source address | Destination address | NAT Source IP | NAT Destination IP | Rule | Source Zone | Destination Zone | Inbound Interface |
TRAFFIC | end | 25-10-2021 12:13 | B.122.99 | C.77.24 | B.122.99 | A.10.24 | VPN from 3rdParty | vpn | A | tunnel.6 |
TRAFFIC | drop | 22-10-2021 15:30 | B.122.99 | C.77.144 | VPN from 3rdParty Block | vpn | untrust | tunnel.6 |
Security Rules
Name | Source Zone | source Address | Dest Zone | Dest Address | Action |
VPN from 3rdParty | vpn | B.122.96/28 | zoneA | A.10.0/24 C.77.0/24 | Allow |
VPN from 3rdParty Block | vpn | B.122.96/28 | any | any | Block |
NAT Rules
Name | Org.Source Zone | OrgDest Zone | Org.Source Address | Org.Dest Address | Org.Service | Source Translation | Dest Translation |
B to A | vpn | untrust | B.122.96/28 | C.77.0/24 | any | address A.10.0/24 | |
A to B | zoneA untrust | vpn | A.10.0/24 | B.122.96/28 | any | static-ip C.77/24 bi-directional |
02-03-2022 03:37 AM
Please read this URL, it explains the reason.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClWBCA0
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.
Thanks.
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!