OPN in a Proxmox VM, trying to spoof VM NIC to transparently relay to host NIC

[wrobelda]

(FYI, this is a cross-post from Proxmox forums, where I got no response: https://forum.proxmox.com/threads/trying-to-spoof-guest-nic-to-transparently-relay-to-host-nic.113600/#post-490741)

I am trying to set up OPNSense inside Proxmox. Unfortunately I cannot pass the interface as is, due to lack of IOMMU support, as I am running this in a nested Azure VM, so I need to get by using bridges.

The host configuration is:
– eth0
– vmbr0 with eth0 assigned to it

Code: [Select]

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet manual
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0
The guest configuration is:
– VirtIO NIC attached to vmbr0, with MAC overridden using same address as the eth0
– Firewall: NO
– MAC Filter: NO

Running dhclient on eth0 or vmbr0 correctly discovers and assigns an IP address.

Now, I am trying to get the OPNSense in a VM to get that IP address instead and to relay its traffic via the vmbr0 transparently outside of the host. I have done something very similar previously between OpenWRT running in a VM and another VM, using OpenWRT's "trivial relay" (kmod-trelay, see https://forum.openwrt.org/t/howto-kmod-trelay/49610/2, also https://github.com/openwrt/openwrt/commit/c3bba7f8c61ee98265bcffef8ee86e22aa89bbe9), and despite that this particular case is much simpler, I can't get the VM to communicate with the ISP properly. I tried simply by spoofing the eth0's MAC address by setting the OPNSense VM's interface to it, but that's not enough.

I also checked the traffic on both ends using tcpdump, and, interestingly, vmbr0 does see the DHCP requests coming from the VM, and the ISP does respond, but that response never reaches the VM, nor the tap interface corresponding to the VM that Proxmox assigned to the bridge.

What am I missing here?

[Maurice]

No experience with Proxmox, but my guess would be: Since the DHCP reply is addressed to the eth0 MAC address, the host claims it for itself and doesn't forward it to the VirtIO NIC. Changing the eth0 MAC address to something random might work.

Cheers
Maurice

[wrobelda]

No experience with Proxmox, but my guess would be: Since the DHCP reply is addressed to the eth0 MAC address, the host claims it for itself and doesn't forward it to the VirtIO NIC. Changing the eth0 MAC address to something random might work.

Thanks, but rather unlikely: eth0 on host is configured to 'manual', that is not to use DHCP on that interface. And it doesn't, because ISP keeps sending DHCPOFFERs and they do not get picked up — the eth0 on host is left untouched.

[Maurice]

"Claims it" on layer 2 only. If the destination MAC address in incoming frames belongs to the host, why should it forward these frames? Of course it then just discards the DHCP reply which it didn't request.

[wrobelda]

Well, that makes sense, but I won't be able to change host's MAC address, as this is not something I can pull off with Azure.

[wrobelda]

why should it forward these frames

But also setting the interface/bridge to promiscuous should lift any such restrictions, yet that didn't help, either.

[wrobelda]

(nvm)