<div dir="ltr">Hi,<br><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 4:53 PM, Klaus Espenlaub <span dir="ltr"><<a href="mailto:klaus.espenlaub@oracle.com" target="_blank">klaus.espenlaub@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hi Maarten,<span class=""><br>
    <br>
    <div>On 06.08.2015 15:18, Maarten Hoes
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Hi,<br>
          <br>
          <br>
          Well I finally figured it out. On my ISP's wifi modem/router,
          there is a setting called 'DHCP Binding'. This can be used to
          make sure that a certain MAC always gets the same IP address
          assigned through DHCP. (essentially creating a DHCP scope of 1
          single IP and 1 single MAC).<br>
          <br>
          When I enable this for a bridged host, reaching the default
          gateway becomes impossible. I verified the MAC both in the VM
          settings as in the guest os, and made sure that they match the
          'DHCP Binding' settings on the modem/router. As soon as I
          remove the entry from the modem/router and restart the guest,
          networking resumes as expected.<br>
          <br>
        </div>
        I had this setting enabled for the 'old' VM's, but not for the
        newly created ones; which explains the difference in behavior.<br>
        <div><br>
          Now what I dont understand is why such a setting should/does
          break bridged to wifi networking - especially when at the same
          time NAT does work as expected with that setting enabled.<br>
        </div>
      </div>
    </blockquote></span>
    Taking a deep breath... let's start with the most surprising piece
    of information for most people. Bridged to wifi actually isn't
    deserving the name "bridging" at all. Bridging happens at the
    Ethernet level, and with wifi that's not possible as 99% of the wifi
    cards out there simply don't support promisc mode (which VirtualBox
    uses for sending/receiving packets with the guest's MAC address).<br>
    <br>
    What "bridged to wifi" implements is a funky routing scheme, packet
    filtering/suppression and some packet content rewriting. It entirely
    shares the host's MAC address (and uses the guest's IP address for
    actually filtering the traffic it needs to receive, so the host's IP
    stack must not see the packets targeted at the guest and vice
    versa), and convinces the wifi router's DHCP server to give out a
    lease for each VM (which I guess is where your solution exploded)
    even though the MAC address "on the wire" is always the host's. The
    final step is to translate the host's MAC address to the guest's and
    when the packets are passed to/from the VM.<br>
    <br>
    Klaus<br></div></blockquote><div><br><br>Thank you for taking the time to elaborate/clarify. It's appreciated. I guess what had me fooled is the fact that the bridged guest's MAC/IP combo's show up in the DHCP lease list on the wifi modem/router.<br><br></div><div>Anyway, I guess I now have a bug to close.<br><br></div><div>Thanks again,<br><br></div><div><br>- Maarten.<br><br></div></div><br></div></div>