Page MenuHomeVyOS Platform
Create Task
Maniphest T7150

Traffic marked invalid on bridge member interfaces
Open, HighPublicBUG
Actions

Description

After upgrading from vyos-1.5-rolling-202406060020 to vyos-1.5-rolling-202502030007 some traffic flowing trough a bridged interface is marked as invalid by the global state policy.

This seems to be a known issue and is related to the following bug reports:

There seems to be a workaround to just accept a hard coded list of ethertypes to make some protocols (ARP, DHCP and PPPoE) work again:
set firewall global-options apply-to-bridged-traffic invalid-connections

This option just adds a few accepts to the output chain:

	chain VYOS_OUTPUT_filter {
		type filter hook output priority filter; policy accept;
		ct state invalid udp sport 67 udp dport 68 counter packets 2 bytes 668 accept
		ct state invalid ether type arp counter packets 0 bytes 0 accept
		ct state invalid ether type 0x8864 counter packets 0 bytes 0 accept
		jump VYOS_STATE_POLICY
		counter packets 887 bytes 71809 accept comment "OUT-filter default-action accept"
	}

However changing this setting does not work in my case, as ARP Traffic is still blocked (6a:c0:93:XX:XX:XX is the vyos bridge interface MAC):

[STATE-POLICY-INV-D]IN= OUT=eth0 ARP HTYPE=1 PTYPE=0x0800 OPCODE=2 MACSRC=6a:c0:93:XX:XX:XX IPSRC=192.168.40.1 MACDST=14:13:33:XX:XX:XX IPDST=192.168.40.80
[STATE-POLICY-INV-D]IN= OUT=eth1 ARP HTYPE=1 PTYPE=0x0800 OPCODE=1 MACSRC=6a:c0:93:XX:XX:XX IPSRC=192.168.99.1 MACDST=00:00:00:00:00:00 IPDST=192.168.99.12
[STATE-POLICY-INV-D]IN= OUT=eth0 ARP HTYPE=1 PTYPE=0x0800 OPCODE=1 MACSRC=6a:c0:93:XX:XX:XX IPSRC=192.168.99.1 MACDST=00:00:00:00:00:00 IPDST=192.168.99.12

Even when removing the invalid state policy completely, some traffic does not work. ARP, DHCP and PPPoE work when the invalid state policy is removed, but some things like RADIUS cannot leave the firewall for some unkown reason. Tcpdump shows the traffic "leaving" the firewall (there are no drops in the firewall log), but the Access-Challenge is never received on the client side:

20:37:02.069597 IP 192.168.99.21.60581 > 192.168.1.20.1812: RADIUS, Access-Request (1), id: 0x74 length: 371
20:37:02.070250 IP 192.168.1.20.1812 > 192.168.99.21.60581: RADIUS, Access-Challenge (11), id: 0x74 length: 64

The same setup worked fine with 202406060020 and is using a simple bridge setup with two member interfaces which have a couple of VLANs on them. The bridge is configured like this:

set interfaces bridge br0 disable-flow-control
set interfaces bridge br0 ip source-validation strict
set interfaces bridge br0 member interface eth0
set interfaces bridge br0 member interface eth1
set interfaces bridge br0 member interface eth0 allowed-vlan 11
set interfaces bridge br0 member interface eth1 allowed-vlan 11
set interfaces bridge br0 stp
set interfaces bridge br0 enable-vlan

set interfaces bridge br0 vif 11 address 192.168.20.1/24
set interfaces bridge br0 vif 11 ip source-validation strict
set interfaces bridge br0 vif 11 mtu 1500

Details

Version
vyos-1.5-rolling-202502030007
Is it a breaking change?
Perfectly compatible
Issue type
Bug (incorrect behavior)

Related Objects

Event Timeline

andrin created this task.Feb 9 2025, 4:53 PM
dmbaturin triaged this task as High priority.Feb 17 2025, 2:52 PM
dmbaturin changed Is it a breaking change? from Unspecified (possibly destroys the router) to Perfectly compatible.
pasik subscribed.Feb 17 2025, 6:40 PM
woodsb02 subscribed.Mar 25 2025, 10:37 AM
andrin added a comment.Mar 26 2025, 7:23 PM

Just to add a little more information:
This does not happen on vyos-1.5-stream-2025-Q1 (although this release also has issues regarding the state policy: https://forum.vyos.io/t/have-to-delete-firewall-global-options-state-policy-invalid-after-upgrading-to-1-5-stream-2025-q1/16131/7)

I suspect this change has something to do with the issue: https://github.com/vyos/vyos-1x/pull/3901

sarthurdev subscribed.Mar 26 2025, 7:50 PM
andrin added a comment.Aug 8 2025, 1:04 PM

Retested with VyOS Stream 1.5-2025-Q2:
Ignoring invalid states for certain protocols was necessary to get most of the traffic working working again on bridges:

set firewall global-options apply-to-bridged-traffic accept-invalid ethernet-type dhcp
set firewall global-options apply-to-bridged-traffic accept-invalid ethernet-type arp
set firewall global-options apply-to-bridged-traffic accept-invalid ethernet-type pppoe
set firewall global-options apply-to-bridged-traffic accept-invalid ethernet-type pppoe-discovery
set firewall global-options apply-to-bridged-traffic accept-invalid ethernet-type 802.1q
set firewall global-options apply-to-bridged-traffic accept-invalid ethernet-type wol

However still some traffic got blocked, like for example if spanning tree is enabled on a bridge:

[STATE-POLICY-INV-D]IN= OUT=eth1 MAC=01:80:c2:00:00:00:XX:XX:XX:XX:XX:01:00:07 
[STATE-POLICY-INV-D]IN= OUT=eth0 MAC=01:80:c2:00:00:00:XX:XX:XX:XX:XX:02:00:26

However the bigger issue is, that radius is still not working. The device does not get a reply from the server. The firewall log does not show anything.