[lvs-users] lvs. Nat

Anders Henke anders.henke at 1und1.de
Wed Apr 30 12:56:21 BST 2014

There are multiple issues with this.
-IP-address changes
-possible port changes

The client initiates a connection from Client-IP A to Director-VIP B:

A->B, using a random source port number to destination port 80.

The director rewrites the IP packet as if it had been sent
from Client A to Realserver C and sends it to the realserver:
A->C, using the client's source port number to destination port 80.

If the realserver would reply to those director-NATed packet, 
the reply would look like this:

C->A, from port 80 to client's source port

The client in turn knows it did create a connection from A to B,
but doesn't know about a connection from A to C and so can't
match those reply packets with "the other" connection. Well,
their destination port is known to be in use with a different connection,
so why should A assume this to be valid?

The reply packets are being dropped as being invalid.

Depending on your configuration, your director may also change
the destination port, e.g. from 80 to 8080:
A->C, using the client's source port number to destination port 8080

... and so the realserver's reply would look like this:

C->A, from port 8080 to client's source port

The client in turn knows it did create a connection from A to B.
Any replies from C won't match that connection and so are being dropped.
Neither IP address nor port number do even closely match a known connection,
there's no way for the client to match them.

In both cases, any firewall protecting A will perform similar 
checks and drop the reply packets, as they are not related to a known 
outgoing connection.

By routing and "un-NAT'ing" the reply packet via the director, the 
director will rewrite the packet from 'C->A' to 'B->A' and rewrite 
any port changes as well to meet the expectations of A (or any 
firewall in between director and A).

In Direct Routing mode, the IP packet isn't changed at all, just
the ethernet destination MAC address ("outside" of the IP packet) 
is changed. In Tunneling mode, the incoming IP packet is encapsulated and
isn't changed as well.

That's why in Direct Routing and Tunneling mode, any replies will be sent
bypassing your director and your director will only see "incoming" packets.

And that's also the reason why in NAT mode, both incoming and outgoing 
bandwith are limited by the director, while in DR/TUN mode, the director
only limits the incoming bandwith. Beside this, the extra complexity of 
performing NAT for incoming and outgoing packets does also affect the 
overall performance of the director.



On 30.04.2014, net.study.sea at gmail.com wrote:
> The real server received packet's source ip is client ip , why not it reply directly to client if there is router available route?
> 在 2014-4-29,22:43,Anders Henke <anders.henke at 1und1.de> 写道:
> > On 29.04.2014, net.study.sea at gmail.com wrote:
> >> In nat mode,does director do dnat and snat packets for all request packets?
> > 
> > In NAT mode, the director does perform destination nat on request packets,
> > so your realserver does still see the correct "source" ip address.
> > 
> > However, replies then need to be sent via the director as well, so the 
> > director can reverse the changed destination IP address and the client
> > does see the reply packet from the "expected" IP address/port.
1&1 Internet AG              Expert Systems Architect (IT Operations)
Brauerstrasse 50             v://49.721.91374.0
D-76135 Karlsruhe            f://49.721.91374.225

Amtsgericht Montabaur HRB 6484
Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann, 
Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek, 
Jan Oetjen, Christian Würst
Aufsichtsratsvorsitzender: Michael Scheeren

More information about the lvs-users mailing list