Unexpected proxy ARP from NAT policy

[msullivan]

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

[Anon1]

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.

[msullivan]

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