source hash outbound NAT - permanent association between private and public IPv4 - several individual IPs
-
Hello and thank you for the information. But I would like to ensure that the address for "Translation", i.e. the address used externally, is always permanently assigned, depending on the internal address. For example, if suitable traffic comes from internally to the outside, 10.0.0.1 should always be translated a.b.c.66 and 10.0.0.2 should always be translated a.b.c.67, as is possible with entire networks with "source hash". Just with individual addresses instead of an entire network of external IPv4. I don't want to influence which internal address is translated into which external address. However, it should be ensured that the same one is always used. This is intended to prevent problems for clients that can arise from “roaming IPs”.
-
@voglcloud that’s the manual Outbound NAT rule on the link above.
-
@voglcloud ok maybe I misunderstood what you were asking.. But per the link @SteveITS linked too your hash option is there
https://docs.netgate.com/pfsense/en/latest/nat/outbound.html#working-with-manual-outbound-nat-rules
Source Hash
Uses a hash of the source address to determine the translation address, ensuring that the translated address is always the same for a given source IP address
-
Okay, but then what should you enter in the “Address” field in the Translation section? I can either enter entire networks or just a single /32 address here. But not several /32 addresses or only some of the addresses of the /29 network. If I enter an alias with several individual addresses or only a part of the addresses of the /29 network, I get an error message: Notices --> Filter Reload: "There were error(s) loading the rules: /tmp/rules.debug:93: tables are only supported in round-robin redirection pools - The line in question reads [93]: nat on $WAN inet from any to !$IPv4_RFC1918 -> $IPv4_Alias port 1024:65535 source-hash 0xf8f09" [...]
-
@voglcloud said in source hash outbound NAT - permanent association between private and public IPv4 - several individual IPs:
But not several /32 addresses or only some of the addresses of the /29 network
Thought you stated
"I don't want to influence which internal address is translated into which external address. "
So if you don't want to control which external IP is used for IP X, what should say address Y use for nat? Something specific?
So why would you not just put your network in there for the source? I am confused what your wanting to do exactly... If you have a bunch of public IPs you want to nat your clients behind pfsense too, and you don't care what external IP some internal address gets natted, you just want to make sure it doesn't change for that client.. Then is not the source hash the option you want?
edit:
but not the entire network (from the hosting provider):
Network: a.b.c.64/29huh? your .64/29 the addresses you listed is that whole /29
-
I would like to ensure that NAT can be used in such a way that not just a single address is used as a translation adress. all 5 adresses from the example above (at top) have to be used. From a.b.c.66 to a.b.c.70. The whole thing is supposed to work in such a way that the internal clients always get the same address externally.
@johnpoz said in source hash outbound NAT - permanent association between private and public IPv4 - several individual IPs:
So if you don't want to control which external IP is used for IP X, what should say address Y use for nat? Something specific?
I would like to use several individual addresses (from a.b.c.66 to a.b.c.70). Unfortunately I can't use the whole network because the address a.b.c.64 is the network address, a.b.c.65 is the gateway of my hosting provider and a.b.c.71 is the broadcast address of the network.
Here is a screenshot of what I need as an example:
Can you understand? Please excuse the confusion and my bad English. I am very grateful for your quick help!
-
@voglcloud said in source hash outbound NAT - permanent association between private and public IPv4 - several individual IPs:
what should you enter in the “Address” field in the Translation section
Create an alias under Firewall/Aliases, with the .66, .67, .68, .69, .70. Name it OutboundNATIPs or whatever you want:
In the Outbound NAT rule, for Address choose "network or alias" and for Address enter OutboundNATIPs:
-
Thanks for the reply!
If I enter it as alias , I get an error message: Notices --> Filter Reload: "There were error(s) loading the rules: /tmp/rules.debug:93: tables are only supported in round-robin redirection pools - The line in question reads [93]: nat on $WAN inet from any to !$IPv4_RFC1918 -> $IPv4_Alias port 1024:65535 source-hash 0xf8f09" [...]
Do you get this error too?
-
@voglcloud said in source hash outbound NAT - permanent association between private and public IPv4 - several individual IPs:
Unfortunately I can't use the whole network because the address a.b.c.64 is the network address, a.b.c.65 is the gateway of my hosting provider and a.b.c.71 is the broadcast address of the network.
And how would that be any different than every other network on the planet? Ah I see the problem, this selection is not as smart as I thought it was..
I would of thought that if you had 1.2.3.64/29 and your using .66 as pfsense address and then .67,68,69 and 70 as your vips.. And you put 1.2.3.64./29 I assume it could only nat to address it has actually assigned/usable.. Ie its own address the .66 and then the vips..How would it use addresses that it doesn't have to nat too?
But I just tested this, and yeah its a pretty useless feature unless you have a larger amount of space and want to use cidr to carve out specific IP ranges to use for the outbound nat with a cidr - which would include the wire and broadcast address of the cidr.
when one address tried to use it worked, and used .67, but then changed the source address and it tried to nat to .64 - that could prob be worded a bit different in the docs, but looked at the original doc for pf, and its not very clear there either.
Ok so that method is pretty useless for your needs then..
But as you said you don't care what external IP a device uses right - you just want it to be sticky.. Why not just use the round robin - sticky option. Then you can use alias that only has the IPs you want to use in it..
Sticky Address: The Sticky Address option can be used with the Random and Round Robin pool types to ensure that a particular source address is always mapped to the same translation address.
That should work, but if you were talking to 8.8.8.8 client might use say .67, but when talking to 9.9.9.9 it might use .68 as your external. But that shouldn't be a problem..
In the enterprise we just use sticky, I don't recall ever setting something like source hash.. So client x might use public IP A for conversation with 8.8.8.8 but could use public IP B when talking to 9.9.9.9 I don't recall ever having an issue with stuff not working for any client..
If the client later attempts to talk ot 8.8.8.8 again it might use public IP C.. But whenever talking to some vendor site or something that might lock down which IP can talk to it, we always just give our full public IP space, because it could be any of those at any given time.. be it client A talking or client B talking to it, or at different times of the day via different sessions, etc.. client X might use any of the IPs, but in a specific session the IP would be sticky.
I don't recall ever coming across where this has ever been a problem.. During a specific session sure, that is why you use the sticky option.
edit: if you don't care if you use them all.. You could setup to use 2 /31s .66/31 and .68/31 - where half your network uses .66/31 and the other half uses .68/31 sort of thing.. you would loose the .70 But you could assign other IPs of your network to use that address.
But think either roundrobin or random sticky with your IPs should work..
-
Thank you for your feedback, @johnpoz!
@johnpoz said in source hash outbound NAT - permanent association between private and public IPv4 - several individual IPs:
Ok so that method is pretty useless for your needs then..
Where can I submit feature requests for pfSense and what is the best way to do it? It would be great if this could actually work in the future.
So, for now, do I have no choice but to use the Round-Robin option 'Sticky'? Initially, this sounded okay to me, especially after your feedback and explanation.
@johnpoz said in source hash outbound NAT - permanent association between private and public IPv4 - several individual IPs:
I don't recall ever coming across where this has ever been a problem.. During a specific session sure, that is why you use the sticky option.
However, I've tested this for myself... Problems occur with certain applications like online games that "don't communicate often enough", and a more specific application that "binds connections to IP addresses" (e. g. UDP, stateless, and not always transmitting). Additionally, some websites (not tested) bind the session to the client's IP address after login, which could also cause issues after idle time.
Best regards and thanks again for the quick and excellent help!
-
@voglcloud well then do it the way I said from the get go tie portion of your network to each IP.
Not a lot of online games played in the enterprise ;)
While udp is considered stateless - your stateful firewall does keep a state..
here is another option.. How many users do you have that you need to nat traffic for.. Why not just 1 of your IPs. Just because you have 5 IPs doesn't mean you have to use them all for your outbound traffic that you nat. you could just nat all your clients behind pfsense to say the .70 address problem solved.
You could put in a feature request on pfsense redmine, but pretty sure the limitation with the cidr is freebsd/pf thing - not some code pfsense could just edit up easy.
-
@voglcloud feature requests and bug reports are at redmine.pfSense.org.
-
@johnpoz & @SteveITS , thanks for the further feedback and the address for feature requests.
I think I'll try using a single IP address for outbound NAT for some time. With currently only around 40-50 users, that should be enough for now.
Thank you again for the quick and good help and the many considerations and approaches!
