About 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:   Make sure the translated-address refers to a 32 bit address entity (1.2.3.4/32 for instance) 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   ... View more