Multiple IP addresses on Host Override with health detection?
-
Trying to find a solution, where clients can have a single IP address or FQDN on pfSense to access a pool of servers. Using these options within the custom options of DNS Forwarder provides all the IP addresses and even rotates between them with each DNS request:
localise-queries host-record=host,host.domain.com,192.168.1.1 host-record=host,host.domain.com,192.168.1.2
The problem is when one of the servers goes down, then clients will be sent to a failing IP address half of the time. So wondering how a health check could be done on the ip addresses?
Services->LoadBalacing (relayd) seemed to provide this exact function (although through NAT), but this was depricated in version 2.5.0.
HAProxy is referenced as an option, but the client's IP address cannot be passed through to the server when the clients and servers reside on the same subnet (thus not using pfSense as a gateway/router).
What other options exist?
-
@321liftoff said in Multiple IP addresses on Host Override with health detection?:
HAProxy is referenced as an option, but the client's IP address cannot be passed through to the server when the clients and servers reside on the same subnet (thus not using pfSense as a gateway/router).
What do you mean by that? If you create a FQDN that points to pfSense' IP on the LAN there's no problem with that. Just create a hostname like
proxy.domain.com
in your DNS or via the DNS Resolver/Forwarder Host Override and use HAproxy in TCP mode if it's not a HTTP/S service you are proxying. UDP also won't work of course. But if it's TCP you're looking at - HAproxy and TCP mode can do exactly that.Cheers
-
@jegr Per the documentation when configuring the backend services of HAproxy, it has the following:
So a couple of limitations when using Transparent ClientIP
- the client cannot be on the same pfSense network interface as the backend server
- the client cannot be on the same subnet as the backend server
Are these constraints not true?
-
@321liftoff Yes they are but why would you need to use transparent ClientIP? That wasn't mentioned anywhere in your question, that's why I'm wondering. Does your service actually need the source IP of the client to work?
Cheers