10-29-2010 11:06 AM
Can you perform source AND destination address translation on a single packet? I know NAT rule processing is first rule match so more specifically, can I have a single NAT rule that defines a source and destination translation?
Absolutely - no problem.
10-29-2010 12:03 PM
Thank you for the quick response Kelly. Are there any plans to allows multi-NAT rule matching? I don't need it now but wondering if it in the plans?
10-29-2010 12:09 PM
It is not currently on the roadmap. Let us know if you have a particular use-case for the feature - we may be able to find a workaround or enter a feature request.
At this time all of the rule bases behave as top-down ordering and first match complete. One subtlety is the Security Rulebase, where the rulebase can be checked multiple times if the application changes mid-session, but it is still top-down ordering and first match complete.
08-08-2011 07:06 AM
I would like to followup on this back of this request.
I too have a requirement for a double NAT entry where by I wish to change the source and destination address of a particular traffic pattern.Here is the scenario.
I want to advertise a service that is routable using a private side/trusted ip address obtained from within subnet range of the private side interface of the firewall. For example;
The trusted side interface and zone of the firewall is;
L3-PRIV = 172.16.227.254/22
I then create a loopback address which is also assigned to the same zone using a subnet range as follows
L3-PRIV = 172.16.245.33/27
I have a network service that is reachable through a DMZ (untrusted interface) and then via a next hop router.
The remote network is routed via the virtual routing table used by both layer 3 interfaces.
I want clients that hit the destination address equal to loopback address of 172.16.245.33/27 to be translated using this soruce and also have the destiantion translated to a new destiantion address routable via my DMZ.
Origianl Packet SRC_ZONE=L3-PRIV - SRC_IP = 192.168.230.10/24 - NAT'd SRC_ZONE=L3-PRIV SRC_IP=172.16.245.33/27
Original Packet DST_ZONE=L3_PRIV - DST_IP = 172.16.245.33/27 - NAT'd DST_ZONE=L3-DMZ DST_IP=10.142.210.5/24
Does this make sense and is this possible?
The use case is that the destination network will only be aware of the loopback address subnet from a routing perspective, plus the clients on my internal network can reach the loopback address, but not the true destination hence the need for a destination NAT. Traffic will always be initiated from the trusted side.
08-15-2011 02:12 PM
Please read the KP article for U-Turn NAT. https://live.paloaltonetworks.com/docs/DOC-1678
It documents how to build two NAT rules for accessing the same public server.
Rule 1 - One to One nat for the outside world when they use the FQDN for access.
Rule 2 - Src and Dest nat when a user on trusted side tries to use the same FQDN URL to access the same server.
01-29-2023 08:34 PM
I would like to request to help investigate my issues, Currently I'm facing with DNAT policy issues. My design is pointing to DUAL Internet user can access to my DMZ network, My current policy and NAT translation is pointing to ISP1 and destination translation IP is 10.101.7.9 this policy working fine and that I can confirm with the hits count for this policy. The problem is when ISP1 down our outside user cannot access the DMZ network, So, I decide to create duplicate the old policy and pointing to ISP2 and destination translation IP also 10.101.7.9. This policy is doesn't work and cannot access from internet. Hits count also 0 for this policy. So, how can i solve the issues please kindly suggests my issues.
Thanks in Advance,
Pyie Phyo Htay.
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!