Hi, I’ve read several discussions on the forum where users misuse the use-ip-firewall setting and bridges. That’s not my case here, this is disabled and not wanted, but still the weirdest thing is happening as I get bridged traffic reach the forward table in the firewall!
For now I believe this must be a misconfiguration rather than a bug, but there’s so little config in bridges that I can’t figure what to try.
Platform:
- board-name: CCR2004-16G-2S+
- version: 7.14.3 (stable)
- factory-software: 7.0.4
I’ve also tried 7.15rc2 and 7.13.5, same issue.
But I’m sure this problem did not exist in the past, about 1 or 2 years ago.
Config:
I only removed L3 and firewalling stuff, some ethernet interfaces.
/interface ethernet
set [ find default-name=ether9 ] name="ether9 (xxxx)"
set [ find default-name=ether10 ] name="ether10 (xxxx)"
set [ find default-name=sfp-sfpplus2 ] arp=disabled name="sfp-sfpplus2 (xxxx)"
/interface bridge
add arp=disabled frame-types=admit-only-vlan-tagged name=bridge port-cost-mode=short protocol-mode=none vlan-filtering=yes
add arp=disabled name=loopback protocol-mode=none
/interface bridge vlan
add bridge=bridge tagged="bridge,sfp-sfpplus2 (xxxx),ether1 (xxxx),ether4 (xxxx)" vlan-ids=10
add bridge=bridge tagged="bridge,sfp-sfpplus2 (xxxx),ether1 (xxxx)" vlan-ids=11
add bridge=bridge tagged="bridge,sfp-sfpplus2 (xxxx),ether1 (xxxx)" vlan-ids=12
add bridge=bridge tagged="bridge,sfp-sfpplus2 (xxxx)" vlan-ids=13
add bridge=bridge tagged="bridge,sfp-sfpplus2 (xxxx),ether1 (xxxx)" vlan-ids=14
add bridge=bridge tagged="bridge,sfp-sfpplus2 (xxxx)" vlan-ids=18
add bridge=bridge tagged="bridge,ether4 (xxxx)" vlan-ids=192
/interface bridge port
add bridge=bridge frame-types=admit-only-vlan-tagged interface="sfp-sfpplus2 (xxxx)" internal-path-cost=10 path-cost=10
add bridge=bridge frame-types=admit-only-vlan-tagged interface="ether1 (xxxx)" internal-path-cost=10 path-cost=10
add bridge=bridge frame-types=admit-only-vlan-tagged interface="ether4 (xxxx)" internal-path-cost=10 path-cost=10
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface="ether3 (xxxx)" internal-path-cost=10 path-cost=10 pvid=11
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface="ether9 (xxxx)" internal-path-cost=10 path-cost=10 pvid=13
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface="ether10 (xxxx)" internal-path-cost=10 path-cost=10 pvid=13
add bridge=bridge interface="ether6 (xxxx)" pvid=11
/interface vlan
add interface=bridge name=vlan10 vlan-id=10
add interface=bridge name=vlan11 vlan-id=11
add interface=bridge name=vlan12 vlan-id=12
add interface=bridge name=vlan13 vlan-id=13
add interface=bridge name=vlan14 vlan-id=14
add interface=bridge name=vlan15 vlan-id=18
add interface=bridge mtu=1480 name=xxxx vlan-id=192
/ip settings
set rp-filter=strict secure-redirects=no
/ipv6 settings
set accept-redirects=no accept-router-advertisements=no
/ip firewall connection tracking
set enabled=yes loose-tcp-tracking=no udp-timeout=10s
Issue:
The problem is with three members of the bridge: ether9, ether10, and sfp-sfpplus2
They are tied to vlan 13, tagged on the SFP and untagged on others.
Also there is a vlan13 vlan interface on top of the bridge for routing, as this box is the gateway for 13.
Communication between ether9 and ether10 seem to be bridged properly and do not go through the firewall. Bridge ports even have the HW offload.
But all flows between sfp-sfpplus2 and those two other ports will hit the firewall. Logs show the same input and output interface :
12:24:24 firewall,info BROKEN forward: in:vlan13 out:vlan13, connection-state:new src-mac xx:xx:xx:xx:xx:xx, proto TCP (SYN), 10.x.x.x:39274->10.x.x.x:443, len 60
What I’ve checked:
- use-ip-firewall=no of course
- no IP or MAC conflict
- no interface with arp proxy
- disabling vlan interface vlan13 does not fix it
- /interface/bridge/host looks good
I’m considering downgrading even further but that’s inconvenient at the moment.
What would you suggest checking? Am I doing anything wrong?
How likely can this be a bug given that sfp-sfpplus2 is a CPU port without a switch chip?
Thanks a lot folks
Have a great day