DSA and Firewall zones not properly respected in 21.02.1

Hi,

I'm in process of migrating from older 19.07 version to 21.02.1 - which requires me to also convert to DSA.

I've been playing around, and seem to have found an issue whereas an isolated VLAN STB is able to still reach LAN network, despite Firewall doesn't have any configuration to allow STB VLAN to be allowed to forward traffic other than WAN zone.

network

config interface 'lan'
	option device 'br-switch0.1'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option igmp_snooping '1'
	option stp '1'

config interface 'wan'
	option proto 'dhcp'
	option ipv6 '0'
	option device 'eth0'

config interface 'wan6'
	option device 'eth0'
	option proto 'dhcpv6'

config interface 'stb'
	option device 'br-switch0.9'
	option proto 'static'
	option ipaddr '192.168.168.254'
	option netmask '255.255.255.0'
	option igmp_snooping '1'
	option stp '1'

config device
	option name 'switch0'
	option type 'bridge'
	list ports 'eth1'
	list ports 'eth2'
	list ports 'eth3'
	list ports 'eth4'

config bridge-vlan
	option device 'br-switch0'
	option vlan '1'
	list ports 'eth1:u*'
	list ports 'eth2:u*'
	list ports 'eth3:u*'
	list ports 'eth4:t'

config bridge-vlan
	option device 'br-switch0'
	option vlan '9'
	list ports 'eth4:t'

config bridge-vlan
	option device 'br-switch0'
	option vlan '10'
	list ports 'eth4:u*'

firewall

config zone
	option name 'lan'
	option network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'stb'
	option network 'stb'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	option network 'wan wan6'

config forwarding
	option src 'lan'
	option dest 'wan'

config forwarding
	option src 'stb'
	option dest 'wan'

Btw, another issue to prevent VLAN leaking, is to put a bogus VLAN (10) here as untagged on the trunk port. Otherwise, despite VLAN being tagged, it becomes untagged on the trunk port.

Anyways, hoping someone can shed some light on interface vs firewall zone config and why I am able to go from STB --> LAN and not from LAN --> STB.

At first glance there are disparities between the bridge device name, and the name used in the bridge vlan filtering sections.

It should be

config device
	option name 'switch0'

config bridge-vlan
	option device 'switch0'

or

config device
	option name 'br-switch0'

config bridge-vlan
	option device 'br-switch0'

Also install the ip-bridge package and run bridge vlan to check the current VLAN status.

Thanks, and well noticed.
Corrected switch0 --> br-switch0.
Installed ip-bridge package, here's vlan output after a reboot:

bridge vlan
port              vlan-id
eth1              1 PVID Egress Untagged
eth2              1 PVID Egress Untagged
eth3              1 PVID Egress Untagged
eth4              1
                  9
                  10 PVID Egress Untagged
br-switch0        1
                  9
                  10

Unfortunately, problem still persists when I am hooked up to trunk port and have my network client hooked up to vlan 9 tagged:

ping 192.168.1.1 -t -S 192.168.168.174

Pinging 192.168.1.1 from 192.168.168.174 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64

This exact same config works on 19.07 (and previous version) without issues.

The default forward policy of the stb zone is set to ACCEPT.

Unfortunately, setting to REJECT (and reloading firewall, even reboot) doesn't make any difference.

config zone
	option name 'stb'
	option network 'stb'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

And why should it make any difference?
As forwarding between lan-stb zones is not configured:

config forwarding
	option src 'lan'
	option dest 'wan'

config forwarding
	option src 'stb'
	option dest 'wan'

It isn’t the forward rule. It is the input rule. That must be drop or reject to block access to the router itself (192.168.1.1)

Dropping/rejecting input will also cause dhcp and dns to fail. You need to create rules to allow access to the router on these ports (67-68 dhcp, 53 dns), if desired.

2 Likes

It doesn't make sense, and does not relate to my issue.

I have 2 zones, and I am able to go from zone stb to zone lan on a trunk port where both networks are tagged only and firewall doesn't contain any forwarding rules to allow this - which should not be possible.

I have - the exact same - configuration on different routers and for many years without issues.
And now you are suggesting to drop/reject traffic to the router itself, but that doesn't solve the forwarding issue.

Thus, I suspect it's bypassing the firewall somehow.

And configuring lan zone input to REJECT, doesn't make any sense to set-up rules for every service I like to offer on my internal lan - which is trusted.

Yes, it does relate to your issue. Your ping example was to an address on the router itself (192.168.1.1). That will be accepted, even though it is technically a different subnet, because the input (to the router) is accepted and the router holds multiple addresses.

Try another address on 192.168.1.0/24 and see if those pings go through.

But my point is that, at least in the test you showed us, the destination IP is not subject to the firewall forward rules. It is only subject to the firewall INPUT rule because that IP belongs to the router itself.

Test pings from a host on one network to a host on another network where both of the hosts in question are not the router itself.

1 Like

Thanks, I had it wrong in my mind.
I thought iptables always sat between interfaces, as it works with zones. Thus, I assumed router's interface would not be reachable.

I've now configured stb zone input traffic to REJECT and that has desired effect.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.