I host a few Eset Protect servers for clients, they work fine, each one on a separate VM. The clients for each VM report back on the same ports so I have multiple WAN IPs mapped in PFSense which allows forwarding of the same ports to different VMs.
The problem is IPv4 IPs cost money so im wondering if there is some way I can have all the clients reporting back to the same IP (via FQDN) and have PFSense and/or HAProxy handle forwarding the packets to the correct VM. For each VM I require ports 443,2222,2223.
I watched the HAProxy vid but it didn’t seem to match my use case. I also don’t need the SSL certs to be correct if that makes it easier. Happy to keep using the self signed certs on the VMs/Eset Protect.
Any advice appreciated.
I have not used Eset Protect and HAProxy as it’s name suggest proxies the port. This works fine for some traffic such as HTTP TCP 80 & HTTPS TCP 443 but does not work for all traffic but I do not know if that works for the type of traffic that Eset Protect uses.
If port 443 is used by a web server (which it should be), then that can be proxied by any HTTP reverse proxy (like HAProxy) to the upstream servers by hostname.
Other application-specific protocols cannot be proxied through an off-the-shelf reverse proxy because the proxy needs to know details of the application protocol (cf. this post). However this ESET help article claims that the ports for “Communication between ESET Management Agent and ESET PROTECT Server” (defaulting to 2222) and “DNS resolving and MQTT fallback” (defaulting to 2223) can be changed, so working off one IPv4 address seams workable to me.
If the traffic can’t be proxied, e. g. it is not native HTTP traffic, your best option is policy based routing. Most routers/firewalls can do that. It will allow you to create routes with if/then statements. For example, figure something like this:
if source ip = 10.10.10.1 then forward to 192.168.1.1
Policy based routing is sometimes called source based routing.
The one “caveat” with source-based routing is that the sender must have a fixed IP address. In the scenario described that does not look like a given to me.
Yes correct, connections could be coming in from any location on the planet.
Never mind, ill stick with multiple WAN IPs. Thanks everyone.