Garbled SSH packets, garbled HTML packets, but not in every

[fozboz]

Hello,

I am having a very strange problem with lost headers on packets when trying to contact a guest VM.

I have bare metal running CentOS 7 and VirtualBox v.5.0.14. I then have a guest running Ubuntu 15.10 using bridged networking. It has happily picked up its IP address from our DHCP server. The guest is running SSH and Apache.

All firewalls are disabled on VirtualBox host, guest and all clients used in the tests below.

I can SSH out from the guest to any other Linux host on our network. I can also connect to Windows Samba services, served out by Windows hosts.
SSH and Apache work when accessing guest from VirtualBox host. Likewise, I can SSH to VBox host from guest
SSH and Apache work when accessing guest from an Ubuntu laptop
SSH and Apache work when accessing guest from CentOS 7 VM
SSH to the VBox host using PuTTY in Windows works fine

Everything is working as it should, right?

SSH from any Windows host using PuTTY results in a "Packet was garbled on decryption" error
Apache from any Windows host results in either unintelligible text output to the screen, or it attempts to download a file which contains the same unintelligible text, depending on the browser

Using Solaris to get the Apache web page or SSH gives us a little more insight. I'm guessing it's behaving the same as the Windows hosts, except we get more debugging output.

Code: Select all

ssh fullyqualifiedguesthostname
0000 0000 0000 a89f
Disconnecting: Bad packet length 0.

The end of that line of numbers is different every time, with a hexadecimal string. i.e.

Code: Select all

0000 0000 0000 xxxx

And when using wget to get the webpage...

Code: Select all

wget --no-proxy fullyqualifiedguesthostname
--09:57:38--  fullyqualifiedguesthostname
           => `index.html'
Resolving fullyqualifiedguesthostname... x.x.x.x
Connecting to fullyqualifiedguesthostname|x.x.x.x|:80... connected.
HTTP request sent, awaiting response... 200 No headers, assuming HTTP/0.9
Length: unspecified

    [      <=>                            ] 11,638         2.33K/s

09:57:43 (2.33 KB/s) - `index.html' saved [11638]

Note the No headers, assuming HTTP/0.9

Additionally, it takes a good few seconds to download this 11Kb file.

Using wget on an Ubuntu host:

Code: Select all

wget --no-proxy fullyqualifiedguesthostname
--2016-02-26 10:08:06--  fullyqualifiedguesthostname
Resolving fullyqualifiedguesthostname (fullyqualifiedguesthostname)... x.x.x.x
Connecting to fullyqualifiedguesthostname (fullyqualifiedguesthostname)|x.x.x.x|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11321 (11K) [text/html]
Saving to: ‘index.html’

100%[=========================================================>] 11,321      --.-K/s   in 0s

2016-02-26 10:08:06 (160 MB/s) - ‘index.html’ saved [11321/11321]

No problems, no message about missing headers, it is done in the blink of an eye, as you'd expect.

And now here are the first lines of the index.html file that was downloaded on the Solaris host:

Code: Select all

cat index.html
.1 200 OK
Date: Fri, 26 Feb 2016 10:18:26 GMT
Server: Apache/2.4.12 (Ubuntu)
Last-Modified: Tue, 26 Jan 2016 15:38:24 GMT
ETag: "2c39-52a3e79e18489"
Accept-Ranges: bytes
Content-Length: 11321
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

Normal, unmolested HTML code follows this.

The index.html file downloaded on the Ubuntu host does NOT contain these first lines. It is just the HTML code.

I am assuming that the missing headers are what is causing the unintelligible text when accessing the web page from a Windows host - the browsers don't know what the file is and therefore don't know how to display it. I am also assuming that the same goes for the SSH failures - missing headers.

I think that just about captures all the variables in this web of confusion.

Does anyone know what the heck is going on?

[fozboz]

I have figured it out. It was annoyingly simple.

It was the virtual network adapter type. This was configured as Intel Pro/1000 MT Desktop.

I have switched it to the Paravirtualization adapter and the issues have disappeared.

This is annoying as a) Paravirtualization has much higher performance and b) this is the standard for KVM and has been fully supported since Kernel 2.6. Why is this not the default when I've told VBox I'm installing a modern Linux guest?

I'm submitting this to Oracle as a bug.