I have a FreeBSD10 host with bhyve and the following IP-configuration in rc.conf:

ifconfig_igb0="inet X.X.X.146 netmask broadcast X.X.X.255"
ifconfig_bridge0="addm igb0 up"

The tap device gets added via the vmrc scripts. I have another IPv4 Address from my hoster which is in another subnet: Y.Y.Y.176. The hoster gives me the following guide to configure bridged-networking with this IP: Bridged Networking

According to this guide I configured the guest (FreeBSD10) like this (the hoster provides me with a "virtual MAC" for the IP):

ifconfig_vtnet0="inet Y.Y.Y.176 netmask ether 02:00:00:8c:46:32"
static_routes="net1 net2"
route_net1="-net X.X.X.254/32 Y.Y.Y.176"
route_net2="default X.X.X.254"

Before starting the VM I setup the bridge like this:

ifconfig bridge0 addm igb0 addm tap0 up

with tap0being the "host-side" of the VMs network adapter.

This does not work. I can't reach the gateway from within the VM and I can't reach the host from the VM. This makes sense to me, because there are no routes. It's unclear how this could even work.

You likely need to do:

ifconfig tap0 up

and/or add net.link.tap.up_on_open=1 to /etc/sysctl.conf to make it auto-up.

Normally, the tap interface doesn't come up until you give it an IP.

This should make the bridge work.

To configure the bridge in rc.conf:

cloned_interfaces="bridge0 tap0"
ifconfig_bridge0="addm igb0 addm tap0 up"

You also need:


in /boot/loader.conf so that tap can be created on the fly.

See the official instructions I wrote here.

  • Sorry I didn't mention it specifically - the bridge gets of course configured like you said. Question updated. Regarding the sysctl and the modules - I did that too. I followed the exact guide you're mentioning. If I route the subnet the "normal" way, I can get it to work - just the "use all IPs as host-addresses"-thing seems to make problems. – Subito Jun 25 '14 at 7:42

Even though the question is more than half a year old, since I just had the same problem

Don't configure your IP address on the physical member interfaces of the bridge but the bridge interface itself. This is mentioned in the FreeBSD handbooks section on bridging.

My understanding is that this is due to the way the packets are processed. if_bridge(4) covers some of it in the section about filtering.

up vote 0 down vote accepted

This did not solve, but rather circumvent the problem:

I assigned igb0 on the host all the IPs with a /32 network-mask, instead of the VMs and assigned bridge0 the private IP, the vtnet0 interface in the VM gets assigned with a default-gateway of and I create a binat using pf.

The rc.conf on the host looks like this:

ifconfig_igb0="inet X.X.X.146 netmask broadcast X.X.X.255"

ifconfig_igb0_alias0="inet Y.Y.Y.176/32"
ifconfig_igb0_alias1="inet Y.Y.Y.177/32"
ifconfig_igb0_alias2="inet Y.Y.Y.178/32"
ifconfig_igb0_alias3="inet Y.Y.Y.179/32"


And the pf.conf on the host:

vm_if1 = "Y.Y.Y.176"
vm_if2 = "Y.Y.Y.177"
vm_if3 = "Y.Y.Y.178"
vm_if4 = "Y.Y.Y.179"

slave = ""

binat on igb0 from $slave to any -> $vm_if1
nat on igb0 from bridge0:network to any -> (igb0)

The VMs rc.conf is really easy:

ifconfig_vtnet0=" netmask"

Now, whenever I provision a new VM, it needs a IP within the range and I need to adjust the hosts pf.conf.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.