DNAT fails to work on PA-VM

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.

DNAT fails to work on PA-VM

L1 Bithead

Hi PA experts,

    I've been racking my brain to figure out the DNAT problem when doing the tests on PA-VM.

    It should be a very common scenario which is why I really don't get why the common DNAT doesn't work. 

    On PA, the inside interface is connected to a router The outside interface is connected to a router with loopback0 on it. I'd like to achieve the connection from to with the DNAT (outside_ip ---> on PA.

    The configured NAT policy is from outside to outside, destination IP outside_ip translated to destination IP (Static NAT).

    The firewall policy is from outside to inside, source IP any, destination IP outside_ip. Allow all service/application. 

    When the outside_ip is in the same subnet as the outside interface, eg, outside_ip is, everything works well. On router, ping source loopback0 is fine. PA works well regarding the DNAT and firewall policy. HOWEVER, when the outside_ip is not in the same subnet as outside interface, eg,, on router, ping source loopback0 fails. It doesn't make any sense. I can confirm the NAT rule and firewall policy are set correctly. And all the needed static routes are configured on all devices, eg, on router, there's ip route

    Could anyone please shed some light on it? It has been driving me crazy. 


Please note you are posting a public message where community members and experts can provide assistance. Sharing private information such as serial numbers or company information is not recommended.

Hi @RiceWu,

Let check if I get your problem correctly

- You want to use additional public IP/range for destination NAT and reach internal resource?

- By additional public IP/range I mean IP/range that is different from the network between your firewall (outside interface) and your ISP provider?


Although you didn't mentioned what security zone have you setup for the loopback I would assume you have put it in "outside" zone. If that is the case the both outside interface and loopback are in the same zone, your NAT ande security rules seems to be correctly configured. But please confirm the loopback zone?


(P.S. In my humble opinion if you plan to have these public IPs/range only for NAT, you don't really need to create loopback interfaces)


Another very possible cause of your problem is that your ISP is not actually routing the additional NAT range to you.

- When you create NAT rule using any IP in the same network between your outside interface and your ISP, firewall will automatically configure proxy ARP, which will cause the firewall to reply to any ARP request for the IP that is used in the NAT rule, even if this IP is not directly assigned on any interface on the firewall (physical or loopback). Now in this case when public users try to reach the NAT IP, your ISP will follow the route for the network that is assigned to your outside interface. When it reaches the ISP CPE, it will generate ARP request, to which your FW will responde and the CPE will forward the traffic to the FW.

- When you want to create NAT for public IP that is not part of your ouside network, your ISP is responsibe to create route on their CPE, which will point the additional public IP/range to your firewall public IP address.


From your explanation it sounds that your ISP doesn't route the IP that you want to use for the NAT to you. And without such NAT there is no way for the ISP CPE to know how to reach this NAT IP.


Hi Astardzhiev

    Thanks for your reply. This is a virtual platform, not the real production environment. The loopback I mentioned is on the ISP router which I used as the source IP address to access the internal through DNAT. All routing is there on each hop as I mentioned clearly in the post "I can confirm the NAT rule and firewall policy are set correctly. And all the needed static routes are configured on all devices, eg, on router, there's ip route"

    I seemed to have got the reason for the problem. PaloAlto does the routing table match before doing the DNAT. So when it receives the packet to, it searches its routing table to match first, which must point at the outside interface (no next-hop IP is needed). In other words, there must be a static route: destination, outgoing interface "outside", next-hop IP "None". It seems that Cisco does it too. I don't think it makes much sense though. For Fortinet, to achieve the DNAT, the routing table match will only occur "after" DNAT. Why on PaloAlto, there must be a routing entry for It'll be translated into anyway right? Just don't get the mechanism. 


  • 2 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!