Unexpected proxy ARP from NAT policy

Announcements

ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.

Reply
Highlighted
L3 Networker

Unexpected proxy ARP from NAT policy

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 1.2.3.0/24 and the gateway is 1.2.3.254. Then the PBF set the next hop to 1.2.3.254.   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 1.2.3.4/24 called "1.2.3.4-24bit 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 "1.2.3.4-24bit 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 1.2.3.0/24 (not just 1.2.3.4 which was my expected behavior). There are two solutions:

 

  1. Make sure the translated-address refers to a 32 bit address entity (1.2.3.4/32 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, 1.2.3.0/24 is a valid subnet and in this context would allow a large NAT pool to be used. However, 1.2.3.4/24 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!

 

Cheers,

Mike

 

Highlighted
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.

Highlighted
L3 Networker

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.

 

Cheers,

Mike

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!