I’ve tried both scenarios:
Bridge without an IP config
Bridge with IP config
Both does not work.
But in my opinion the second try was just wasted because it doesn’t make sense to me to configure the IP on the bridge and then on the VM again or only on the bridge, but then how would the vm know…
I have a similar setup, and I have found that the best way to handle this, is just to pay for additional public IP addresses. Did you ever get this working?
I just bought another IP for my hypervisor.
The pro side of this is, that even if you mess up you firewall config, you can still access your hypervisor and repair via console.
What I did to get mine working was to remove the ‘Default Gateway’ setting on my vmbr0 interface (management), and instead assigned it to vmbr1, so then my para-virtualized nic’s on VM’s are assigned under vmbr1 and appear as regular hosts on my network.
If you had another nic you could just assign it either directly to your guest vm or do para-virtualized so long as it connects to your network.
I took it one step further and assigned an active-backup bond to the vmbr1 for redundancy. Then at my pfsense router I forward all web traffic for a specific high-random-port exclusively from my haproxy on linode to my local haproxy on my network which is where I then perform SSL termination.
Then I on my local haproxy I have the config file maintained with salt stack so when I push changes to it my minion updates the config whenever it changes and perform a graceful reload.
So I run tons of shit behind my proxy.
Traffic looks like this:
internet -> haproxy (linode) -> wan -> haproxy (lan) -> services
But all traffic appears to clients as the haproxy on linode so it’s all obfuscated.