Possbile Bug - Outbound NAT using subnet/hash giving out broadcast address
-
So I believe this is a bug and as suggested by pfsense guidelines we would need to confirm it before filling out a bug report.
I have a /24 subnet of public IP's, using Outbound NAT and source hash with subnet, I get many internal client IP's(1000+ internal clients) with no internet, after checking the clients IP in the states of pfsense I can see that their outgoing comms show the public IP broadcast address ..*.255.
As a test I have since shortened the subnet to a /26 starting at IP 128, the last public IP that should be issued out via the NAT should be 190, with broadcast IP being 191, however those same internal client IP's that were previously affected now receive public IP's ending in 191, so of course they are now working, but firstly 191 should not have been issued out by pfsense as this is the broadcast address for the subnet I entered.
Is there anyone else using a similar setup on version 2.4.3? Can anyone else test this with their config and see if they have the same affliction?
I'm at least working around the issue by shortening my subnet of public IP's, main goal here is to verify with other if this is indeed a bug so we can raise a report.
-
It's working fully as intended there, the problem is you can't use a subnet with NAT that way when the subnet is actually used for anything other than NAT. By that I mean it can't be a subnet that's used on an interface, it has to be an entire subnet that is routed to your firewall, not the WAN subnet itself.
If that /24 is on your WAN subnet for example you'd also potentially be using your gateway address and firewall's own address for NAT, which is also not good. If you're using it that way it probably also means you're using an improper VIP setup as well (e.g. proxy ARP VIP that could be causing a conflict with the gateway, firewall WAN, or anything else in that /24).
The way pf works, it either takes a full routed subnet there for NAT, or you can use an alias with lists of addresses. When you give it a full subnet it can do things like bitmask, random, source-hash mapping, or round-robin. If you use an alias it can only do round-robin.
Say for example you have a /24 on your WAN, but choose to only use a portion of that, say a /28 picked from the middle, for NAT. Should it also exclude the first and last address of the defined subnet, even when they are perfectly valid addresses inside the larger network it lives inside?
If you only have a /29 on your WAN for example and then a /24 routed to your firewall's address in the /29, then if you only use that larger subnet for NAT and do not place it on an interface directly, then it also has no null route or broadcast address, it's a range of addresses you can use in its entirety.
Long story short: You can't use it the way you're trying to use it, and there is no way to make that setup work overloading it on top of an interface network. If you make an alias containing the full valid range of addresses, then you can't use source hash, only round-robin. You can map the users to a subsection of the network and still use source-hash, but you can't make use of the entire usable portion network that way.
-
Thanks, ok that does make sense. I need to use source hash so I guess I'll just use a portion of the subnet.
Would be nice if we could use source hash with alias. Sticky round robin just doesnt do it for us.Thanks for clearing that up!
