NAT driver drops inbound retransmits that happen after FIN

[Elliott]

In TCP, it is possible and allowed (and actually, necessary) for the sending side to retransmit after sending the FIN but before receiving a FIN from the other side. The sending side will send a final "window" of TCP segments, ending with a FIN packet. If one of those is dropped, the receiving side should ACK the most recently received packet, then the sender will retransmit. Only after all packets are received and acknowledged should the recipient ACK the sender's FIN segment and send back its own.

Instead, guests within virtualbox seem to immediately respond to the FIN with a FIN/ACK and tear down the connection. This means that if a segment is dropped within the final window transmission, the download is silently truncated. It's likely a rare bug, in that it only becomes high-probability with a combination of high latency, large window sizes, and nontrivial amounts of packet loss. With almost all TCP schedule algorithms, even small amounts of packet loss result in a very small transmission window. The new BBR, on the other hand, tries to probe the latency and bandwidth available rather than relying on packet loss for feedback, so it's far more likely to result in a large TCP window despite some packet loss.

[Valery Ushakov]

What is your host OS?

Do you have packet traces (host and guest sides)?

Note that "NAT" is not really a NAT. The remote sending side is actually talking to the host OS socket. May be "NAT" is not draining the socket correctly after it gets HUP from poll(2)... In this case the guest will probably see the tail of the data chopped off.