NAT and Proxy Arp and Interface Addresses - help understanding

[TonyDeHart]

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.

[TomYoung]

Hi @TonyDeHart ,

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

Thanks,

Tom

[TonyDeHart]

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.

[TomYoung]

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

[TonyDeHart]

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.

[TonyDeHart]

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.

[TomYoung]

Hi @TonyDeHart ,

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

Thanks,

Tom

[DDecker]

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.

[TonyDeHart]

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.

[DDecker]

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.

[TonyDeHart · Accepted solution]

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.

[TomYoung]

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