So… imagine you have a KVM host, set up with a public bridge on eth0 as described on the Debian wiki. The configuration seems to match exactly; yet when the bridge starts, connectivity is lost on the host. So although the guest VM is able to ping out to say; Google, the host has no outbound connection.
After a complete red herring involving this host being connected to a TL-WR702N wireless bridge; (does this mean I need to rewrite the MAC address of my VM?) and a digression into ebtables – I finally struck gold with the output of ip route which showed me that both the bridge (in my case kbeth0) and my physical adapter (etho) had the same IP.
That can’t be right! Makes you think about how you were so intent on this machine having LUKS encryption; but wanted to be able to shove it in a cupboard and decrypt remotely through ssh. And so when the machine boots off the initrd I start up a dropbear ssh server; assigning a static IP via the grub command line; and how perhaps that assignment persists after the disk has been decrypted and kbeth0 comes up.
Turns out; adding an ip addr flush dev eth0 to the end of /etc/rc.local (just before the exit 0) means that kbeth0 is able to come up with the right ip address; having taken it off eth0 – and all is right with the world once again. And – no need to fiddle about with ebtables.
I can’t say i’m entirely sure of this hypothesis; but it seems to work – and now I can decrypt on boot remotely; while still bridging my network adapter to run virtual machines in KVM.