Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got troubles configuring an Hardware load-Balancer with NAT functions.

I have the following architecture:

Internet ===> VIP (public) LB (private ip) ====> private addressed servers

When a connection is initialised from the outside (internet) , the LB correctly forwards the SYN packet to one of the private servers. But when these servers want to reply with a SYN/ACK there is a problem.

the initial SYN packet had as ip header : VIP => Private_server_Address

But the private servers cannot reach VIP from their side (this is normal since it's nated), and then provide a correct reply.

Have you guys any solution to correctly forward the packets to their correct destination ?

Note: The load balancer, which is the default gw for the servers, also has a NAT rule for "masquerading" (actually more SNAT than real masquerading)



share|improve this question

There are many ways to configure a load balancer, and you don't make it clear how you wanted your balancer to behave - or rather, you'r giving contradicting scenarios.

Based on the architecture that you outlined, your LB should be 'terminating' the TCP connection - then it would open a new TCP connection with your private server and send only the data across. This means that when connection reaches your private server, it should not be seeing the external VIP as the source address of the connection, but the loadbalancer's internal private IP. This contradicts what you described.

IIRC, in this mode (some vendors call it "proxy mode", different from "DSR mode"), there is no NAT required so the masquerading could be disabled.

So initially I would suggest that you confirm which source IP your private is seeing - it should not be the external VIP address I think.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.