[lvs-users] FTP data port connection not closing?

Owain Jones Owain at 4ColourDigital.com
Wed Aug 30 13:50:40 BST 2017

On 29/08/2017 19:53, Julian Anastasov wrote:
> 	Hello,
> On Tue, 29 Aug 2017, Owain Jones wrote:
>> Hi,
>> The packets seem to be dying at the router. As I can see the packets being
>> received on the director and the response packets being sent from the real
>> server.
>> One thing I'm thinking of, that I failed to mention earlier, is that the
>> router does NAT. I've placed the VIP in the DMZ, so the director should be
>> receiving all external packets directly. But the actual machines themselves
>> are in the router's LAN and being NAT'ed.
>> As I'm using LVS-DR, then the only thing that should be being changed in the
>> incoming packet is the MAC address, yes? But then, when the real server
>> responds, it'll have a different MAC address to the incoming packet because
>> it's actually a physically different machine.
>> So my thought is, could this MAC address mismatch be possibly confusing the
>> router's NATting?
> 	The MAC usually does not play. You can also check the state
> of conntrack entries in router, if possible.
Not possible, I'm afraid.

The router is an ISP-provided thing which doesn't provide access to that 
sort of thing.

> But to be sure that it
> is not the router, you can start client connection from some box
> on the LAN, then the real server will talk directly with this
> client box.
The FTP server is configured to report the external IP address.

But if I change that to the internal IP address and connect to it from a 
client box within the LAN, then everything works perfectly. No issues. 
So the FTP server itself works.

And using tcpdump to watch the packets, things are failing when the real 
server is trying to communicate back to the client, to ACK the 
half-close and close the connection (and, behaviourally, that fits 
because data is being sent to the server, it's just that the connection 
is not closing - so, eventually, it times out and sometimes a few bytes 
are missing at the end of the file, but I'm thinking that's just caching 
and if the connection did close then it would write back the whole lot 
on receipt of EOF, it's only shortened because I'm having to abort the 
connection manually).

>> I guess I could test it by rewriting the MAC address on outgoing packets from
>> the real server to have the MAC of the director, so that, from the router's
>> perspective, the LVS is entirely transparent.
> 	Almost, Linux 4.10+ decrements the IP TTL field for all
> forwarding methods including DR.
>> Though surely, that said, the source MAC address on outgoing packets shouldn't
>> really matter, I'd have thought.
> 	Yep
Yeah, I thought that the source MAC address really ought to do nothing. 
But the only reason I'm thinking of this is because things start failing 
when the real server is passing its response to the client's FIN packet 
on the passive port.

The router "owns" the LAN, by the way, and is providing the NAT. So my 
thought was that, though I can't access it, it's got connection tracking 
and maybe, as the source MAC coming out of the real server is different 
to the dest MAC that came in on the VIP, that the router's conntrack is 
not recognising the response as being connected to the request. 
Confusing it.

But that's just a guess. I honestly wish I had some clue why this was 


More information about the lvs-users mailing list