When a load balancer is deployed, a decision is made to place them in-line or in, what is referred to as, a one-armed or SNAT mode. In an in-line deployment, the load balancer is also the default gateway for backend servers or is in the way (inline) between the backend servers and the clients via the network topology.
The image below is a very basic overview of an inline load balancer:
The image below is a very basic overview of a one armed load balancer deployment, the main difference in these deployment models (in terms of NAT) is SNAT and DNAT are performed in step 2, the Source IP is replaced with the LB VIP and the Destination is replaced with the Server IP, this forces traffic to go back through the LB instead of directly from the server to the client:
The inline method leaves the user (origin) IP address intact, which allows the web servers to act on the origin and perform certain tasks (traffic analyse as an example). The draw back is that the ESG has to be in the path of the web servers, which makes the design less flexible. The one armed configuration has a few draw backs. The first being that the web server does not see the original user as the incoming IP address. To be fair, it is a widely used configuration and the user IP is not entirely lost as you can enabled an option called “Insert X-Forwarded-For HTTP Header” – which make the ESG send the user IP along in the HTTP headers, which the web server can use for analysis. Another draw back (or benefit, depending on how you look at it) is that you would need a dedicated ESG to do only load balancing. An existing ESG that is serving as the default gateway of your web virtual machines cannot be configured in this mode.