VMware Communities
SMB1
Expert
Expert
Jump to solution

Virtual Interfaces being registered in DNS

This is a new problem since moving my OS X host to Leopard, it didn't occur in Tiger. The problem is the OS X host is registering the 172.16.x.x addresses that are being assigned to host only and NAT interfaces in my companies DNS. This is making reverse lookups my host slow and/or incorrect (I suspect it is one of the things making AD logins so slow).

This really should not be happening.

Now it may not really be a Fusion problem but what I need to know is how to simply disable the NAT and host only interfaces completely so no address is assigned to be updated in DNS in the first place. I only use bridged networking.

Reply
0 Kudos
1 Solution

Accepted Solutions
WoodyZ
Immortal
Immortal
Jump to solution

Now it may not really be a Fusion problem but what I need to know is how to simply disable the NAT and host only interfaces completely so no address is assigned to be updated in DNS in the first place. I only use bridged networking.

I don't know if this is the official way however it's what worked for me...

You need to edit the "/Library/Application Support/VMware Fusion/boot.sh" file.

In Terminal...

$ sudo nano "/Library/Application Support/VMware Fusion/boot.sh"

Near the end of the boot.sh file there are lines as shown below (not together in the file and just shown here for example).

  1. Create virtual interface for the NATted vmnet8

"$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet8.pid vmnet8 vmnet8

  1. Create virtual interface for the Host-Only vmnet1

"$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet1.pid vmnet1 vmnet1

You need to comment out the two lines that start with '"$LIBDIR/vmnet-netifup"' by placing a "#" in front.

  1. Create virtual interface for the NATted vmnet8

"# "$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet8.pid vmnet8 vmnet8"

  1. Create virtual interface for the Host-Only vmnet1

"# "$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet1.pid vmnet1 vmnet1"

Now restart the boot.sh with...

sudo "/Library/Application Support/VMware Fusion/boot.sh"

After that if you do ifconfig -a you will not see vmnet1: or vmnet8:

Edit: I placed quotes around the 2 lines to be commented in the example because this message board just loves to screw up what's typed sometimes and it's really starting to get annoying! Obviously in the actual file only a "#" is placed in front of the line

View solution in original post

Reply
0 Kudos
5 Replies
WoodyZ
Immortal
Immortal
Jump to solution

Now it may not really be a Fusion problem but what I need to know is how to simply disable the NAT and host only interfaces completely so no address is assigned to be updated in DNS in the first place. I only use bridged networking.

I don't know if this is the official way however it's what worked for me...

You need to edit the "/Library/Application Support/VMware Fusion/boot.sh" file.

In Terminal...

$ sudo nano "/Library/Application Support/VMware Fusion/boot.sh"

Near the end of the boot.sh file there are lines as shown below (not together in the file and just shown here for example).

  1. Create virtual interface for the NATted vmnet8

"$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet8.pid vmnet8 vmnet8

  1. Create virtual interface for the Host-Only vmnet1

"$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet1.pid vmnet1 vmnet1

You need to comment out the two lines that start with '"$LIBDIR/vmnet-netifup"' by placing a "#" in front.

  1. Create virtual interface for the NATted vmnet8

"# "$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet8.pid vmnet8 vmnet8"

  1. Create virtual interface for the Host-Only vmnet1

"# "$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet1.pid vmnet1 vmnet1"

Now restart the boot.sh with...

sudo "/Library/Application Support/VMware Fusion/boot.sh"

After that if you do ifconfig -a you will not see vmnet1: or vmnet8:

Edit: I placed quotes around the 2 lines to be commented in the example because this message board just loves to screw up what's typed sometimes and it's really starting to get annoying! Obviously in the actual file only a "#" is placed in front of the line

Reply
0 Kudos
SMB1
Expert
Expert
Jump to solution

Thank you, that worked. It would be nice to have a better way to do that though.

Reply
0 Kudos
WoodyZ
Immortal
Immortal
Jump to solution

Thank you, that worked. It would be nice to have a better way to do that though.

I agree however until there is a GUI for these things I don't see another way.

FWIW I always copy the original target file appending an .ori to it and then make my edits once the copy the edited file to a file with an appropriate added extension. I then incorporate the various configurations into into a script which based upon a command line argument copies the target added extension file to the working named file and restart the service in this case. Thus being able to quickly switch between various configurations without having to edit the working file each time.

Reply
0 Kudos
HangLoose74
Contributor
Contributor
Jump to solution

If I followed your description, vmnet1 and vmnet8 indeed disapear from ifconfig. But when i start my VM (Windows XP), Fusion gives a note that the device "dev" vmnet0 cannot be found/started.

After that I tried the following:

-) sudo rm locations (in the /Library/Application Support/VMware Fusion directory)

-) sudo ./vmware-config-net.pl

-) sudo ./boot.sh --restart

Still it doesn't seem to work for me. Any ideas?

With Kind Regards

Reply
0 Kudos
ed_209
Contributor
Contributor
Jump to solution

I concur with this assessment. I raised Apple Bug ID 664258. We too are experiencing this problem on Mac OS X 10.5.6 machines bound to AD with VMWare installed, and whilst I don't have conclusive proof, either uninstalling VMWare or turning off Bonjour, or unbinding from the AD domain will stop the issue. None of these are palatable solutions though.

The solution suggested on this thread is also unacceptable - we need the vmnet interfaces because we require NAT. (Automatic interface switching, access via the raccoon PPTP implementation and so forth). Although I mention Parallels Desktop in the bug report, I don't think we seem to notice the same issue with Parallels Desktop since its networking plays infinitely nicer with Mac OS X - its interfaces show up in the Network system prefs pane for example.

So, whilst conceding that it's likely a problem in the way mDNSResponder detects interface, it sure would be nice if there was a way to 'cloak' VMWare interfaces from DNS-SD address-based domain enumeration queries.

How about it Fusion guys?

-


Here's the bug report...

Bonjour address-based domain enumeration queries for virtual private interfaces

04-Mar-2009 10:07 AM Marc Bailey:

Summary

-


What is the "defined" DNS-SD behaviour for address-based domain

enumeration queries on virtual interfaces with RFC1918 private address

space?

Steps to Reproduce

-


A Mac OS X 10.5.6 computer running VMWare Fusion or Parallels

Desktop ends up with a number of virtual network interfaces in RFC1918

private address space.mDNSResponder periodically issues address-based domain enumeration

queries for all network base addresses by bitwise AND of mask and

address.For example, for a standard vmnet interface of 172.16.162.1/24 Bonjour issues DNS queries like:PTR lb._dns-sd_udp.0.162.16.172.in-addr.arpa.

The problem is that these address zones do not exist because they

are artefacts of the VM environments, and since there are five standard

bonjour domains, you get a heap of NXDOMAIN replies with 2 second

timeout latency. Rinse and repeat. Frequently.

Actual Results

-


We can't yet precisely confirm, but believe that this is causing

large problems with Active Directory bound Macs. A typical Mac Book Pro

with Parallels and VMWare, GigE and Wifi connections will offer seven

interfaces, five of which are virtual. So, five domain enumerations X

five interfaces x 2 second delay = 50 seconds.For some reason we see blocking behaviour at login time; login

appears to be stalled (beachballed) and the only traffic seems to be

unicast DNS-SD queries of this form - even though kerberos handshaking

is working fine.Only after mDNSResponder gives up on these queries can a user

login. This can take minutes. It's almost like Bonjour is being

consulted to discover AD services - which of course makes no sense.

Expected Results

-


What is the "defined" DNS-SD behaviour here? Should virtual

interface domain enumeration queries even make it out of the machine? I

am guessing the answer to that is a firm 'no'.

Regression

-


sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistresults in elimination of login delays and timeouts.It also, naturally, is very undesirable because it shuts down Bonjour completely.

Notes

-


I'm requesting clarification from the Bonjour team as to what is

"supposed" to happen for these kinds of interfaces. Then happy to take

this to VMware or Parallels for resolution if they are doing the wrong

thing somehow or if there is no way for mDNSResponder to recognise

their interfaces as 'virtual'.Another possibility might be to provide an explicit

include/exclude interface plist/config file for Bonjour to manually

confine mDNSResponder to physical interfaces only.


[Marc Bailey|http://jira.objective.com/secure/ViewProfile.jspa?name=marc] -

04/Mar/09 10:16 AM Raised Apple bug ID 6642581

Bonjour address-based domain enumeration queries for virtual private

interfaces

04-Mar-2009 10:07 AM Marc Bailey:

Summary

-


What is the "defined" DNS-SD behaviour for address-based domain

enumeration queries on virtual interfaces with RFC1918 private address

space?

Steps to Reproduce

-


A Mac OS X 10.5.6 computer running VMWare Fusion or Parallels Desktop

ends up with a number of virtual network interfaces in RFC1918 private

address space.

mDNSResponder periodically issues address-based domain enumeration

queries for all network base addresses by bitwise AND of mask and

address.

For example, for a standard vmnet interface of 172.16.162.1/24 Bonjour

issues DNS queries like:

PTR lb._dns-sd_udp.0.162.16.172.in-addr.arpa.

The problem is that these address zones do not exist because they are

artefacts of the VM environments, and since there are five standard

bonjour domains, you get a heap of NXDOMAIN replies with 2 second

timeout latency. Rinse and repeat. Frequently.

Actual Results

-


We can't yet precisely confirm, but believe that this is causing large

problems with Active Directory bound Macs. A typical Mac Book Pro with

Parallels and VMWare, GigE and Wifi connections will offer seven

interfaces, five of which are virtual. So, five domain enumerations X

five interfaces x 2 second delay = 50 seconds.

For some reason we see blocking behaviour at login time; login appears

to be stalled (beachballed) and the only traffic seems to be unicast

DNS-SD queries of this form - even though kerberos handshaking is

working fine.

Only after mDNSResponder gives up on these queries can a user login.

This can take minutes. It's almost like Bonjour is being consulted to

discover AD services - which of course makes no sense.

Expected Results

-


What is the "defined" DNS-SD behaviour here? Should virtual interface

domain enumeration queries even make it out of the machine? I am

guessing the answer to that is a firm 'no'.

Regression

-


sudo launchctl unload -w

/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

results in elimination of login delays and timeouts.

It also, naturally, is very undesirable because it shuts down Bonjour

completely.

Notes

-


I'm requesting clarification from the Bonjour team as to what is

"supposed" to happen for these kinds of interfaces. Then happy to take

this to VMware or Parallels for resolution if they are doing the wrong

thing somehow or if there is no way for mDNSResponder to recognise

their interfaces as 'virtual'.

Another possibility might be to provide an explicit include/exclude

interface plist/config file for Bonjour to manually confine

mDNSResponder to physical interfaces only.

</div>

</div>

</div>

Reply
0 Kudos