NAT issue - ISP interface IP different than public IP block assigned

[JBarbera-Medifast]

I'm currently working with PA support on this issue but I thought I would put this question out there for the community to see if anyone has had a similar problem.  We are in the process of migrating from Juniper SSG firewalls to the PA-500 and the issue we have is when we attempt to migrate our ISP connection to the PA, we are no longer able to reach any of the NAT IPs of public facing servers.  When we switch back to the Juniper, everything is reachable again.

Here is the scenario:

ISP has assigned us a /30 for the interface block so we have a 157.133.x.x/30 address.  The actual block of usable public IPs they assigned to is in a 65.210.x.x/28 range.  On the Juniper SSG, we assign MIP IPs (their term for NAT) under the interface configuration and then create an inbound rule for zone Untrust to DMZ.  This solution works fine and there is nothing else special we need to do. On the Palo side, we have the NAT configurations defined in the policies but neither inbound nor oubound static NATs will respond.  Is there anything special we need to configure on the PA-500 to make this solution work, i.e. gratuitous ARP, etc?  How does the firewall know to respond for NAT IPs that are not physically defined on any interface?

We have a 2nd ISP that I connected and tested but their entire block assigned to us is a /24 so both the interfaces and public IPs are within the same subnet.  This solution works fine since the Palo is able to respond to requests for those addresses.  It's just the setup above with the NAT subnet being complete different than the interface /30 that the ISP assigned to us that is giving us some fits.  Any suggestions or advice would be greatly appreciated. 

[VinceM]

Hi,

I was in the same situation couple of month ago. 1 ISP with two punlic IP subnet. But for me, everything was ok, as soon as you have nat rule define in your palo, it's supposed to work.

Are you sure your ISP router send traffic to the palo ?

Make a TCP dump on you external interface ?

Do you see grat ARP ?

Keep us in touch.

V.

[reaper]

The Palo Alto Networks firewall will send proxy arp out for IP addresses in the NAT policy

Did you make sure to clear the upstream ARP table and check if there aren't any static ARP entries on the router?

It shouldn't be necessary to do so (due to the proxy arp sent out), but you could try adding the public ip addresses to the interface as a secondary IP range, this will not interfere with any functionality, it may simply assist in attaching to an interface and getting the proxy arp out

-if an ip/subnet in a NAT rule is unassigned, the firewall will determine the 'appropriate' interface by looking up the routing table and finding the closest match which should be the 0.0.0.0/0 but there might be overlap

[JBarbera-Medifast · Accepted solution]

I found the solution was to run the "test arp" command below for each of the public-facing NAT IP addresses after we switched over the PA-500 firewall.  After the GARP was sent, I was immediately able to reach the public IP.   All is good now and the transition to PA has gone very smoothly so far.  Thanks everyone for their responses and help.

test arp gratuitous ip x.x.x.x/32 interface ethernet1/x

[RFalconer]

I ran into this a while ago also. When I called support, they provided me with an explanation and a fix.

I was told that due to the usable block of public addresses not being in the routing table, the traffic was dropped. This is due to the order of operations that specifies a forwarding lookup is done to make sure there is a destination available. This forward lookup is done before NAT is evaluated. If the forward lookup fails, it never gets to the NAT evaluation.

Support had me add a fake route for the public subnet so that it would pass this step and get to the NAT evaluation. I used the untrust interface and a next hop of 'none'. As soon as I did this, it started working fine. No need for any gratuitous ARP.

This was in version 6 so maybe it's changed in 7.