Virtual IP Proxy ARP Network will use invalid IPs for Pool
-
I had a lot of users complain they couldn't get to the internet. Seemed random and temporary, and by the time we'd get out to visit in the field the issue was gone.
Digging into it, we found it was the outbound NAT trying to use reserved IP addresses and the interface gateway address as a source address .
For example, if your WAN interface is 64.233.160.2, your netmask a /25 and your gateway is .1, you 'd expect a VIP on that interface to avoid using the .0 (subnet ID) and the .1 (the gateway) as source addresses. You'd be wrong however and 1.5 % of your users will be blocked. When you have thousands of devices, that's a lot of unhappy people.
To demonstrate, create a Firewall -> Virtual IPs and click add. Set it to type Proxy Arp, the interface to WAN, and the address type of network. Enter your network and subnet (such as 64.233.160.0/25) and disable expansion.
Now go to your Firewall -> NAT -> Outbound and edit your mapping under Translation -> Address to the new subnet you cerated (such as Subnet: 64.233.160.0/25)
Lastly, check your state table and you'll see entries like 64.233.160.0 -> 8.8.8.8 with bytes send, but 0 bytes received.
If you'd setup your Firewall NAT Outbound with a pool option that users Sticky Addresses, you'll have users 'stuck' mapped to the .0 or .1 address. When that happens to the VP you have a difficult time explaining you don't know what's going on :-/
The only remedy we found was to create a series of Individual Virtual IPs of type alias, and then under Firewall -> Aliases add an alias entry and put the range of IPs we'd just crated there, then use that for the outbound NAT
-
That is working as designed.
Outbound NAT has no concept of the interface network and broadcast addresses.
It is just doing what it was told to do.
If it was not that way you would "waste" two addresses if you told outbound NAT to use something like 64.233.160.16/29 as an outbound NAT pool.
-
That's surprising, as you do tell it the netmask, and so the broadcast and network ID are known, the .255 and .0 in the case of a /24, for example.
Is there a way to remove non-routeable addresses from the proxy arp pool?
-
But it is not a broadcast network in all cases. It is just a CIDR/Subnet. In the scenario I described, 64.233.160.16 and 64.233.160.23 are perfectly valid Outbound NAT addresses when they are on a 64.223.160.0/25 interface.
About all that can be done there is to try to do some input validation in the web page since pf is what is handling the NAT there once told what subnet to use. Can only prevent so much foot-shooting especially in the more advanced areas like this.
I agree the behavior there might be unexpected in some cases but it is technically correct.
-
Ahh, so the proxy arp pool CIDR notation strictly defines the pool size and has nothing to do with netmask and routing.
In your example, there are 6 useable IPs,
64.233.160.17 - 64.233.160.22. However the pool will include all 8,. 16 and .23, because it's a pool defifition and not a netmaskThat is an important safety tip!
So how would one create a proxy arp pool that didn't include the two reserved address and the gateway address without cutting the pool in half by increasing the netmask?
-
This post is deleted! -
What's more of a mystery is how you use the feature effectively.
Maybe it's more effective when the wan gateway is on a different network and pf is routing a pool of VIPs to it. That way you dont have any conflicting IPs.
When the VIPs are on the same network as the gateway, you obviously need to exclude that address, and you may get (like I did) unexpected results with the bottom address and top address ( the .0 and .255, in the case of a /24 )
pf isn't my edge device so that may not be the most common use case.
-
That (now-deleted) reply was totally to the wrong thread. Sorry.
Well, right, you should not have a /25 on your WAN interface. You should have a much smaller subnet there and the /25 should be routed to you.
If that was the case, as strange as it sounds, .0 and .127 would be valid NAT addresses.
In order to use something other than round robin you must use type subnet.
If you can use round robin, just define a host alias using a range and NAT to that.
