SOLVED Tagged traffic not copied to a bridge interface

[asimov-solensan]

Hello,

So I have got a question that I have no way to solve. Basically I have got a pfsense firewall virtualized in bhyve. It uses the physical interface em2 as a trunk interface (using a bridge interface, no hardware bypass in any way).

My intention is to access the same freenas and other jails or virtual machines through this same interface and managed by the firewall.

Therefore I have go this tagged vlan on the same interface em2.

Code:

bridge200: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
		ether 02:c8:7a:06:44:c8
		nd6 options=9<PERFORMNUD,IFDISABLED>
		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: em2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
				ifmaxaddr 0 port 4 priority 128 path cost 2000000
		member: tap200 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
				ifmaxaddr 0 port 9 priority 128 path cost 2000000

tap200 is obviously the pfsense interface

Now I check that the interface I'm testing is alive, this will be the gateway for this specific vlan.

Code:

[root@charcoal openvpn]# ping 192.168.17.1
PING 192.168.17.1 (192.168.17.1) 56(84) bytes of data.
64 bytes from 192.168.17.1: icmp_seq=1 ttl=64 time=4.64 ms
64 bytes from 192.168.17.1: icmp_seq=2 ttl=64 time=3.48 ms

And check that the vlan interface is correctly created.

Code:

vlan17: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
		ether 00:15:17:2e:65:a3
		inet 192.168.17.10 netmask 0xffffff00 broadcast 192.168.17.255
		nd6 options=9<PERFORMNUD,IFDISABLED>
		media: Ethernet autoselect (1000baseT <full-duplex>)
		status: active
		vlan: 17 parent interface: em2

Then from freenas I try to ping this interface. Remember that this will go tagged to a trunk interface should see it and then the specific interface will just answer the ARP request.
Therefore first step ping from freenas.

Code:

[root@lavochkin] ~# ping 192.168.17.1
PING 192.168.17.1 (192.168.17.1): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down

Well nobody answers, let's check the output interface:

Code:

[root@lavochkin] ~# tcpdump -n -i vlan17 -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode																				   
listening on vlan17, link-type EN10MB (Ethernet), capture size 65535 bytes																				   
19:03:39.769033 00:15:17:2e:65:a3 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 46: 192.168.17.10 > 224.0.0.251: igmp v2 report 224.0.0.251		   
19:03:39.769044 00:15:17:2e:65:a3 > 01:00:5e:00:00:02, ethertype IPv4 (0x0800), length 46: 192.168.17.10 > 224.0.0.2: igmp leave 224.0.0.251				 
19:03:40.229960 00:15:17:2e:65:a3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.17.1 tell 192.168.17.10, length 28		 
19:03:41.231801 00:15:17:2e:65:a3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.17.1 tell 192.168.17.10, length 28		 
19:03:42.232643 00:15:17:2e:65:a3 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.17.1 tell 192.168.17.10, length 28		 

Everything ok here, we have got the rquest although not tagged. Now let's check the physical interface.

Code:

[root@lavochkin] ~# tcpdump -n -i em2 -e | grep 192.168.17.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em2, link-type EN10MB (Ethernet), capture size 65535 bytes
19:48:56.317864 00:15:17:2e:65:a3 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 17, p 0, ethertype ARP, Request who-has 192.168.17.1 tell 192.168.17.10, length 28
19:48:57.319704 00:15:17:2e:65:a3 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 17, p 0, ethertype ARP, Request who-has 192.168.17.1 tell 192.168.17.10, length 28
19:48:58.321556 00:15:17:2e:65:a3 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 17, p 0, ethertype ARP, Request who-has 192.168.17.1 tell 192.168.17.10, length 28
19:48:59.323337 00:15:17:2e:65:a3 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 17, p 0, ethertype ARP, Request who-has 192.168.17.1 tell 192.168.17.10, length 28

Nice! Our request is here, now tagged as I expected. But still remember that my intention is to have this traffic in the interface tap200 which is the one attached to my pfsense. Therefor next thing to check is the bridge that includes em2 and tap200.

Code:

root@lavochkin] ~# tcpdump -n -i bridge200 -e | grep 192.168.17.10
tcpdump: WARNING: bridge200: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bridge200, link-type EN10MB (Ethernet), capture size 65535 bytes

And sadly this is where things end. The traffic from vlan17 is not present in bridge200 although it's clearly present in em2.

I guess this is the hardcoded behaviour. This completely screws my plan. Is there a way to pass tagged traffic to a bridge interface?

i know this may be a complex question, and I don't want anyone to understand the full question, just why the traffic of a vlan interface isn't present in a bridge associated to the same interface.

Thanks in advance.

 

[asimov-solensan]

Well I just took a rest and the solution came to me.

The same post explain where the problem is. If the tap200 is created it can just be added to freenas and then configure the vlan in this interface. Since pfsense is also attached to it the communication just works. It doesn't really matter now if the traffic is in the bridge or not.

Seems that I was just obfuscated after many hours working in this.