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

Reply
Highlighted
L1 Bithead

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

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. 

 

 


Accepted Solutions
Highlighted
L1 Bithead

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

View solution in original post


All Replies
Highlighted
L5 Sessionator

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.

Highlighted
L7 Applicator

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

Tom Piens - PANgurus.com
Like my answer? check out my book! amazon.com/dp/1789956374
Highlighted
L1 Bithead

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

View solution in original post

Highlighted
L3 Networker

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.

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 Live Community as a whole!

The Live Community thanks you for your participation!