In virtualbox use nat, sometimes network error with "Connection reset by peer"

[Maxwell]

when I use vagrant with ubuntu/xenial64, I found I usally get a network error.
i.e. sudo apt-key adv --keyserver hkp://ha.pool.sks-keyservers.net:11371 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
The output is like this:
Executing: /tmp/tmp.LO7eukZqdi/gpg.1.sh --keyserver
hkp://ha.pool.sks-keyservers.net:11371
--recv-keys
58118E89F3A912897C070ADBF76221572C52609D
gpg: requesting key 2C52609D from hkp server ha.pool.sks-keyservers.net
?: [fd 4]: read error: Connection reset by peer
gpgkeys: key 58118E89F3A912897C070ADBF76221572C52609D partially retrieved (probably corrupt)
gpg: no valid OpenPGP data found.
gpg: key 2C52609D: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg: w/o user IDs: 1

I use
docker run -d --name registry --restart always -p 5000:5000 -v /vagrant/config/docker-registry/config.yml:/etc/docker/registry/config.yml -v /vagrant/repo/docker-registry:/var/lib/registry registry
create a private docker registry, in another vagrant env(ubuntu/xenial64 box), when I run
docker pull xxxx
I can found error in /var/log/syslog like this:
Nov 3 12:59:00 ubuntu-xenial dockerd[2167]: time="2016-11-03T12:59:00.506141276Z" level=error msg="Error trying v2 registry: read tcp 10.0.2.15:33580->10.99.169.227:5000: read: connection reset by peer"
Nov 3 12:59:00 ubuntu-xenial dockerd[2167]: time="2016-11-03T12:59:00.506732903Z" level=error msg="Attempting next endpoint for pull after error: read tcp 10.0.2.15:33580->10.99.169.227:5000: read: connection reset by peer"

I create a test in attachment, that is copy from sudo apt-key adv --keyserver hkp://ha.pool.sks-keyservers.net:11371 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
I test that test in ubuntu, 99% get the connection reset by peer, but I test in vagrant env (centos/7 box), always right.
Run test like this:
tar -xf gpgtest.tar
cd gpgtest
./gpg.1.sh --keyserver hkp://ha.pool.sks-keyservers.net:11371 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D

I got output in ubuntu:
gpg: WARNING: unsafe permissions on homedir `.'
gpg: requesting key 2C52609D from hkp server ha.pool.sks-keyservers.net
?: [fd 4]: read error: Connection reset by peer
gpgkeys: key 58118E89F3A912897C070ADBF76221572C52609D partially retrieved (probably corrupt)
gpg: no valid OpenPGP data found.
gpg: key 2C52609D: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg: w/o user IDs: 1

And got output in centos:
gpg: 警告：用户目录‘.’权限不安全
gpg: 下载密钥‘2C52609D’，从 hkp 服务器 ha.pool.sks-keyservers.net
gpg: 密钥 2C52609D：“Docker Release Tool (releasedocker) <email address hidden>”未改变
gpg: 合计被处理的数量：1
gpg: 未改变：1

My env:
Mac book pro 15, macOS 10.12.1 (16B2555)
vagrant 1.8.6
virtualbox 5.1.8
vagrant box ubuntu/xenial64 20161102.0.0
vagrant box centos/7 1609.01

I test in xps13(win10) and mibook(win10), got the same error.
I test with other vbox network(nat network, host only), not this error.
I test with different wifi, got the same error.

I think this is a ubuntu/xenial64 box's error.

[Maxwell (maxwell1987)]

I test the desktop version(ubuntu-16.04.1-desktop-amd64.iso) in vbox nat, had the same error.

[Jan Boonen (janboonen5)]

I had the exact same problem with the Debian Jessie box from Hashicorp. I solved the issue by downgrading VirtualBox to version 4.3.40. So, I guess the problem is not in the image.

[Maxwell (maxwell1987)]

to Jan Boonen:
I test centos/7 in same virtualbox version, but it has not the error.

btw: how to reply a comment?

[Mat Schaffer (mat-schaffer)]

https://www.virtualbox.org/ticket/16084 Seems to be the underlying VirtualBox issue for this.

The tests build in recent comments (Mac OS 5.1.9 r111957 (Qt5.6.2)) is working for me so far.

[Maxwell (maxwell1987)]

Yes, upgrading to vbox 5.1.9 r11957 hasn't get the error.

[John Chittum (jchittum)]

Closing as stale and fixed in virtualbox. a fix was reported in 5.1.9, and all versions of Ubuntu in standard support (20.04 forward) have > 5.1.9 virtualbox (in this case, 6.1.6 in 20.04)

marked as "invalid" for cloud-images, as the original bug was virtualbox, not the image.