[SOLVED] Windows 7 64bit host network not working for guests

[petocervik]

Hi,

I have problem to get network work for my guests under my host Win7 64bit Pro. I've configured network as NAT. The guest OS gets the IP address from DHCP as well as DNS servers (in /etc/resolv.conf are entries which I can ping from my host and there is also domain name of our internet provider). But outer network is unreachable. When I ping address like google's dns 8.8.8.8 I get response, but when I ping domain name like google's one, I don't get anything. I also have doubt that IP address response is authentic.

As guest I am using CentOS, but I have also tried Debian and issue was the same.

What I found so far:
1. from the log I find out, that when I am trying to resolve some domain name I get this entries:

Code: Select all

00:00:37.553264 supR3HardenedErrorV: supR3HardenedScreenImage/LdrLoadDll: cached rc=VERR_LDRVI_NOT_SIGNED fImage=1 fProtect=0x0 fAccess=0x0 cHits=1 \Device\HarddiskVolume1\Program Files\Open Text\SOCKS Client\HumSOCKS.dll
00:00:37.553523 supR3HardenedErrorV: supR3HardenedMonitor_LdrLoadDll: rejecting 'C:\Program Files\Open Text\SOCKS Client\HumSOCKS.dll' (C:\Program Files\Open Text\SOCKS Client\HumSOCKS.dll): rcNt=0xc0000190

The unsigned dlls are from Open Text Socks client.
2. When I tried to uninstall Socks, as it was working before I installed it, it works how it should.

Some summary information, which can be usefull:
Host: Windows 7 64bit Pro
Virtualbox: Version 5.1.2r108956
Guest: CentOS 7
Sigcheck:

Code: Select all

C:\Users\ADMIN\Desktop\temp>sigcheck.exe "C:\Program Files\Open Text\SOCKS Client\HumSOCKS.dll"

Sigcheck v2.54 - File version and signature viewer
Copyright (C) 2004-2016 Mark Russinovich

c:\program files\open text\socks client\HumSOCKS.dll:
        Verified:       Unsigned
        Link date:      22:40 14-May-15
        Publisher:      n/a
        Company:        Open Text Corporation
        Description:    Open Text SOCKS Client for x64
        Product:        Open Text SOCKS Client
        Prod version:   14.0.0.0
        File version:   14.0.13.188
        MachineType:    64-bit

Is there any solution other than uninstalling Socks, as it is more important for me then virtualbox?

[socratis]

The HumSOCKS.dll is unsigned. It tries to load itself inside the VirtualBox process. This is not allowed as of VirtualBox 4.3.12. It is rejected and that affects your network, presumably because the DNS resolutions have to go through HumSOCKS.dll. The thing is that in their website they say that it is Windows 7 certified. Doesn't that mean signed as well? Or maybe you have an older version whose signature has expired?

Unless you get a signed version of the DLL, or you can put some rules that prevents it specifically from attaching itself to VirtualBox, no, there is no other solution.

See also ticket #13292 (https://www.virtualbox.org/ticket/13292).

[mpack]

The thing is that in their website they say that it is Windows 7 certified. Doesn't that mean signed as well?

Not quite, though they do tend to go together. Windows certification is a quality assurance rubber stamp on the outside: compatibility with Windows latest standards, particularly if it involves device drivers not bringing down the entire PC. Signing OTOH is about the credentials of the supplier, not the quality of the code. Signing says "I'm not malware", not "I'm bug free".

OTOH, if someone has gone to the (unnecessary) expense to get their app certified, I'd have thought they'd sign it too.

[socratis]

You're right, it would seem logical that certification and signing go together, I simply thought it was actually a requirement. Thanks for the explanation.

[petocervik]

I've seen that ticket #13292, it was actually how I came to unsigned dlls conclusion. But this really helped me:

... This is not allowed as of VirtualBox 4.3.12. ...

I haven't realized when I was reading that thread, that downgrading VirtualBox can solve my problem. It did.

Now I feel little silly, but at least my problem is solved. Thank you very much for your help.

[socratis]

Mind you this is not a solution, this is a workaround, at a time when VirtualBox didn't actually look for processes that were injecting themselves into VirtualBox. This was a security threat. Still is. Just wanted to warn you of the dangers. You seem to take precautions even with your TCP connections so be aware of the dangers in VirtualBox.

[mpack]

It's also not a solution because 4.3.12 is becoming increasingly obsolete. E.g. it isn't supported in Win10 hosts. You can't stay with that forever, except to run even less current operating systems.