Using 2 public addresses to hide a single internal IP and get replied from the correct one
-
@johnpoz said in Using 2 public addresses to hide a single internal IP and get replied from the correct one:
so I will get around 50000 requests from different IPs per second
Yes, you're absolutly right. It didn't realize, that he is really having such high load and may exhausting the state table.
However, with enough memory and cpu power, increasing the state table size and shortening the state timeouts it may be doable. -
Regarding the "states" for the public IP, I can modify the associated rule with the port forwarding and choose "State type" as "none", and that would solve it, no?
-
Hmmm?
https://docs.netgate.com/pfsense/en/latest/firewall/configure.html
-
@johnpoz Yes, that, plus also not keeping it in the outbound, no?. And how to configure UDP state expiration?
-
Well if you don't keep any states for the rule - it shoudn't matter.. But in the advanced section of the rule you can set the timeout option for states.. Also would need to be done on a outbound rule that matches.
I am not 100% sure if that would also pertain to what pf does for udp tracking - I would assume so..
-
@johnpoz So the Floating rule for the Outbound, should be something like:
Direction: In. State type: none
So traffic going into the LAN from the internal load balancer, intended to get towards the wan to the outside world... no? Or I'm getting it wrong?
-
@johnpoz Also, any idea why it still creates states even if I have the port forward rule set to "state type: none"? See:
(DELETED TO AVOID SHOWING PUBLIC IP)
-
I just assumed that none would do that - but with udp they are not actually states.. They are just tracking. So its possible those settings do not apply??
https://www.openbsd.org/faq/pf/filter.html
Keeping State for UDP
One will sometimes hear it said that "one cannot create state with UDP, as UDP is a stateless protocol!" While it is true that a UDP communication session does not have any concept of state (an explicit start and stop of communications), this does not have any impact on PF's ability to create state for a UDP session. In the case of protocols without "start" and "end" packets, PF simply keeps track of how long it has been since a matching packet has gone through. If the timeout is reached, the state is cleared. The timeout values can be set in the options section of the pf.conf file.edit: Looks like your public IP is exposed in your state table. Are you ok with that? If not I would edit your image to obfuscate your public IP. If you need help with that just, just ask.
Are those maybe old, from before you set the none in the rule?
-
@johnpoz I just deleted the image.
So I did a Reset states several times, and states are created no matter what. I don't understand how to avoid that.
-
Not sure if possible with udp.. And have never tried it with tcp either.. It is listed as an option, but not sure on the details of that option.
We can call in maybe @Derelict he would have better understanding here of these options. I would think ;)
