NAT not working in 4.3.22

[Kevn]

Upgrade to 4.3.22 broke previously working NAT networking (Adapter 1 Attached to NAT). Test build revision 98674 shows same problem.
[Edit: Original posting reported pre-upgrade version was 4.3.18, but now I believe version was 4.3.12 prior to upgrade.]

Host is Windows 7, Guest is Redhat 5.7

Using "Attached to: Bridged Adapter" works perfectly, being used as a temporary workaround for ssh and other networking tools, but NAT needed for VPN and for port forwarding.

Symptom is lack of connectivity for ssh (and telnet and ftp). Ping works. And DNS lookup also works with --natdnshostresolver1 set to on.

Code: Select all

% ssh tcadrd7
ssh: connect to host tcadrd7 port 22: Network is unreachable
% ping tcadrd7
PING tcadrd7 (10.15.87.239) 56(84) bytes of data.
64 bytes from 10.15.87.239: icmp_seq=1 ttl=55 time=110 ms

Based on the following trace and the fact that Bridged mode works great, I don't think the problem is with the guest network configuration.

Code: Select all

VBoxManage modifyvm RedHat5.7 --nictrace1 on --nictracefile c:\file.pcap

The symptom is in line 29 of file.pcap:

Code: Select all

26	57.167219	10.0.2.15	10.0.2.3	DNS	67	Standard query 0x3240  A tcadrd7
27	57.167427	10.0.2.3	10.0.2.15	DNS	83	Standard query response 0x3240  A 10.15.87.239
28	57.167593	10.0.2.15	10.15.87.239	TCP	74	50826→22 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=4294718103 TSecr=0 WS=128
29	57.168686	10.0.2.2	10.0.2.15	ICMP	70	Destination unreachable (Network unreachable)
30	61.169004	10.0.2.15	10.0.2.3	DNS	67	Standard query 0x3c3c  A tcadrd7
31	61.169236	10.0.2.3	10.0.2.15	DNS	83	Standard query response 0x3c3c  A 10.15.87.239
32	61.169447	10.0.2.15	10.15.87.239	ICMP	98	Echo (ping) request  id=0x060c, seq=1/256, ttl=64 (reply in 33)
33	61.267503	10.15.87.239	10.0.2.15	ICMP	98	Echo (ping) reply    id=0x060c, seq=1/256, ttl=55 (request in 32)

Lines 26-27 show that the DNS query is working (I first had to set up "--natdnshostresolver1 on" because DNS packets were also being stopped).
Line 28 shows the ssh request properly goes out from the guest at 10.0.2.15.
Line 29 shows the VirtualBox NAT implementation thinks the network is unreachable.
Lines 30-33 show a successful ping to tcadrd7

What I've tried unsuccessfully:

• Tried four different Adapter Types
• Tried --natbindip1 to the working Windows 7 interface (both cabled and wireless)
• Disconnected and reconnected the cable with --cableconnected1
• Tried NAT Network instead of NAT, but obtained same lack of network connectivity for ssh.

Would anybody have any steps I should take to debug, or any possible ways to get NAT working again?

[michaln]

Could you please try 4.3.20 to narrow down when things changed?

At any rate, you should probably create a ticket on the public bug tracker, attach VBox.log for the VM and the packet trace.

Lots of people are using ssh with NAT without trouble, so the logical question is: What's so unusual about your setup?

[Kevn]

Downgrade to 4.3.20 results in the same non-connectivity behavior (didn't try the scan, though).
Downgrade to 4.3.18 -- the version I thought was running previously -- now results in the same non-connectivity behavior (!).
Downgrade to 4.3.16 results in unstable running of the VM.
Downgrade to 4.3.14 results in immediate error message when running VM.
I didn't try anything further back.

Before pursuing the issue of why downgrades don't help return previously working behavior, I perused VBox.log and VBoxStartup.log to try to answer michaln's logical question: "What's so unusual about your setup?"

We use Novell SecureLogin for single-signon to the network.

And in the VBox.log file I found, voi-là:

Code: Select all

00:00:25.520477 supR3HardenedErrorV: supR3HardenedScreenImage/LdrLoadDll: cached rc=VERR_LDRVI_UNSUPPORTED_ARCH fImage=1 fProtect=0x0 fAccess=0x0 cHits=2048 \Device\HarddiskVolume2\Program Files\Novell\SecureLogin\slcaptain64.dll
00:00:25.520580 supR3HardenedErrorV: supR3HardenedMonitor_LdrLoadDll: rejecting 'C:\Program Files\Novell\SecureLogin\slcaptain64.dll' (C:\Program Files\Novell\SecureLogin\slcaptain64.dll): rcNt=0xc0000190

So my current hypothesis is that the rejection of the SecureLogin dll is preventing the VirtualBox NAT implementation from speaking TCP with my host network adapter. Apparently ICMP is allowed, permitting the ping.

Does this sound like a reasonable hypothesis? If so, is there some way I can test further? And ultimately, are there solution options?

Thanks

[Perryg]

Version 4.3.12 was the last version before the security hardening was added. I would see if it works with that version to verify if that is your issue.

[Kevn]

I downgraded to 4.3.12 and now I have perfect network connectivity again with NAT.

Thank you for your help. I'll take the issue to the IT department here to see why the Novell dll doesn't seem to be signed.

[michaln]

OK, that explains the problem at hand, but... 4.3.18 should have behaved the same in this regard (i.e. rejecting unsigned DLLs)! Do you know if that's something which may have changed on your end?

[Kevn]

Don't know of any changes on my end, so my best explanation is that I was running 4.3.12 for a long time, thinking it was 4.3.18. I did not carefully re-check the version before doing the upgrade.

[michaln]

OK, that would explain it