DNAT fails to work on PA-VM

[RiceWu]

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 1.1.1.1/24 connected to a router 1.1.1.2/24 with loopback0 2.2.2.2/32 on it. I'd like to achieve the connection from 2.2.2.2 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 1.1.1.10, everything works well. On 1.1.1.2 router, ping 1.1.1.10 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, 4.4.4.4, on 1.1.1.2 router, ping 4.4.4.4 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 1.1.1.2 router, there's ip route 4.4.4.4 255.255.255.255 1.1.1.1

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

    Thanks!

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.

[aleksandar.astardzhiev]

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.

[RiceWu]

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 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 1.1.1.2 router, there's ip route 4.4.4.4 255.255.255.255 1.1.1.1"

    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 4.4.4.4, it searches its routing table to match 4.4.4.4 first, which must point at the outside interface (no next-hop IP is needed). In other words, there must be a static route: destination 4.4.4.4/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 4.4.4.4/32? It'll be translated into 192.168.1.10 anyway right? Just don't get the mechanism. 

    Thanks.