1

https://www.cloudshark.org/captures/6f185eb12e97

  • 172.30.5.1 Linux vm with bridged networking, running on another server, VM has RFC1918 address only
  • 144.76.103.194 Linux host with one interface, connected to both internet and RFC1918 broadcast domain, acts as NAT gateway for VMs
  • 86.59.21.20 Linux HTTP Server

TCP stream on port 29909 encounters a RST from 144.76.103.194 after a delayed, already retransmitted, segment arrives from 86.59.21.20.

  • Frame #581 - Retransmit for sequence 522729 is initiated
  • Frame #615 - Sequence 522729 has been retransmitted
  • Frame #1727 - Original sequence 522729 arrives, ~600ms delayed
  • Frame #1728 - NAT host sends a RST back to the HTTP server

Connections initiated directly from the NAT host work fine.

Michael Renner
  • 1,750
  • 13
  • 17

1 Answers1

3

This seems to be related to the Linux conntrack code being unhappy about the "long" delayed segment, aborting the connection because of unexpected data.

The behavior can be mitigated by setting netfilter/nf_conntrack_tcp_be_liberal to 1.

Kernel documentation: https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt

Michael Renner
  • 1,750
  • 13
  • 17