Using 2 public addresses to hide a single internal IP and get replied from the correct one
-
@viragomann I see it going out of the internal machine but I don't receive it on the client.
-
Ok fixed, just had to add a 1:1 NAT
-
But now, how I make it work with TWO public IP addresses? It works with one but if I add additional public IPs in 1:1 NAT rules then only the first one will work.
-
@adrianx
You cannot use 1:1 NAT with two public addresses and a single internal. 1:1 means 1 public to 1 internal.Use port forwaring instead.
Did you already add the second public IP to the WAN interface?
-
@viragomann Yes, I have the 2 public Ips added, let's say:
85.1.1.2
85.1.2.3I do port forwarding from :7777 to :7777 to a machine in the network that has a load balancer. The load balancer then sends the request transparently (keeping source IP + source port) to a set of servers that reply directly to the client.
So this works great and I get the reply correctly for 1 IP, but not for 2 IPs. The problem is that for the backend servers to be able to reply directly to the client, I added a 1:1 NAT of public IP 85.1.1.2 to each of the backend servers. And hence answers from that public IP work.
But now in order to be able to reply when asking the second IP 85.1.1.3, I added another 1:1 NAT to each of the backend servers with the second IP, so I have two 1:1 NATs per backend servers (the ones replying to the client directly). But that doesn't work, only first 1:1 NAT mapping in the list works.
How should I do it so that the reply gets translated to the original public IP that was used?
Thanks.
-
@adrianx said in Using 2 public addresses to hide a single internal IP and get replied from the correct one:
The load balancer then sends the request transparently (keeping source IP + source port) to a set of servers that reply directly to the client.
You mean, replies don't pass the load balancer?
If so, pfSense won't have states for these replies.How should I do it so that the reply gets translated to the original public IP that was used?
That is the default behavior. If you access IP1 from outside and pfSense forward the packets to an internal device, it transaltes the source IP in replies back to IP1 when the packets leave the WAN interface.
However, this is controlled by the state table. -
@viragomann Yes exactly, replies don't pass the load balancer, it's a Direct Server Reply (DSR).
It works with first public IP as I have the 1:1 NAT mappings in the servers replying to the client. And I have 4 servers that reply.
To make it work with the second IP, should I use a different set of servers to reply from the second public IP and do 1:1 NAT mappings on those? Consequently I would need a second load balancer for the second public IP port forwarding... right?
Would that be the correct way?
-
@adrianx said in Using 2 public addresses to hide a single internal IP and get replied from the correct one:
The problem is that for the backend servers to be able to reply directly to the client, I added a 1:1 NAT of public IP 85.1.1.2 to each of the backend servers.
You added a 1:1 NAT rule to the backends themeself or on pfSense?
-
@viragomann I mean on pfSense, see:
One for each backend. This is in Firewall / NAT / 1:1. Public IP is the 198.50. The 192.168.1.213 is the server were the traffic got forwarded from the load balancer.
-
Ok Im a bit confused here.. Lets forget 2 public IPs for a minute.. Either I need more coffee, or I am missing something
If you send traffic from say 1.2.3.4 hitting your wan IP to a load bal 192.168.1.213, and this sends on the traffic to what? Say 192.168.1.113
If .113 responds back directly to pfsense saying I want to go to 1.2.3.4 with a SA.. How would that work? Pfsense should not allow that traffic, because there is no state..
edit: your setting up 1:1 nat on pfsense to your bankend IPs, not the load balancer? Yeah I need more coffee ;)
-
@adrianx
So as I already mentioned, you cannot use 1:1 for that, since you have a single internal IP. There is also no need for 1:1.I think, it should work, but instead of the 1:1 NAT rules, add port forwarding rule.
So you can add forward rule for 85.1.1.2 to 192.168.1 and a second forwarding 85.1.2.3 to 192.168.1.The response from the backend is automatically retranslated into its origin destionation address, as already mentioned.
-
@johnpoz
https://www.haproxy.com/blog/layer-4-load-balancing-direct-server-return-mode/
I'm not familiar with that as well. But I think it should be able. -
That is ha proxy.. Did he mention he is running this through ha proxy? He is using that as a backend load bal, or on pfsense. If on pfsense why would he be setting up any port forwards or nats? Those are not used when you have ha proxy listening on wan and sending traffic.
Yeah I need more coffee ;)
-
Ok so here is the full picture, first a port forward from public IP port 7777 to load balancer (NGINX UDP Load Balancer, transparent mode = keep source IP + source port), see:
This is in Firewall / Nat / Port forward. The 192.168.1.211 is the NGINX load balancer. Then the load balancer forwards the traffic to one out of 4 backend servers, let's say that we only have 1 to simplify it, and that one is 192.168.1.213.
Then backend 192.168.1.213 gets the traffic as if it was coming directly from the client given the transparent mode from NGINX, and then replies to it, taking profit of this 1:1 NAT to translate it's IP to the public IP:
Makes sense? Let me know please. This works at the moment.
The problem is when using 2 public IPs.
-
@viragomann If I do only the port forwarding to the Load Balancer without the 1:1 to the backends, it doesn't work, and I don't get any replies from the backend servers (and they send the traffic, I checked). Neither with 1 nor 2 public IPs. But I may be missing something?
-
Huh.. Not sure how that would work.
Seems more like your 1:1 nat is just sending traffic to 213.. and 211 isn't getting anything?
I don't see how pfsense would allow traffic from 213, if there is no state.. If it sent traffic to 211, why would it allow return traffic from 213..
Can you show use the state table for the IPs in question.
This UDP traffic?
-
@johnpoz Huh I just checked and you are right, only the first packet goes to the load balancer, and the following ones go to the backend directly..... that's not what I wanted.
And yes it's UDP traffic.
Do you know how I could achieve this?
-
If I remove the 1:1 on the backend, everything goes into the Load balancer (correct), but the backend reply doesn't arrive to me (client).
-
So your goal is to send all traffic hitting your wan IP on port XYZ to nginx load balancer at .211.. which then sends this traffic to .213..
And you want 213 to return traffic direct back to pfsense. But pfsense to continue to send all traffic that hits its wan on to .211?
So asymmetrical traffic flow..
hmmmm - yeah going to need more coffee, if not beers... Off the top of my head, I don't really think such a setup is possible??
Once your return traffic is allowed from .213, not sure new traffic would even go to 211, because pfsense would keep track of the conversation.. Hmmmmm
-
@johnpoz I see so the reason I just receive the first packet in the load balancer and the next ones directly on the backends, it's because the state is already there and then NAT 1:1 is applied for my source IP? But for new IPs they will have to send also first a the first packet to the LB, right?
Could I then remove the option to keep the state and keep the 1:1 on the backend, and that should deliver everything to the load balancer even if I already queried it?
-
@adrianx said in Using 2 public addresses to hide a single internal IP and get replied from the correct one:
Could I then remove the option to keep the state and keep the 1:1 on the backend
Not sure sure such a thing is possible??
Why can you not just return traffic back to nginx? And let it send traffic back to source IP 1.2.3.4? That is normally how it would be setup.. And that would be just simple port forwards on pfsense.
-
@adrianx
So how does the server responed? Check with packet capture.
It should use the VIP as source address in respond packets. I suspect that is not the case. -
@johnpoz The reason is because I'm doing this to distribute the load of incoming UDP requests for a UDP flood attack with spoofed IPs, so I will get around 50000 requests from different IPs per second. This saturates the NGINX leaving it without ports to bind when communicating with the backends. That's why I want to delegate the reply to the backend. Do you see my point?
-
wouldn't you have the same problem with pfsense..
Confused how that would solve the problem?
-
@viragomann So with packet capture on the LAN, I see that the backend replies this:
15:32:57.557414 IP 192.168.1.213.7777 > Client.Public.IP.60428: UDP, length 15
So not using the Virtual IP. Is there a way to make it use the public IP?
-
@adrianx
So DSR is not configured correctly on the servers.From the linked site above:
the service VIP must be configured on a loopback interface on each backend and must not answer to ARP requests
-
^ exactly.
But I still don't see how that really solves a state exhaustion issue.. No matter how many IP you send to behind pfsense.. Pfsense is natting to its public IP, which has a limit of how many states it can have.
The way to solve state exhaustion issue would be to filter the traffic that is "bad" before a state is created..
-
I'd suppose, if the backend servers are configured correctly for DSR (responding using the VIP and not responding to ARP requests) the states will be fine.
However, I've never set up something like that. -
so I will get around 50000 requests from different IPs per second
He still have his public IP with states.. Doesn't matter how many IPs he sends to behind.. While sure the local boxes would have less states.. His public IP would still have the states.. at 50k a second that is going to burn through states like crazy..
I don't really see how doing something like this could solve a state exhaustion issue to be honest..
Well lets not really call them states if they are UDP... But pf tracks them like they were.. You can set an option in pf for how long these are tracked..
But yeah I believe using the VIP on these end boxes for the IP of the load balancer is how such a setup is to be done. To solve the asymmetrical flow problem.. Since pfsense will only send traffic to what it thinks is 1 IP.. And the return traffic to pfsense will be coming from that same IP. As far as pfsense knows, since its source would be the vip address.
-
@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 ;)