FORWARD rules for a zone that has a single covered network

Would setting FORWARD to:

  1. accept mean devices within the single covered network be able to reach each other?
  2. reject/drop mean devices within the single covered network be unable to reach each other? (like "client isolation" for wireless networks?)

No. Forward only affects the case where there are multiple covered networks in the same zone.

Devices that are on the same l2 network will be able to communicate with each other without the involvement of the router and firewall. (And likewise, they cannot be blocked using the firewall, except in very specific use cases)

1 Like

I have eth1.3 and AP iot on zone fw_iot

fw_iot is not allowed to forward or input packets except DHCP and ICMP

However, I cannot connect PC to either eth1.3 or complete joining AP iot due to lack of IP assignment

What am I doing wrong?

/etc/config/network

config interface 'IOT'
	option proto 'static'
	option ipaddr '10.1.2.1'
	option netmask '255.255.255.0'
	option type 'bridge'
	option device 'br-iot'

/etc/config/wireless

config device
	option type 'bridge'
	option name 'br-iot'
	list ports 'eth1.3'
	option ipv6 '0'

config wifi-iface 'wifinet4'
	option device 'radio0'
	option mode 'ap'
	option ssid 'iot'
	option encryption 'psk2'
	option key 'rooter2017'
	option network 'IOT'

/etc/config/firewall

config zone
	option name 'fw_iot'
	option output 'ACCEPT'
	list network 'IOT'
	option forward 'DROP'
	option input 'REJECT'

config forwarding
	option src 'fw_iot'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew-IOT'
	list proto 'udp'
	option src 'fw_iot'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping-IOT'
	option family 'ipv4'
	list proto 'icmp'
	option src 'fw_iot'
	option target 'ACCEPT'

There appears to be a bunch of stuff wrong. Let’s see the complete configuration.

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
1 Like

This is not OpenWrt. You'll need to direct your questions to the people who support GoldenOrb.

Or...
you can install official OpenWrt on your device.
https://firmware-selector.openwrt.org/?version=23.05.0&target=ath79%2Fgeneric&id=tplink_archer-c7-v2

1 Like

Ok the actual image is:

https://downloads.openwrt.org/releases/23.05.0/targets/ath79/generic/openwrt-23.05.0-ath79-generic-tplink_archer-c7-v2-squashfs-sysupgrade.bin

?

yes.

If you install OpenWrt, be sure that you do not keep settings from your current GoldenOrb installation - they will not be compatible.

1 Like

I think underscores will cause problems...

Remove the bridge line, change the device to br-iot

These two stanzas should look like this instead:

config interface 'iot'
	option proto 'static'
	option device 'br-iot'
	option ipaddr '10.1.2.1'
	option netmask '255.255.255.0'

config device
	option type 'bridge'
	option name 'br-iot'
	list ports 'eth1.3'
	option ipv6 '0'

Note I've also changed the name of the network to simply iot.

following that, be sure to adjust the SSID to use network iot

config wifi-iface 'wifinet2'
	option device 'radio0'
	option mode 'ap'
	option ssid 'iot'
	option encryption 'psk2'
	option key 'rooter2017'
	option network 'iot'

as well as the dhcp server (also renaming the dhcp server):

config dhcp 'iot'
	option interface 'iot'
	option start '100'
	option limit '150'
	option leasetime '12h'

and in the firewall, remove the device and adjust the network name so that it looks like this:

config zone
	option name 'fw-iot'
	option input 'DROP'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'iot'
2 Likes

You are absolutely correct that the "-" (which is the only special character allowed by the UI) leads OpenWrt to misbehave. Replacing that lets things work just fine!

However, I am completely confounded by these observations:

  1. How is it even possible that I can visit 192.168.2.1 (LAN) from the iot (10.1.2.1) SSID?
    ping, LUCI at 192.168.2.1 both work when exclusively connected to iot (10.1.2.1) SSID (I checked that I'm assigned from 10.1.2.* and hence there shouldn't be any connection to 192.168.2.)
    As you know, there's no forward rule for iot, infact, "Zone β‡’ Forwardings" shows no targets and explicitly shows "REJECT", so absolutely no traffic should leak out from 10.1.2.
  2. I proceeded to change forward rule for iot to explicitly be "reject" and that has no effect! I can still visit 192.168.2.1 (LAN) via the iot (10.1.2.1) SSID
  3. Setting input rule for iot to be "reject" absolutely kills that interface even if I have an explicit DHCP traffic rule should allow 68 to the router
  4. Also, even after all the above, when connected to LAN, I am able to ping 10.1.2.1 or visit LUCI at 10.1.2.1 (even though IOT zone has both forward and input to reject and no Forwardings), even though I cannot get either a ethernet or wifi connection provisioned on that interface any longer! (only setting input to accept on IOT zone lets both work irregardless of whether I have accept rules for DHCP in traffic rules which seems to have no effect!)

This is absolutely baffling!

a. I can visit one subnet (192.168.2.) from another (10.1.2.) although I shouldn't be able to
b. Whitelisting specific ports on an otherwise "reject" zone has no effect

What am I doing wrong?

/etc/config/network


config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd17:b19b:6bd4::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1.1'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.2.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option device 'eth0.2'
	option proto 'dhcp'

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

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0t 2 4 5'
	option vid '1'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '6t 1'
	option vid '2'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option vid '3'
	option ports '0t 3'

config interface 'ifIiot'
	option proto 'static'
	option device 'brIiot'
	option ipaddr '10.1.2.1'
	option netmask '255.255.255.0'

config device
	option name 'brIiot'
	option type 'bridge'
	list ports 'eth1.3'
	option ipv6 '0'

/etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'pci0000:00/0000:00:00.0'
	option channel '36'
	option band '5g'
	option htmode 'VHT80'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'
	option disabled '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/ahb/18100000.wmac'
	option channel '1'
	option band '2g'
	option htmode 'HT20'
	option disabled '1'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'

config wifi-iface 'wifinet2'
	option device 'radio0'
	option mode 'ap'
	option ssid 'iot'
	option encryption 'psk2'
	option key 'rooter2017'
	option network 'ifIiot'

/etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
	option ednspacket_max '1232'
	option filter_aaaa '0'
	option filter_a '0'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'iot'
	option interface 'ifIiot'
	option start '100'
	option limit '150'
	option leasetime '12h'

/etc/config/firewall


config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'fwIiot'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'ifIiot'

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

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

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

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCP-Renew-IOT'
	option src 'fwIiot'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

It's not leaking out... this is a function of the INPUT rule on your IoT zone. Specifically, when you're trying to connect to an address that the router holds (in your case 192.168.2.1 or 10.1.2.1), you're not routing (and thus not traversing zones or networks)... the router itself listens for incoming connections to any of its addresses unless the firewall prohibits the INPUT. Think of it like two names for the same person -- we'll use the name Elisabeth... her co-workers call her by her given name, but her friends/family call her Beth. Because she's listening for both those names, she'll respond.

This is expected and correct behavior. The zone FORWARD rule controls the routing between multiple covered networks in the same zone; it has nothing to do with INPUT to the router.

I'll look at your DHCP allow rule... but it is expected to reject all except the explicitly allowed ports at that point.

Again, this is the INPUT rule at play here, not the FORWARD or even zone forwardings.

2 Likes

Try this for the DHCP rule on the IOT zone...

config rule
	option name 'Allow-DHCP-Renew-IOT'
	option src 'fwIiot'
	option proto 'udp'
	option dest_port '67-68'
	option target 'ACCEPT'

You may also want to make a similar rule for DNS (port 53, TCP+UDP).

1 Like
  1. Linux treats all IP addresses held by the kernel the same. If a packet arrives on any interface with a destination IP of another interface, it will be answered (and routed back to the proper destination interface by the routing table). In other words there's no consideration of the source in the kernel's basic IP stack. That is what the firewall is for.
  2. Packets addressed to the router itself are not forwarding, they are input. A deny input rule on iot will prevent any input to any IP on the router from an iot.
  3. Port 67 (not 68) UDP needs to be allowed for input for DHCP to work. A DHCP server takes input on port 67 and sends replies from port 68. A lot of guest/iot network instructions say to open both ports for input, that is not necessary, only 67. The reply from port 68 is usually covered without a separate rule by leaving the default output rule ACCEPT.
  4. Same as 1. The rule is input from a zone, i.e. an iot on a network that is included in the iot zone.
2 Likes
  1. If I set Input to reject on IOT, will I be able to access webservers running on other sibling devices on IOT zone?
  2. Now what if I want to reach webservers running at 8080 on sibling device 10.1.2.55 - do I have to create an "allow" rule for this access specifically?

Yes. Devices on the same L2 subnet are not subject to the firewall rules (which are applied as part of L3/routing operations).

From where? From another device on the 10.1.2.0/24 network -- no. From the 192.168.2.0/24 network, yes.

2 Likes

I see. I am curious about:

  1. How "isolate clients" is achieved over wireless
  2. Is there a way to achieve something similar over ethernet/wired?

This is a unique feature for wifi (part of the standard, of course), in that the AP can, optionally, be set to isolate clients. This is not related to the OpenWrt firewall, though... it is done as an L2 filtering operation by the radio itself.

No, and yes...

Tradtionally this is not possible to do when the clients are all part of the same L2 network. However, you can do this on some managed switches (especially as you select devices that are business and enterprise grade) via port isolation. And there is something called bridge firewall (which I've never used, but may work). In this case, the clients would all need to be directly connected to the ports on your router -- you cannot isolate ethernet clients if they do not need to actually traverse the router's built-in switch. (think of this as the shortest path between the two hosts -- if there is another switch, especially an unmanaged one, to which they are both connected, you cannot isolate them from each other.

2 Likes