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 192.168.1.1/24 connected to a router 192.168.1.10/24. The outside interface is 22.214.171.124/24 connected to a router 126.96.36.199/24 with loopback0 188.8.131.52/32 on it. I'd like to achieve the connection from 184.108.40.206 to 192.168.1.10 with the DNAT (outside_ip ---> 192.168.1.10) on PA.
The configured NAT policy is from outside to outside, destination IP outside_ip translated to destination IP 192.168.1.1 (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 220.127.116.11, everything works well. On 18.104.22.168 router, ping 22.214.171.124 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, 126.96.36.199, on 188.8.131.52 router, ping 184.108.40.206 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 220.127.116.11 router, there's ip route 18.104.22.168 255.255.255.255 22.214.171.124
Could anyone please shed some light on it? It has been driving me crazy.
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.
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 192.168.1.10 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 126.96.36.199 router, there's ip route 188.8.131.52 255.255.255.255 184.108.40.206"
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 220.127.116.11, it searches its routing table to match 18.104.22.168 first, which must point at the outside interface (no next-hop IP is needed). In other words, there must be a static route: destination 22.214.171.124/32, 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 126.96.36.199/32? It'll be translated into 192.168.1.10 anyway right? Just don't get the mechanism.
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!