Bridge connections to VM

Started by devl_ish, May 22, 2025, 09:07:25 AM

Previous topic - Next topic
Hi - been following this guide: "HOWTO: Setup OpenWRT Virtual Machine on OPNsense and use it to manage a WiFi AP" - https://forum.opnsense.org/index.php?topic=34034.15 so I could get better control of an Intel BE200.

Everything worked except for the bridged network - I can't ping the host from guest or vice versa:

1. I have a VLAN set up for access points (currently Dumb AP through a managed switch). For step 2 of the guide I used this as the member interface. As this is not a physical device could this be the source of the problem?

2. I'm using DNSMasq DHCP where the guide uses DHCPD. Any possible causes (i.e. things I may have overlooked using a different DHCP server)?

I've looked around for a guide for troubleshooting bridging and have run through the guide sequence a few times but I'm stuck. Unstick me?

Quote from: devl_ish on May 22, 2025, 09:07:25 AMI have a VLAN set up for access points (currently Dumb AP through a managed switch). For step 2 of the guide I used this as the member interface. As this is not a physical device could this be the source of the problem?

No - this is how it is supposed to be done.

Did you

- move the Interface assignment from the VLAN interface to the bridge interface (Interfaces > Assignments)?
- activate the two mandatory tunables that are documented in step 6?

?

Both steps are not optional.

Kind regards,
Patrick
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

May 22, 2025, 10:12:40 AM #2 Last Edit: May 22, 2025, 10:30:10 AM by devl_ish
Yes and yes (I think):






(damn, I screenshotted and posted to imgbb but doesn't appear to be showing up -

https://ibb.co/whw2LgbQ
https://ibb.co/yF9ttw6b
https://ibb.co/V09nVCj0

More detail - I've used a different subnet to the example - 10.10.9.0/24 - and the ip on the bridge is 10.10.9.1.

Host ifconfig:

bridge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: VM_BRIDGE (opt11)
options=0
ether 58:9c:fc:10:6c:3f
inet 10.10.9.1 netmask 0xffffffff broadcast 10.10.9.1
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: tap0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        ifmaxaddr 0 port 17 priority 128 path cost 2000000
member: vlan0.1.10 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        ifmaxaddr 0 port 9 priority 128 path cost 20000
member: vlan0.1.50 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        ifmaxaddr 0 port 13 priority 128 path cost 20000
groups: bridge vm-switch viid-4c918@
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
tap0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: vmnet/openwrt/0/public
options=4080000<LINKSTATE,MEXTPG>
ether 58:9c:fc:10:df:73
groups: tap vm-port
media: Ethernet 1000baseT <full-duplex>
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Opened by PID 24286


Host: VM Switch list:

NAME    TYPE    IFACE    ADDRESS  PRIVATE  MTU  VLAN  PORTS
public  manual  bridge0  n/a      no       n/a  n/a   n/a
(IP address n/a showing - weird?)

Guest ifconfig output:

root@OpenWrt:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr 58:9C:FC:0F:8F:E8 
          inet addr:10.10.9.130  Bcast:10.10.9.255  Mask:255.255.255.0
          inet6 addr: fe80::5a9c:fcff:fe0f:8fe8/64 Scope:Link
          inet6 addr: fdeb:7e23:77e1::1/60 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:280 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:12472 (12.1 KiB)

eth0      Link encap:Ethernet  HWaddr 58:9C:FC:0F:8F:E8 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:140 errors:0 dropped:0 overruns:0 frame:0
          TX packets:547 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8168 (7.9 KiB)  TX bytes:38830 (37.9 KiB)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:367 errors:0 dropped:0 overruns:0 frame:0
          TX packets:367 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:35344 (34.5 KiB)  TX bytes:35344 (34.5 KiB)


Guest /etc/config/network:

root@OpenWrt:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdeb:7e23:77e1::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '10.10.9.130/24'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option gateway '10.10.9.1'
        option dns '10.10.9.1






Just looked at the firewall logs and I've found a bunch of these:

Detailed rule info
__timestamp__ 2025-05-23T16:30:30
action [block]
anchorname
datalen 308
dir [in]
dst 255.255.255.255
dstport 67
ecn
id 0
interface tap0
interface_name tap0
ipflags none
ipversion 4
label Default deny / state violation rule
length 328
offset 0
protoname udp
protonum 17
reason match
rid 02f4bab031b57d1e30553ce08e0ec131
rulenr 10
src 0.0.0.0
srcport 68
subrulenr
tos 0x0
ttl 64

I can see the tap0 interface on ifconfig and in the devices->overview page as an "unassigned interface" but I can't assign it, so I can't write a rule for the firewall to pass all tap0 traffic to see if that's what's blocking my ping and DHCP queries. Is there any way to check whether the bridge is otherwise working?

You can't attach images in "quick reply". You can with reply or after preview.

I'm no expert on these but I don't believe bridging 2 separate vlan devices with different VLAN IDs is legit.
Physical device + vlan_deviceN parented to other physical devices, bridging untagged and tagged ports for 1 VLAN.
I assume physical device could also be a tap.

FW rules are at interface level, for the entire bridge.
Could be a consequence of the config problem above. Or the bridge tunables.

Not being able to assign the tap interface and place firewall rules on it is also perfectly as it should be. With the two tunables set correctly no filtering on the tap interface should take place.

No time to dig deeper just right now, sorry.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: EricPerl on May 23, 2025, 10:35:49 PMYou can't attach images in "quick reply". You can with reply or after preview.



Thanks - its been ages since I've posted on any forum!

Quote from: EricPerl on May 23, 2025, 10:35:49 PMI'm no expert on these but I don't believe bridging 2 separate vlan devices with different VLAN IDs is legit.
Physical device + vlan_deviceN parented to other physical devices, bridging untagged and tagged ports for 1 VLAN.
I assume physical device could also be a tap.

FW rules are at interface level, for the entire bridge.
Could be a consequence of the config problem above. Or the bridge tunables.


I thought about that and pulled membership of both VLANs and made igc0 (physical LAN port) a member to test - no change in behaviour.

Quote from: Patrick M. Hausen on May 23, 2025, 10:41:15 PMNot being able to assign the tap interface and place firewall rules on it is also perfectly as it should be. With the two tunables set correctly no filtering on the tap interface should take place.

No time to dig deeper just right now, sorry.

No worries, thanks for giving it a go!

About the "no filtering on the tap interface" - I see a few of these in the log:

2025-05-23T17:02:31 Informational filterlog 10,,,02f4bab031b57d1e30553ce08e0ec131,tap0,match,block,in,4,0x0,,64,0,0,none,17,udp,328,0.0.0.0,255.255.255.255,68,67,308

That seems to suggest there is some filtering going on which is odd.

I'm also having trouble with a NAT port forward that as far as I can see should work but doesn't (nothing in the logs but passes) so before I try anything else I'm going to back up settings, reflash the router and try just the things that aren't working right now (that's OK as this is my first go at Opnsense, decent learning exercise and maybe I poked something in the process).

Any filtering on a member interface implies that the tunables from step 6 of the bridge documentation are not set.
Literally, disable filtering on members, enable filtering on bridge.

There are a few threads about bridges over VLAN devices (the opposite does not work).
You should be able to bridge:
* physical device
* VLAN devices (parented to other physical devices)
* virtual device like tap

As I understand it, the bridge knowns nothing about VLANs. All tagging happens at the device level.
Additional constraints:
Bridge members must not have IP addresses.
If a physical device is a member of a bridge, it cannot be a parent for a vlan device.

OPNsense VM (for OpenWRT) + bridging + VLAN is not exactly noob material.
I have experimented with the latter but avoid it in production.

When dealing with such topics, I suggest you test often and increase complexity when the previous steps check out.
For example, get the VM going as the sole AP on the interface (assign interface to tap or assign interface to bridge over tap), then bridge with a physical device.
Test with AP connected to interface assigned to VLAN device (i.e. validate switch config).
Then combine.

Quote from: EricPerl on May 24, 2025, 11:25:19 PMAny filtering on a member interface implies that the tunables from step 6 of the bridge documentation are not set.
Literally, disable filtering on members, enable filtering on bridge.

That's what's confusing me, tunables are definitely set in the GUI-
net.link.bridge.pfil_member runtime 0 1 Set to 0 to disable filtering on the incoming and outgoing member interfaces.
net.link.bridge.pfil_bridge runtime 1 0 Set to 1 to enable filtering on the br


Quote from: EricPerl on May 24, 2025, 11:25:19 PMThere are a few threads about bridges over VLAN devices (the opposite does not work).
You should be able to bridge:
* physical device
* VLAN devices (parented to other physical devices)
* virtual device like tap

As I understand it, the bridge knowns nothing about VLANs. All tagging happens at the device level.
Additional constraints:

Bridge members must not have IP addresses.

Check - have changed IPv4 config to "none" on all attempts.

Quote from: EricPerl on May 24, 2025, 11:25:19 PMIf a physical device is a member of a bridge, it cannot be a parent for a vlan device.

Wasn't aware of that, I had two other VLANs configured on that parent. Deleted them, no change though.

Quote from: EricPerl on May 24, 2025, 11:25:19 PMOPNsense VM (for OpenWRT) + bridging + VLAN is not exactly noob material.
I have experimented with the latter but avoid it in production.

I hear ya, but its a useful combination, and I'm up for the experimenting. If I can't solve this in a day or so I'll just use another AP. I started to look into this option because the AP I have lying around - Asus AC59u - doesn't have OpenWRT support for the 2.4ghz radio, just the 5ghz (although a legendary contributor did put up a patch last month to work with it on another similar router, I just don't have the skills to do my own patched build yet)


Quote from: EricPerl on May 24, 2025, 11:25:19 PMWhen dealing with such topics, I suggest you test often and increase complexity when the previous steps check out.
For example, get the VM going as the sole AP on the interface (assign interface to tap or assign interface to bridge over tap), then bridge with a physical device.
Test with AP connected to interface assigned to VLAN device (i.e. validate switch config).
Then combine.


Definitely great advice. I'll be starting over first trying to get the port forward I need going, then the OpenWRT VM, and then build out the network from there. My home network is currently a free-for-all with my docker server sharing the same network with NAS and a bunch of tuya devices through a consumer router and no firewall, so this is my attempt at being a little less of a ransomware/data theft dream lol.

Maybe if the bridge is not setup/functioning properly, the device might not be considered a member of a bridge and still be subject to filtering.

Quote from: devl_ish on May 25, 2025, 09:32:04 AM...
Quote from: EricPerl on May 24, 2025, 11:25:19 PMIf a physical device is a member of a bridge, it cannot be a parent for a vlan device.
Wasn't aware of that, I had two other VLANs configured on that parent. Deleted them, no change though.
You misunderstood.
If you have bridge0 with igb0 as member
Then you can't have bridge1 with vlan0.1 (where vlan0.1 is parented to igb0) as member

This is not a limitation on number of vlans on a single physical device and whether you can bridge them (which would severely cripple such bridging).
It's a limitation on mixing bridging on the physical device and bridging on vlans parented to that same physical device. 

Quote from: EricPerl on May 25, 2025, 09:53:00 PMMaybe if the bridge is not setup/functioning properly, the device might not be considered a member of a bridge and still be subject to filtering.

Quote from: devl_ish on May 25, 2025, 09:32:04 AM...
Quote from: EricPerl on May 24, 2025, 11:25:19 PMIf a physical device is a member of a bridge, it cannot be a parent for a vlan device.
Wasn't aware of that, I had two other VLANs configured on that parent. Deleted them, no change though.
You misunderstood.
If you have bridge0 with igb0 as member
Then you can't have bridge1 with vlan0.1 (where vlan0.1 is parented to igb0) as member

This is not a limitation on number of vlans on a single physical device and whether you can bridge them (which would severely cripple such bridging).
It's a limitation on mixing bridging on the physical device and bridging on vlans parented to that same physical device.


Thanks, I did misunderstand but it didn't end up making a difference.

I'm sorry to say I never did work this out - I went to Proxmox instead for VM and bridging.

Thanks for the attempts, I learned a lot even if we didn't get to the bottom of it.