Network Load Balancer for multiple Subnet IPs

You can use just about any common load balancer. The incoming requests for your services need to be directed to the load balancer instead of to your servers and the load balancer needs to be able to reach the backend servers.

The load balancer will source nat (snat) the incoming packets, that is it will substitute the source address with its own address, before passing them on to one of your servers.

So the backend servers will reply to the load balancer instead of to the original client. For the response packets the load balancer will again do address substitution, this time substituting the target adress with the original client address.

To let the backend server service gain knowledge of the original client address, the load balancer is often, but not always, configured to inject this address as an application field which can be interpreted and/or logged by the backend service. For http this may for example be a http header such as x-forwarded-for or x-client-ip or similar.

The load balancer can be configured with several backend servers for each service, and they can be placed on different subnets as long as the server application requirements permit this. The load balancer is commonly indifferent as to where the backends are, as long as they are reachable.

You could try this by configuring haproxy, nginx or apache httpd, or just about any of the other open source and commercial load balancers on the market.

Caveat: There are load balancers which use a somewhat different approach, such as Microsoft Windows NLB. NLB is commonly installed on the actual backend servers to integrate the load balancing with the backend. This creates a requirement that the backend servers usually need to be on the same subnet for the NLB intra-cluster communication to work. NLB can also be combined with IIS ARR to provide a more ordinary load balancing frontend (such as found with other load balancers), at which the backend nodes may be placed on different subnets.