NAT: public IP pool to internal segment
-
I was wondering if pfsense was capable of doing the following or something similar to it.
Lets say I have a public IP range of 64.251.XX.1 - 14 /28
And a internet network of 192.168.0.0 - 255 / 24 with 70 hosts on the network.
When an internal host requests a service beyond pfsense, it will automatically pick a public IP (between 64.251.XX.1 - 14 /28) and NAT it to that host. Once that host is no longer communicating beyond the pfsense it will unbind the NAT translation.
Once all the public IP's are assigned to a internal host, it can then use the WAN IP of pfsense or reuse the existing public IP range.
If you need any more information feel free to let me know, Thanks!
-
NAT pools are doable with pf, but not supported in the GUI currently.
Here is an old post with some more info: http://forum.pfsense.org/index.php/topic,8929.0.html -
Not configurable via the GUI' is shorthand for 'totally unsupported and will break the next time the filter is reloaded'. I haven't tried this, but a fairly standard AON rule would look something like this:
nat on vr1 inet from 192.168.1.0/24 to any -> (vr1) round-robin
You should be able to use something like:
nat on vr1 inet from 192.168.1.0/24 to any -> { 10.20.30.10, 10.20.30.15 }
This http://www.openbsd.org/faq/pf/pools.html suggests round-robin might be problematic and that something like this might be better:
nat on vr1 inet from 192.168.1.0/24 to any -> 10.20.30.12/30 source-hash
For experimentation, one could copy out the ruleset, modify and reload.
Again, I haven't actually tried this, so YMMV.So it would be something like
nat on vr1 inet from 64.251.XX.0/28 to any -> 192.168.0.0/24 source-hash
then copy over the ruleset, and reload?
-
You've reversed the internal and external subnets.
IIRC, the syntax should be something like:
nat on vr1 inet from 192.168.1.0/24 to any -> 64.251.xx.0/28 source-hash
BUT, that would use all the ips in what I would assume is your WAN subnet. You probably want something more like:
nat on vr1 inet from 192.168.1.0/24 to any -> 64.251.xx.8/29 source-hash
This would use 64.251.xx.8,9,10,11,12,13,14,15 as outbound IPs. You would need all those defined as VIPs on your firewall. Substitute your actual WAN interface (fxp1, em2, whatever) for vr1 and your LAN subnet for 192.168.1.0 (unless your WAN is vr1 and your LAN is on 192.168.1.0, obviously)
Keep in mind doing this could break your network, and reloading the filter in the GUI will overwrite your changes. With that said, I would test something like this:
Get into a shell, copy rules.debug to rules.test (or something)
Edit rules.test and change the nat line.
pfctl -f /tmp/rules.test
Observe what happens. Report back. -
Unfortunately I can't try this right now, I'm still in the planning stages of setting up a LAN gaming center and trying to find the best product / setup that will work for it.
I would like to have 1:1 NAT to all hosts, but the amount of public IP's is costly, next best thing is having a NAT pool.
One last question, once all the outbound IP's are used (64.251.xx.8,9,10,11,12,13,14,15/29), will it just assigned another host to an already used outbound IP? will both hosts still work?
-
As far as I understand, pf is always doing PAT vs Basic NAT. In Cisco-speak it does overload unless you use the static-port options. Round-robin goes through sequentially, source-hash generates a randomized hash and always uses that to map addresses. The hash only changes when you re-load the ruleset. Eg- machines will be randomly mapped to the various publics and will continue to use them until the filter is reloaded. Source-hash avoids the problem with round-robin of having the source address change. That could cause problems with secure websites. It is also mentioned that you could use sticky-address on the round robin pool to avoid this.
-
As far as I understand, pf is always doing PAT vs Basic NAT. In Cisco-speak it does overload unless you use the static-port options. Round-robin goes through sequentially, source-hash generates a randomized hash and always uses that to map addresses. The hash only changes when you re-load the ruleset. Eg- machines will be randomly mapped to the various publics and will continue to use them until the filter is reloaded. Source-hash avoids the problem with round-robin of having the source address change. That could cause problems with secure websites. It is also mentioned that you could use sticky-address on the round robin pool to avoid this.
So using source-hash, NAT will be served to the 70 hosts. Each host would get a random public IP from the pool, IP's would be reused from the pool until a reload.
Since its doing PAT, would there be a port issue if two computers connect to the same game that had the same public IP? Would pfsense know to route to the correct host? or would there be a conflict due to the IP/PORTS over lapping with PAT
-
It randomizes the source-port, so there would be no problem with overlapping connections. If you needed static-port, then you would probably have trouble with multiple connections to the same server. I'm not a big gamer- you might want to check out the gaming section. There's a sticky about static ports.
