Haproxy Nat Mode
You set up haproxy nat mode by routing traffic through the load balancer IP address. The load balancer rewrites packet headers so return traffic flows back through the same host. Teams often use this setup to hide internal server addresses from outside networks. Still, broad network rules can give one logged-in user access to every backend service. Once a session passes the network edge, wide roles let users run risky commands. How haproxy nat mode routes network traffic In a standard setup,
HAProxy Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up haproxy nat mode by routing traffic through the load balancer IP address. The load balancer rewrites packet headers so return traffic flows back through the same host. Teams often use this setup to hide internal server addresses from outside networks. Still, broad network rules can give one logged-in user access to every backend service. Once a session passes the network edge, wide roles let users run risky commands.
How haproxy nat mode routes network traffic
In a standard setup, a client sends a request to a public virtual IP address. The load balancer accepts the packet and changes the destination address to a backend server. At the same time, it rewrites the source IP address to its own internal address. This step makes sure the backend server sends its reply back to the load balancer. The load balancer then rewrites the address again and sends the reply to the client.
Some teams need the backend server to see the real client IP address instead. To do this, engineers set up transparent mode using kernel routing rules and packet marks. In that flow, the backend server must use the load balancer as its default route. If you skip that route, return packets bypass the load balancer and the client drops them. Standard source address translation avoids this routing change because the load balancer owns both sides.
Planning return routes and subnet layouts
Before you turn on address translation, you must check your subnet layout and port limits. Because the load balancer uses its own IP for backend sessions, high traffic can use up ports. Teams solve this by adding a pool of internal IP addresses for outbound backend sessions. You also need to check how backend apps read client identity from the network layer. Since translation hides the client IP, web apps often read client headers or socket headers.
For database and shell traffic, headers do not work in the same simple way. When an engineer connects through a translated route, the database sees the load balancer IP. Audit logs on the backend host record the load balancer address instead of the person. This makes incident review hard when many people share the same network path and role. You can fix network routing with translation, but user identity gets lost along the way.
HAProxy Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network translation solves and what it misses
Network translation is great for managing IP pools and keeping internal subnets private. It lets you add or remove backend servers without changing the public IP address. It also keeps return traffic tidy without changing default routes on every single backend host. For pure packet delivery and server uptime, this pattern works well across most cloud networks.
Still, network routing only decides which host receives a packet on a given port. It does not check which user is inside the session or what query they send. Once a database or shell session opens, the user has full power of that role. Translation cannot block a drop table command or rewrite emails and card numbers in results. Teams need controls that inspect commands in flight and tie actions to real user names.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why do backend logs show the load balancer IP in haproxy nat mode?
The load balancer replaces the client source IP so return packets come back to it. Because of this rewrite, the backend server only sees the internal load balancer address.
How is source NAT different from transparent mode?
Source NAT uses the load balancer IP for backend sessions and works on any subnet. Transparent mode keeps the real client IP, so backends must route replies through the load balancer.
Does NAT mode protect backend databases from bad queries?
No, NAT mode only routes packets between IP addresses and ports at the network layer. It cannot read database queries, block risky statements, or mask phone numbers in query results.