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:
- ⚓ T6647 Zone-based Firewalls on Bridges would flag related DHCP traffic invalid
- ⚓ T6951 Add a configuration command for ethertypes that bridge firewalls should always accept
- ⚓ T6918 pppoe traffic is classified as invalid
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
Since there seems to be an underlying issue with the connection tracking on bridge member interfaces, can someone elaborate why this happens and is there a proper fix in the works?