Solved Promiscuous mode along a bridge

Hello wise people,

I have a problem. I think a network related one.

I plan to put an Intrusion Detection System (a SELKS VM) among several bhyve VMs. They share the same bridge (bridgeLOCAL).

The problem is that it seems the IDS VM doesn't receive other packets than the ones specifically destined to it or the broadcast/multicast traffic (despite the tap is in promiscuous mode).

I tried to put the bridge itself in promiscuous mode but this has no effect (it actually displays the "PROMISC" option but nothing else changes).

So, the question is: how to do for a given tap to receive all the packets that flowing on the bridge?

Here is an example with a Windows 10 VM. SELKS do not receive the packets to or from this VM.

ifconfig
Code:
re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=82099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
        ether 44:8a:5b:59:8b:35
        inet 192.168.5.9 netmask 0xffffff00 broadcast 192.168.5.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
bridgeLOCAL: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 58:9c:fc:10:d2:2f
        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: tapWIN10 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 5 priority 128 path cost 2000000
        member: tapSELKS flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 4 priority 128 path cost 2000000
        member: re0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 1 priority 128 path cost 55
        groups: bridge
        nd6 options=9<PERFORMNUD,IFDISABLED>
tapSELKS: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        ether 58:9c:fc:10:d3:57
        groups: tap
        media: Ethernet autoselect
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        Opened by PID 1258
tapWIN10: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        ether 58:9c:fc:10:bf:2f
        groups: tap
        media: Ethernet autoselect
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        Opened by PID 1342
 
Reading the volumeous ifconfig(8), I had an idea:
Bridge Interface Parameters
The following parameters are specific to bridge interfaces:
(...)
discover interface
Mark an interface as a "discovering" interface. When the bridge
has no address cache entry (either dynamic or static) for the
destination address of a packet, the bridge will forward the
packet to all member interfaces marked as "discovering". This is
the default for all interfaces added to a bridge.
(...)
learn interface
Mark an interface as a "learning" interface. When a packet
arrives on such an interface, the source address of the packet is
entered into the address cache as being a destination address on
the interface's segment. This is the default for all interfaces
added to a bridge.

-learn interface
Clear the "learning" attribute on a member interface.

Would it be enough to clear the learning attribute on the tapSELKS? Or rather on all interfaces? This last will cause many useless traffic...
 
The problem is that it seems the IDS VM doesn't receive other packets than the ones specifically destined to it or the broadcast/multicast traffic (despite the tap is in promiscuous mode).
A bridge(4) acts the same as a switch not a hub. You can't read traffic to/from other hosts on a switch either. You typically put a switch port in a 'monitoring' or SPAN mode.
 
Yes, the span attribute seems to be the solution. I was knowing it was not that complicated.
I will try tonight.
 
Ok. That works but it's far more complex to setup than I was thinking.

First, you can't set this (any?) attribute once you addm the tap. You must span it directly instead: ifconfig bridgeLOCAL span tapSELKS.

Second, a span interface cannot be used to reach the VM. I had to create another tap in order to join the SELKS GUI. This implies not only to modify the bhyve command line but also the network configuration inside the VM.
 
Nevertheless, there is a problem with that span port.

I see only the layer 4 frames (tcp, udp ...). No arp and even no ICMP packets.

Yet, the handbook states (https://docs.freebsd.org/en/books/handbook/advanced-networking/#network-bridging):
span
A span port transmits a copy of every Ethernet frame received by the bridge. The number of span ports configured on a bridge is unlimited, but if an interface is designated as a span port, it cannot also be used as a regular bridge port. This is most useful for snooping a bridged network passively on another host connected to one of the span ports of the bridge.

Ethernet frame, unless I'm mistaking, it's layer 2 and therefore, I'm supposed to see arp and ICMP.

What's wrong here?
 
Nevertheless, there is a problem with that span port.

I see only the layer 4 frames (tcp, udp ...). No arp and even no ICMP packets.

Yet, the handbook states (https://docs.freebsd.org/en/books/handbook/advanced-networking/#network-bridging):


Ethernet frame, unless I'm mistaking, it's layer 2 and therefore, I'm supposed to see arp and ICMP.

What's wrong here?
Forget this post. If I can't see arp and ICMP packets, it's the SELKS tool fault (EveBox). I see them with tcpdump inside the SELKS VM.

Sorry for the noise.
 
Back
Top