VirtualBox Networking does not pass DCE RPC BIND packets with OS X host

[Matt Foster]

Host: OS X 10.5.7 Guest: Vista 32 bit, SP1. Outlook 2007 SP2 (Also happens with Win7) Networking: Bridged to wired ethernet (also happens with NAT)

Windows Vista/Win7 guests are unable to connect to Exchange 2003 using MAPI. The DCE RPC BIND packet sent from the guest never leaves the host. Attached screen shots show wireshark captures from the guest and the host.

Packet 744 (the last one in the guest trace), never appears in the host trace. This happens regardless of the type of NIC emulated in the guest (Intel and PCnet-FAST III) tested.

The X.X.67.255 box is the Vista guest client and the X.X.55.71 box is the Exchange server. The .255 is valid as an ip address for the client as a large netmask is being used.

This prevents outlook from communicating with Exchange.

All firewalls on host and guest disabled.

Present since at least 2.1.2 on OS X

[Matt Foster]

Host packet capture screenshot

[Matt Foster]

guest packet capture screenshot

[Matt Foster]

Note - all other windows networking (file shares, browsing, HTTP, kerberos) seem to be working fine.

[Matt Foster]

VBox log included

[vasily Levchenko]

Could you please add log for the same issue with NAT networking?

[Matt Foster]

Log file when NAT networking used. (Other log is with bridged)

[Matt Foster]

A bit more information. I've been through the normal outlook issue steps of deleting and recreating the mail profiles. At one point I suspect the guest OS, but even with clean installs of both Vista and Win7 plus O2K7 the issue is repeatable and happens every time.

[vasily Levchenko]

Replying to fm2503:

A bit more information. I've been through the normal outlook issue steps of deleting and recreating the mail profiles. At one point I suspect the guest OS, but even with clean installs of both Vista and Win7 plus O2K7 the issue is repeatable and happens every time.

Would you mind to send me (vasily[dot]levchenko[at]Sun[dot]COM) pcap file of guest to NAT interaction (please see ​pcap for details)

[Matt Foster]

Replying to Hachiman:

Would you mind to send me (vasily[dot]levchenko[at]Sun[dot]COM) pcap file of guest to NAT interaction (please see ​pcap for details)

Annonmised pcap mailed as requested.

[Rob Moore]

I'm seeing something similar but I have a Ubuntu 9.04 host and a Windows XP guest. Also, I've had success connecting to Exchange but only intermittently and after a wait of 10 minutes or so. I can provide pcap data if desired.

[vasily Levchenko]

Replying to robmoore:

I'm seeing something similar but I have a Ubuntu 9.04 host and a Windows XP guest. Also, I've had success connecting to Exchange but only intermittently and after a wait of 10 minutes or so. I can provide pcap data if desired.

Thanks for information, please do it. will compare and will try found some solution

[vasily Levchenko]

BTW: Is it new issue appeared in 2.2.4 or it presents in 2.0, 2.1 as well?

[Matt Foster]

Replying to Hachiman:

BTW: Is it new issue appeared in 2.2.4 or it presents in 2.0, 2.1 as well?

It certainly wasn't present in 1.6, nor I think 2.0. Unfortunatley I switched from an Ubuntu host to a OS X around the 2.1 time frame, so can't be certain when exactly it broke.

IIRC the problem manifested itself around the 2.2 time frame. I think 2.1 was OK, but am not in a position to test at the moment. Could probably do a binary chop to determine exact version this regression was introduced, but that will have to wait for the weekend.

Matt

[Rob Moore]

I've sent the pcap file to your email. A small note, in the pcap instructions you link to the command line options are a bit out of date -- it appears the option is modifyvm rather than just modify.

[vasily Levchenko]

Replying to robmoore:

I've sent the pcap file to your email. A small note, in the pcap instructions you link to the command line options are a bit out of date -- it appears the option is modifyvm rather than just modify.

Thank you for files, and noticing mistype on wiki (updated).

[Matt Foster]

I've done some version testing and on OS X the problem is present in 1.6.4 2.0.8 2.1.4 and 2.2.4. Clearly this is an OS X specific thing, as I didn't see this issue on Kubuntu at all.

[vasily Levchenko]

Replying to fm2503:

I've done some version testing and on OS X the problem is present in 1.6.4 2.0.8 2.1.4 and 2.2.4. Clearly this is an OS X specific thing, as I didn't see this issue on Kubuntu at all.

Thank you for update and investigation.

[Matt Foster]

This seems to be a generic problem with the RPC traffic and VB on OS X. Using a host only network I was unable to domain join a W2K03SP2 box to a 2K08 domain until I followed the steps listed in ​http://support.microsoft.com/kb/899148

Notably I set Server2003NegotiateDisable to 1, and then the 2K03SP2 box was able to join the domain. Without this flag set, the box could not join the domain and failed with RPC errors.

Sadly Server2003NegotiateDisable doesn't solve the problem for Vista and outlook to talk MAPI to exchange

[Matt Foster]

Having said that, I've flicked the Vista VM to bridged networking, and my connectivity to Exchange is restored. I'll double check the NAT configuration. Server2003NegotiateDisable certainly works around the problem using bridged networking.

[Matt Foster]

OK, the situation is confirmed. With host only or bridged networking Server2003NegotiateDisable set allows these RPC packets to pass, and connectivity is achieved. With NAT networking the problem remains.

Hope this helps.

[Matt Foster]

Issue is still present with NAT networking under version 3.0.2. Bridged continues to work fine.

[Matt Foster]

I've upgraded to 3.0.4 and on first glance the problem remained. However I have been able to establish connectivity with Exchange by authenticating in the format fqdn.domain.name.com\user.name and configuring the security settings on the exchange account for Logon network security to "Negotiate Authenticaiton".

So whilst there are various scenarios that do not work, these could equally be down to outlook/exchange strangeness, although server2003NegotiateDisable does seem to be still required.

As a valid work around now exists I'm happy for this to be closed.

[vasily Levchenko]

Replying to fm2503:

Thank you for publishing workaround.

[vasily Levchenko]

Replying to fm2503: Could please collect the pcap files for 2.1 and 3.0.4 releases? Still not sure what is real problem for dropping this packets.