NAT and Proxy Arp and Interface Addresses - help understanding

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

NAT and Proxy Arp and Interface Addresses - help understanding

L4 Transporter

I'm having trouble understanding why some recently added NAT rules did NOT Proxy ARP on our outside ISP interface as I expected it to.

 

I'd setup some NAT rules both using a bidirectional outbound rule NAT'd to an outside interface address (new one, not the existing one that was assigned) and an incoming only NAT rule mapping a new outside address to an internal one.  In both cases, neither worked until I added the IP Address used in the NAT rule to the Interface that had that subnet assigned to it.

 

My expectation was that since the subnet was mapped to the interface, the firewall would know what interface that address belonged to and Proxy ARP that address on that interface.  Instead, I needed to add that address as a /32 on the outside interface.

 

If Proxy ARP is a feature (which it appears it is), why is it necessary to actually assign the interface the address explicitly?

 

What I have now is our Ethernet interface with a boatload of IP's assigned which just seems odd based on my previous experience with other firewalls.

 

Is there a better more recognized way to do this on the Palo Alto Firewalls?

 

(Most of this came about due to a recent migration from an ASA so its been a somewhat accelerated learning experience.)

 

Thanks in advance for the help. The forums here have been invaluable and I appreciate those that are able to assist.

1 accepted solution

Accepted Solutions

I just ran a test and specified the interface in a bi-directional rule and it worked properly without adding the IP address to the outside interface.

 

I basically just added a bidirectional rule for my workstation mapped to the test IP in NAT and setup an allow ping rule from outside to my workstation.  Once I pushed it ping worked properly.

 

Help to know that was definitely the issue previously for me.  I feel a bit better about it now knowing.

View solution in original post

11 REPLIES 11

Cyber Elite
Cyber Elite

Hi @TonyDeHart ,

 

Are the NATed IP addresses in the same subnet as the original IP address on your outside interface?

 

Thanks,

 

Tom

Help the community: Like helpful comments and mark solutions.

L4 Transporter

Yes, they were.  We had three subnets on our IP networks outside interface that I believe were /28's and even though there were IP's assigned with the /28 subnet designated, I had to individually add every NAT'd address with a /32 to the network interface before NAT would work.

Cyber Elite
Cyber Elite

Hi @TonyDeHart ,

 

I have done NAT many times for IP addresses in the same subnet as the outside interface, and I never had to add the /32 IP to the interface.  You should not have to do that.  That is either a bug or double check your subnet masks.

 

If you are NATing to an IP address that is not in the subnet of the IP on the outside interface, you will need to add a route on the NGFW.  In your case, you have done step 2 of this doc ->  https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClGZCA0.

 

Thanks,

 

Tom

Help the community: Like helpful comments and mark solutions.

L4 Transporter

What is interesting is step 2 of that document says:

 

Create a secondary IP address on the network of this new destination NAT IP or the IP itself.
Example: If 70.1.1.1/24 is on Ethernet1/3 (Untrust), and destination NAT needs to be configured for 70.1.2.22, add either the IP address 70.1.2.22/32, or an IP in the network (70.1.2.1/24 for example) as a secondary IP on the Untrust interface.
This will tell the firewall that this network exists on this firewall, and it will know how to route traffic properly.

 

That was what I thought should have worked as we had the subnet's interface configured but nothing alongside it worked in the same subnet without defining the address.  Unfortunately it isn't something easy to test in a live config so I'm sort of stuck with it at this point until I can get another testing window to troubleshoot more fully.  We had a small window for our ASA to PA migration and we were banging our heads against a wall until we added those addresses.

 

I appreciate the confirmation that at least it wasn't a misunderstanding and simply something that should have worked but wasn't.  I'm on 10.1.9-h1 too and I've not seen anything bug related like this in the release notes.  I've not opened a ticket with palo about it though either.

L4 Transporter

Just as a follow-up to this, I did end up having a brief conversation with an engineer at Palo. While it SHOULD have worked, the suggestion was to add the interface to the NAT destination along with the Zone.  It is possible with only the Zone the firewall is not determining properly what subnet/interface needs the proxy ARP.  When I have time I may setup a set of test rules to experiment with.

Cyber Elite
Cyber Elite

Hi @TonyDeHart ,

 

That makes sense!  Please let me know if that works.

 

Thanks,

 

Tom

Help the community: Like helpful comments and mark solutions.

Did you have a chance to try it out? I'm getting the same result. I did specify the destination interface like you mentioned and it works but thats after it was already working when i had specified the IP manually on the wan interface. Very odd behavior. Support is working on it.

L4 Transporter

Unfortunately I have not had a chance to test this but I'll see if I can carve out some time.  I've been in the midst of several decomm's of old(er) devices and have had to concentrate my time on that and other duties but I'm just as curious to see if it works or not.

 

What version of PAN-OS are you running?  I'm in 10.1.9h1.

All good. I know how that is. I was running 11.0.0, then just recently upgraded to 11.0.1 incase it was a bug but no change.

I just ran a test and specified the interface in a bi-directional rule and it worked properly without adding the IP address to the outside interface.

 

I basically just added a bidirectional rule for my workstation mapped to the test IP in NAT and setup an allow ping rule from outside to my workstation.  Once I pushed it ping worked properly.

 

Help to know that was definitely the issue previously for me.  I feel a bit better about it now knowing.

Cyber Elite
Cyber Elite

Hi @TonyDeHart ,

 

Good to know that the NGFW may not proxy ARP for the IP if the interface is not specified in the NAT statement.  Please mark your last post as the solution in case someone else has the same issue and is looking for a fix!

 

Thanks,

 

Tom

Help the community: Like helpful comments and mark solutions.
  • 1 accepted solution
  • 3823 Views
  • 11 replies
  • 0 Likes
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!