Haproxy Nat
You set up haproxy nat by routing packets between public and private network addresses. The load balancer rewrites packet headers so private servers can talk to outside clients. Many teams use this setup to expose internal apps or databases. They often open broad network ports to make routing work right away. Broad network rules let any user on the subnet reach backend servers. How haproxy nat works in your network Network address translation changes the source or target IP address on network
HAProxy Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up haproxy nat by routing packets between public and private network addresses. The load balancer rewrites packet headers so private servers can talk to outside clients. Many teams use this setup to expose internal apps or databases. They often open broad network ports to make routing work right away. Broad network rules let any user on the subnet reach backend servers.
How haproxy nat works in your network
Network address translation changes the source or target IP address on network packets. In a standard setup, a client sends a request to a public IP. The load balancer sits at the edge of the private network. It takes the client packet and swaps the public target IP. It puts the private IP of a backend server in that spot.
Next, the load balancer also changes the source IP to its own private address. This step makes sure the backend server sends the reply back to the balancer. If the balancer kept the client source IP, the server would reply directly. That direct reply would fail or get dropped by the client firewall. Once the balancer gets the reply, it puts the public IP back in place.
Some teams need the backend server to see the real client IP address. For web traffic, the load balancer can add a special header with the IP. For raw TCP traffic, teams use a transparent mode in the kernel. Transparent mode lets the balancer spoof the client IP on the internal network. To make this work, the backend servers must use the balancer as their gateway.
Routing packets versus controlling user actions
A network translation setup solves the problem of reaching private servers from outside. It hides your internal IP layout from the public internet. It also lets you scale out backend servers behind one single public address. Your team can add or remove servers without changing DNS records for clients.
Still, network translation only works at the packet and port level. Once a packet passes the network rule, the balancer sends it right through. The balancer does not know which engineer or service sent the database query. It cannot check if a command inside an encrypted session will drop a table. It also cannot mask card numbers or emails in the data that comes back.
HAProxy Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing backend sessions with least privilege
Relying only on network rules often leads to shared logins and wide access. Engineers log in to the network and use a shared admin key for databases. When an error happens, the server logs only show the load balancer IP address. Even with transparent mode, the logs only show a machine IP, not a user.
To fix this gap, teams must separate network routing from user session control. Network rules should still block unknown traffic at the edge of your cloud. Inside the network, you need controls that inspect individual commands and queries in flight. Checking each request lets you block risky actions and mask sensitive fields in results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between source NAT and destination NAT in HAProxy?
Destination translation changes the target IP so traffic reaches a private backend server. Source translation changes the sender IP so the reply routes back through the balancer.
How do backend servers see the real client IP address?
For web apps, the balancer adds an HTTP header that holds the client IP. For TCP apps, teams use a proxy protocol header or kernel transparent mode.
Does network translation secure database queries from insiders?
No, network translation only moves packets between IP addresses and ports. It does not read database queries, check user identity, or mask emails in results.