VirtualBox NAT implementation tcp keep-alive problem

[Aegis]

Guests behind VirtualBox NAT have problem using TCP keepalive. When connection with remote is lost (i.e. even host OS reports no connection), VirtualBox NAT implementation continues to reply to guest OS keepalive requests, hence guest cannot detect TCP connection loss.

Encountered on: Host OS: Windows 7 Professional 64 VirtualBox 4.3.10 Guest OS: Ubuntu 12.04 32

The same problem was reported by two users on the forum: ​https://forums.virtualbox.org/viewtopic.php?f=7&t=52384

[Valery Ushakov]

Yes, it's a known problem. Unfortunately it's very hard to fix properly. VirtualBox "NAT" is not really a NAT, more like automagic socks proxy. So the guest doesn't talk to its peer directly (modulo address translation), instead it talks to the TCP stack in the "NAT" engine, which uses host's sockets to talk to the peer.

Outbound keepalive might be possible to identify and emulate. Inbound keepalive - probably impossible since host's TCP stack handles it internally and doesn't notify the app.

NAT and NAT Network are really more of a convenience that don't require any setup. If you want real networking, you will have to use either bridged mode so that the guest talks to the network directly or use host-only and setup real NAT/routing/firewalling on the host.

[Aegis]

This reasoning is understood as well as the fact that there are some workarounds for the problem. In my case I'm interested in outbound keepalive, and it, however, doesn't appear to work. I observed the situation when host reported no connection to peer (connection loss was already detected by the host), however VirtualBox NAT was continuing to respond to keepalive requests. It might be a bug, because it appears like if host lost the connection this should be translated to behind-NAT counterpart. If this worked it would be possible to configure host's keepalive settings for host to do outbound part.

[Valery Ushakov]

The latter is #11696 - which is alleviated in 4.3.22. Alleviated, not fixed, because it converts inbound reset to orderly shutdown, which is not correct, but it brings Windows in line with Unix versions.