Mac os bridged networking

How to bridge vboxnet with Wi-Fi on OS X 10.10 «Yosemite»

I am trying to bridge two interfaces on OS X 10.10 «Yosemite» but somehow this does not seem to work for virtual interfaces:

The network on Virtualbox goes over «Host Only Network»

Is there a way to overcome this? I want to bridge 192.168.56.1 with the Wi-Fi in order to make my virtual machines visible to other computers on the internet.

1 Answer 1

VirtualBox and OS X provide several (no-NAT) methods to connect your VM:

1. The VirtualBox «Bridged Adapter»:

First remove bridge1 in Terminal and use a «Bridged Adapter» instead of vboxnet0 in your VM. Go to the Network settings of the respective VM -> Adapter1 -> attached to: and change the type from whatever it is now to «Bridged Adapter» then choose your Wi-Fi interface:

The VM’s en0 attached to the bridged adapter has to be configured with a unique IP in the same network range as the hosts interface IP.

• My hosts en1 config: network: 192.168.1.0/24 IP: 192.168.1.2 gateway: 192.168.1.1
• The VM’s eth0 config: network: 192.168.1.0/24 IP: a free and unique IP-address in the range 192.168.1.3-192.168.1.254 gateway: 192.168.1.1

If you want to make the VM accessible to other computers in the WAN (internet) (e.g. a web-server) you have to forward the respective ports in the router to the VM’s IP. The VM can be accessed by all other computers in the same network (192.168.1.0/24) in your LAN directly.

Finally it looks like this:

2. The OS X bridge

I assume en1 is your Wi-Fi interface and eth0 is the first adapter in your (Linux-)VM. Check this with ifconfig on your VM-host. Please adapt the commands and change the interfaces below if necessary.

If you don’t want to use «Bridged Adapter» but vboxnet0 do the following after starting VirtualBox:

Attach the VM adapter 1 to the «Host-only Adapter» and the «Name» vboxnet0.

On the host in Terminal enter:

In the VM (Linux) you have to configure an IP-address and a default route:

A configured «Network Manager» might interfere with those settings.

On the various Macs in your network you have to configure an additional static route:

On the router your have to forward ports to the VM and add a static route to 192.168.56.0/24 to make the VM accessible to other computers in the WAN (internet).

Finally it looks like this:

The bridge and the various routes (except those on the router and the default gateway of the VM) don’t survive a reboot.

To roll-back all changes:

To remove bridge1 on the host do the following:

To disable forwarding on the host do the following:

To remove static routes on the Mac enter:

Remove the static route on the Router.

As a result one might say it’s much easier and much more comfortable to use method 1.

Источник

Mac os bridged networking

Virtual machine can use three different networking modes depending on user needs:

To switch between network modes go to menu bar when virtual machine is active > Devices menu > Network.

Note: configuring Shared and Host-Only networks is available in Pro and Business Editions in Parallels Desktop Preferences > Network.

Shared Networking

This is the default and recommended network mode for virtual machines, as it works «out of the box» and does not require any specific configuring. When this networking mode is used Parallels Desktop will work as a virtual router for your virtual machine. As a result:

• Parallels Desktop creates a separate virtual subnet with its own virtual DHCP server running in macOS.
• A virtual machine belongs to that virtual subnet with its own IP range.
• A virtual machine is not visible in the real subnet the Mac belongs to.
• A virtual machine use full Internet access.
• If Mac is connected to virtual private network — VPN access is automatically shared with virtual machine.

This network mode is suitable for most of the user needs.

Bridged Network

When this network mode is used, your virtual machine uses a virtualized network interface card with direct access to Internet. As a result:

• A virtual machine appears as a separate computer that belongs to the same subnet as the Mac it is running on.
• A DHCP server (e.g., your router) provides a virtual machine with an IP address within the same IP range as other computers in the same subnet.
• A virtual machine can ping and see all computers in the subnet.
• Other computers can ping and see the virtual machine.

Note: when selecting this network mode Parallels Desktop is no longer responsible for any network connectivity issues.

Bridged network can be enabled on a particular network interface, such as Ethernet, Wi-Fi or other Mac network interfaces.

• Bridged: Ethernet corresponds to your Mac Ethernet adapter
• Bridged: Wi-Fi corresponds to your Mac Wi-Fi adapter. (may work unstable depending on router settings)
• Bridged: Default Adapter corresponds to whichever network adapter is chosen as the default (the first in the list System Preferences >Network) on the Mac.

Host-Only Network

This mode is similar to Shared Network except that this virtual subnet (10.37.129.x) is isolated from the outer world. As a result, the virtual machine that is working in host-only mode can only see and ping other virtual machines and communicate with the gateway (10.37.129.1).

Additional information

The networking technology basics below should help you decide which networking mode to choose.

When talking about networking we often use terms like IP address, DHCP Server, subnetwork, and many others. The first three are the most important in our case.

IP address

A numerical label assigned to each device (e.g., computer, printer) participating in a computer network that uses the Internet Protocol (IP) for communication.

IP addresses are represented in dot-decimal notation, which consists of four decimal numbers, each ranging from 0 to 255, separated by dots, e.g., 192.168.0.10. Each part represents a group of eight bits of the address. IP addresses, like regular addresses, are used by computers and other devices to communicate with each other.

An IP address can be assigned to a network device (e.g., computer, printer, tablet, smartphone, etc.) either manually by a user or a System Administrator, or automatically by a DHCP server. To see the IP address of your Mac, go to System Preferences > Network.

Your Mac will normally use either a Wi-Fi connection:

or an Ethernet (cable) connection:

DHCP server

A computer or a specific network device (router) that maintains a database of available IP addresses and configuration information. When the server receives a request from a client device (e.g., computer, printer), the DHCP server determines the network to which the DHCP client is connected, and then allocates an IP address that is appropriate for the client, and sends configuration information appropriate for that client.

In an average home network your router will work as a DHCP server that automatically assigns the IP addresses to all your network devices so that you do not need to worry about the IP addresses and other necessary settings for your Mac or a smartphone.

Subnetwork (subnet)

A logically visible subdivision of an IP network. The practice of dividing a network into two or more networks is called subnetting.

All computers that belong to a subnet are addressed with a common, identical, most-significant bit-group in their IP address. For example, a typical home subnet will have IP addresses in the following range: 192.168.0.1-255. This means your Wi-Fi router will have an IP address of 192.168.0.1, your MacBook Pro® will have an IP address of 192.168.0.10, your smartphone — 192.168.0.20 and your wireless printer — 192.168.0.30. To learn more about the settings of the DHCP server, please read your router’s documentation.

Traffic between subnetworks is exchanged or routed with special gateways called routers, which constitute the logical or physical boundaries between the subnets.

Network adapters (NIC) types in virtual machine configuration explanation

In virtual machine configuration you can choose between 4 types of network interface card (NIC):

Virtio network adapter is the fastest card. However, it works only in Linux and BSD guest operating systems. It is a default adapter for Linux-based OSes.

Intel® PRO/1000 MT is a default network adapter for Windows and Mac OS X virtual machines. It works in all operating systems. It also counts a checksum and splits packages. Thus, it allows to increase the network performance.

Intel® Gigabit CT (82574L) support for this network interface was added in Parallels Desktop 11 for Mac. This is Intel’s e1000e Ethernet driver.

Realtek RTL8029AS is the simplest adapter from the list. It does not count a checksum or split packages. The Realtek adapter can be used only if you have Parallels Tools installed in your virtual machine. Without Parallels Tools it will work very slow or even will not work at all. It works especially good with Windows XP virtual machines.

Была ли эта статья полезной?

Как, по вашему мнению, можно улучшить эту статью?

Источник

Ticket #10019 (closed defect: fixed)

Last modified 3 years ago

Unable to bridge Mac OS X AirPort connection

Reported by:	willmc	Owned by:
Component:	network	Version:	VirtualBox 4.1.6
Keywords:	mac bridge wifi airport wireless network	Cc:
Guest type:	Linux	Host type:	Mac OS X

Description

If I connected my host OS (Mac OS X 10.7.2) to a Wi-Fi network, I cannot bridge the VM’s network connection to that interface. The VirtualBox VM settings allow me to choose bridging over that interface, but I’m unable to obtain a DHCP lease or do anything else on that interface. Bridging to the Ethernet interface works fine, and the Wi-Fi connection works fine in the host OS.

Attachments

Change History

Changed 10 years ago by willmc

• attachmentVBox.log added

comment:1 Changed 10 years ago by camjack1728

I am also having this same issue. If there is any information that I can supply to help in trouble shooting this, Please let me know.

comment:2 Changed 9 years ago by DrPepperAndPizza

I am also having the same issue.

• VirtualBox 4.1.18 guest interaction. . «>r78361
• Host: Mac 10.7.4. MacBook Pro. Just purchased 3 weeks ago.
• Guest: Debian 6.0.5, CentOS 6.2. All guests really.

Bridged Network *WAS* working on Wi-Fi. But it stopped after I the the following:

1. Created a 2nd Wi-Fi. (Directions: On Mac OS X, click «System Preferences» -> «Network» -> «+» -> Interface = «Wi-Fi», Service Name = «Wi-Fi (AirPort)» -> «Create» -> «Apply».) I created a 2nd Wi-Fi, because I was on the train going home and wanted to test a VM with 2 NICs.
2. Create a Network. (Directions: On Mac OS X, click the wifi icon in the upper right of the screen -> «Create Network. » -> Network Name = «my network blah», Channel = 11, Security = «None» -> «Create».
3. In Virtualbox, set the VMs to use the 2 wifi in Bridge Network mode.

Up to here, everything was working.

Here is when Bridge Networking stopped working when the wifi is used for bridged networking.

I was done testing and I deleted the 2nd Wi-fi that I created in step 1. (Directions: On Mac OS X, click «System Preferences» -> «Network» -> select «Wi-Fi (AirPort)» which was created in step 1 above -> «-» -> «Apply».

After that Bridged Networking does not work when en1: Wi-Fi (AirPort) is selected. It seems as if VirtualBox is still pointing to the one I deleted. I don’t remember, but I think I named it «Wi-Fi (AirPort)». And that’s the entry that VirtualBox keeps.

But «Wi-Fi» (which is the default in Mac OS X) and is the only entry in «System Preferences» -> «Network».

1. Deleting «Wi-Fi» and creating a «Wi-Fi (AirPort)» to match what Virtualbox is showing.
2. Having both «Wi-Fi» and «Wi-Fi (AirPort)» entries.
3. Uninstalling VirtualBox, reboot, then re-installing.

In the guest, Debian still cannot contact the DHCP server on my network after running /etc/init.d/networking restart: . . Listening on LPF/eth0/08:00:27:56:00:de Sending on LPF/eth0/08:00:27:56:00:de Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 5 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 10 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 13 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 11 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 14 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 intervale 8 No DHCPOFFERS received. No working leases in persistent database — sleeping. done.

I’ve tail -f my dhcp logs and it shows no contact from the guest host.

I’m guessing that Virtualbox is still stuck to the 2nd wifi that I added then deleted.

Everything else works, just not Bridged Networking on wifi.

• NAT works on both wifi and ethernet.
• Bridged Networking works on ethernet. It used to work both both ethernet and wifi, until I added then deleted the 2nd wifi.
• Internal Network works on both
• Host Only Adaptor works on both, I think. Didn’t really test much.

I really want and need Bridged Networking on the wifi to work. Let me know if you need any other info.

comment:3 Changed 9 years ago by DrPepperAndPizza

I ran the command to force the name change on the wifi nic:

And that took. In the VirtualBox Manager windows with the list of VMs on the left and the Details of the settings on the right, the name of the Network is updated:

In the VirtualBox Manager window, I click on the VM to highlight/select it on the left -> «Settings» -> «Network».

For «Attached to» pull down menu, select «Bridged Adaptor».

Then for «Name», the old wifi name «en: Wi-Fi (AirPort)» in the pull down menu it still shows up! There is no choice for «en: Wi-Fi».

So when I select «en: Wi-Fi (AirPort)», the Details show «en: Wi-Fi (AirPort)», not «en: Wi-Fi».

I turned to the source and found in src/VBox/Main/src-server/darwin/iokit.cpp that apparently Virtualbox is some how not finding the interface and generating a name by adding «(AirPort)» or «(Wireless)» to it.

comment:4 Changed 9 years ago by DrPepperAndPizza

So I deleted my VMs. Installed from ISO a new Debian 6 installation. Set to NAT so that it could retrieve packages during the install.

After the installation, I shutdown the guest, switch the NAT to Bridged Networking and started the guest. In the Guest, I set /etc/network/interfaces to a static IP in the same range as my Host. Then rebooted the guest.

Now I’m getting a strange behavior. The host loses connection to the router 192.168.1.1 = router (iptables with Debian 6.0.5) 192.168.1.10 = host OS (Mac OS X 10.7.4) 192.168.1.100 = guest OS (Debian 6.0.5 64-bit)

Pinging scenario 1:

• pinging from host to router works.
• pinging from host to guest works.
• pinging from guest to router does NOT work.

When I stop the wifi and restart, the same occurs, but when I ping from guest to router, the pinging from host to router dies.

I have to stop/start the wifi, we go back to scenario 1.

It’s either the host can ping the router or the guest can ping the router, but not both at the same time.

If I leave the pinging running in the Guest, eventually the guest can ping, but the ping from host to router dies. After about 10-20 seconds, it goes visa-versa (the ping from guest to router dies, and the ping from host to router starts working again.

The ping from host to guest never has any problems.

comment:5 Changed 8 years ago by dportabella

I have the same issue on my Mac book air, OSX 10.8.4.

Any solution to this issue?

comment:6 Changed 8 years ago by drkn

Any update on this — or at least a workaround? Having an ethernet cable plugged in just for vbox is a pain.

comment:7 Changed 8 years ago by Oliver Drummond

Having the same problem, can only connect in Bridge Mode on my Mac if I use a cable connection. Any news about this?

comment:8 Changed 8 years ago by tmas

Hi, having the same issue on my macbook air. Any updates about this issue?

comment:9 Changed 8 years ago by lidaobing3

Any update on this — or at least a workaround?

comment:10 Changed 8 years ago by Os

Hi, I have a Macbook Air as host and having the same problem. Any update of using bridged adapters over WiFi ?

comment:11 Changed 8 years ago by phillipbarron

I have a MacBook Pro running Mavericks and have the same issue — I am running Virtual box on a Windows 7 machine too and have no problem bridging the Wireless network adaptor to the VM running Debian 6.0.6.

The problem then seems Mac specific — The Mac is my Main Dev machine and not being able to get an IP from the Wireless Adapter is a real headache. This support ticket is already 2 years old ! — I will submit another in the hope that someone will look again or, at the very least, respond. If this is not going to be fixed, please state that this is the case.

comment:12 Changed 8 years ago by obduk

So far I have found out this seems to be something to do with VirtualBox not working on mac os wirless when IPv6 is enabled, however following these instructions I have still not got it to work:

comment:13 Changed 8 years ago by cerberos

I have this problem with a new MBP with Mavericks running virtualbox 4.3.10, it’s not related to IPV6 as I’ve turned it off via

MBPs don’t have ethernet sockets any more so this is a major problem.

comment:14 Changed 8 years ago by cerberos

I setup some wireshark captures while running sudo dhclient eth0 -v with bridged ethernet and bridged wireless settings. There seems to be some duplicate packets that are issued with the mac address of the client then again with the mac address of the host, I don’t know if that’s correct or not. Here are the capture files.

comment:15 Changed 7 years ago by Ingmar

This is just to say «I have the same problem». I have e MBP 15″ Retina with Mavericks. I cannot connect from the host to the VM (where I run Fedora 20). I don’t know much about networking, but I have tried m best to follow the documentation, and follow various old advise on the internet. Nothing works. NAT always works fine, so I can connect from Fedora to the internet. I have tried pinging, with mixed results, at times I have been able to ping from Mavericks to Fedora, but have still not been able to connect via SSL or http. Very irritating, lots of hours spent to no avail. Banging on the MBP doesn’t help at all. Maybe more force will do the trick?

comment:16 Changed 7 years ago by VahidKowsari

I had the same problem and it seems to work in one wireless environment and not in another. For me it worked at home, while the same exact configuration didnt work at work.

The way I did get it to work is turn on my MBP Internet sharing on and share my Wifi, with the VirtualBox VM guests. I shared it using the Thunderbolt Bridge interface. Then in each of the guest OSes, I set Virtual Box to Bridge and use the bridge0 interface.

Hope that helps somebody else.

comment:17 Changed 7 years ago by Bezeker77

+1 On working @ my house and not working @ work . In my office selecting NAT works (Get Internet Connection) however Exchange server does not work as Reverse DNS is screwed up .

Would be great if VB would fix this issue

comment:18 follow-up: ↓ 19 Changed 7 years ago by vushakov

This should be partially fixed in 4.3.16.

Many wifi routers now try to use unicast link-level destination for broadcast/multicast IP destination. The reasons are explained in http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01 — that is in context of IPv6, but the same logic applies to IPv4 (IPv6 is hit harder since it relies more on multicast). Behavior varies between wifi routers, so you may get bridged setup working with some and not working with others.

If the wifi router that is not working for you just uses unicast delivery for multicast, then 4.3.16 should help (a typical packet capture can be seen in #12207). In this case the host was receiving DHCP replies intended for the guest (broadcast IP, but unicast to host MAC), but was not rewriting MAC address correctly, so the guest was not receiving the packet. If you plug another computer into the wired port of the router to capture DHCP exchange as seen on the wired side, you would see the same DHCP replies sent to ethernet broadcast on the wired connection. So this is just an optimization for wifi that some routers do.

Unfortunately — and this is orthogonal to multicast/unicast issue above — some routers will send DHCP replies to broadcast IP, but to the unicast client MAC address (i.e. guest MAC in this case) fetched from the DHCP request. These packets will never be even seen by the host. I’m afraid the packet captures in comment:14 is an example of that. In the ethernet capture you can see DHCP replies unicast to guest and in the wireless capture you don’t see any replies at all. I have one router like this (though it at least uses ethernet broadcast for its DHCP NAKs, so you can see something in the wireless capture :).

comment:19 in reply to: ↑ 18 Changed 7 years ago by vushakov

This should be partially fixed in 4.3.16.

Unfortunately — and this is orthogonal to multicast/unicast issue above — some routers will send DHCP replies to broadcast IP, but to the unicast client MAC address (i.e. guest MAC in this case) fetched from the DHCP request. These packets will never be even seen by the host. I’m afraid the packet captures in comment:14 is an example of that. In the ethernet capture you can see DHCP replies unicast to guest and in the wireless capture you don’t see any replies at all. I have one router like this (though it at least uses ethernet broadcast for its DHCP NAKs, so you can see something in the wireless capture :).

[Sorry, accidentally sent too early. ]

This latter kind of routers has problems with DHCP, but usually you can work around it by not using DHCP and using static IP instead. E.g. I cannot connect to that router of mine with DHCP, but if I use static IP in the guest then I get normal connectivity. Yes, this is suboptimal :(, but better than no connectivity if you must use bridged for some reason.

comment:20 follow-up: ↓ 21 Changed 6 years ago by stevenstromer

Unless I am mistaken regarding the issue here, simply allowing ip forwarding on the OSX host will resolve the issue:

sudo sysctl -w net.inet.ip.forwarding=1

comment:21 in reply to: ↑ 20 Changed 6 years ago by vushakov

Unless I am mistaken regarding the issue here, simply allowing ip forwarding on the OSX host will resolve the issue

No, bridged traffic doesn’t go through host’s routing.

comment:22 Changed 3 years ago by vladkd

It’s been 7 years. Any updates yet?

comment:23 Changed 3 years ago by vushakov

• Status changed from new to closed
• Resolution set to fixed

See comment:18 and comment:19 above. It’s a bug in the DHCP server in your AP/router.

comment:24 Changed 3 years ago by socratis

But, vushakov, is it actually a bug? If I’m not mistaken, the specification does not allow for Bridged-over-WiFi. If it happens, it’s because the AP/router’s manufacturers don’t actually follow the spec, but they relaxed it so that Bridged-over-WiFi is supported.

In other words, it’s not supposed to work, and if it does, it’s because someone didn’t follow the spec to the «T». Do I have it wrong?

comment:25 Changed 3 years ago by vushakov

Which specification do you mean?

I don’t think that IETF draft was ever promoted to something more binding, and it only talks about IPv6. Obviously AP manufacturers use similar optimizations for IPv4 too (for the same reasons), but there’s no official spec to follow.

Now, my memory is hazy, but the summary of what’s going on here is roughly like this:

• Guest sends DHCP request with its MAC in chaddr
• We tweak the packet to make sure the DHCP broadcast flag is set
• The packet is sent with hosts MAC as source (as all packets are with bridged-to-wifi)
• The server should reply with a broadcast, but tries to optimize and use unicast instead
• Correct optimization is to send unicast to the host’s MAC (source MAC of the DHCP request as seen by the server).
• Bad optimization is to send unicast to the MAC from chaddr (VM’s MAC).

The latter obviously doesn’t work as the packet never reaches the host and hence the guest.

Источник