Unexpected proxy ARP from NAT policy

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Unexpected proxy ARP from NAT policy

L3 Networker

Hi there,


I had an interesting go round with PAN support involving proxy ARP and source NAT.   Background: I don’t use the PAN for public ingress/egress traffic, for me it is for internal DMZs only.  As such, I’ve not had the opportunity to utilize the NAT policy features. Things do change however and now I’m at a place where I plan on using the PAN for egress (to public Internet) traffic. I must say I was caught off guard by a “feature” when it comes to the source IP address used in a NAT.


My test scenario was simple, all my wifi networks sit behind the PAN, and so I just setup a Policy Based Forwarding (PBF) rule to match my test client. The next hop is the default gateway for the public VLAN. Let’s say the public IP address space is and the gateway is Then the PBF set the next hop to   So far, so good.


The PAN needs an interface in the public VLAN, so I setup an interface using a 24 bit mask on the address object (ie called " pub VLAN"). I setup a NAT policy that referenced that address. Here is an example of the NAT policy:


"Test NAT" {

     source-translation {

       dynamic-ip-and-port {

         translated-address " pub VLAN";



     to Public-zone;

     from Wifi-zone;

     source any;

     destiNATion any;

     service any;

     description "NAT policy for test wifi client";

     disabled no;




Now it gets messy.   I started seeing ARP conflicts in the logs of the neighbor devices, and on the PAN itself. The PAN was proxy ARPing for any ARP requests in that VLAN.   Not good.


After a couple of late nights with PAN support, it was realized that if the translated-address is an IP/Mask, the device will proxy ARP for all IPs that match the subnet mask. In other words, the NAT address is interpreted as a subnet and the device will ARP for anything in (not just which was my expected behavior). There are two solutions:


  1. Make sure the translated-address refers to a 32 bit address entity ( for instance)
  2. Change it to an interface-address

How would it work in my ideal world? Well, if the intent is to allow NAT-ing over a subnet, then the argument should be checked to see if it is indeed a subnet. In other words, is a valid subnet and in this context would allow a large NAT pool to be used. However, is NOT a valid subnet and should have been rejected by the commit (or the GUI).


I’m sure I am in the minority here, I expect most PAN users are placing the PAN at egress points from the beginning, but if you are like me, watch out when you introduce your PAN to external VLANs and use NATs, it might create production issues when ARP breaks!






L4 Transporter

With an IP address object with /24 as netmask you basically tell the firewall to use the whole IP range for the source NAT operation as a pool of IP addresses. This is the same as for destination NAT. There you also need to limit it to a /32 netmask if you only want a single IP address to be used for destination NAT.

Hi Anon,


Yes, what you assert is true and is a good paraphrase of what I stated in my post.


My point is that if an attribute is supposed to be a subnet, then only valid subnets should be accepted.  By accepting an IP/Mask, the meaning of the configuration is occluded and less deterministic (looking).  Since the outcome is disastrous for the vlan that is natted, it should be vetted in a way that minimises mistakes.


It would be easy for PAN to check for valid subnets in this context during the commit / config validate processes.




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!