Join Log in
Score:2
avatar Server

How to block devices connecting to a specific wireless interface from accessing the internet?

eg flag
KevinM

I have configured my OpenWRT WiFi router with two wireless interfaces: wlan0 and wlan0-1. My WAN ethernet interface is eth0.2.

How do I prevent devices that connect to wlan0-1 from accessing the internet, e.g. using iptables?

My context is that I have some devices (air-filters) with WiFi access to support monitoring and control, however they also upload data to a cloud server, which I want to prevent.

br-lan    Link encap:Ethernet  HWaddr 70:4F:57:00:51:AE
          inet addr:192.168.1.254  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fd76:9521:f357::1/60 Scope:Global
          inet6 addr: fe80::724f:57ff:fe00:51ae/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:380362 errors:0 dropped:9 overruns:0 frame:0
          TX packets:1678139 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:128540610 (122.5 MiB)  TX bytes:1235755098 (1.1 GiB)

br-wan    Link encap:Ethernet  HWaddr 70:4F:57:00:51:AF
          inet addr:192.168.178.20  Bcast:192.168.178.255  Mask:255.255.255.0
          inet6 addr: fe80::724f:57ff:fe00:51af/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1684381 errors:0 dropped:10354 overruns:0 frame:0
          TX packets:369066 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1209960142 (1.1 GiB)  TX bytes:132041857 (125.9 MiB)

eth0      Link encap:Ethernet  HWaddr 70:4F:57:00:51:AE
          inet6 addr: fe80::724f:57ff:fe00:51ae/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1809158 errors:0 dropped:16 overruns:0 frame:0
          TX packets:1611603 errors:1 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1276777715 (1.1 GiB)  TX bytes:1193854987 (1.1 GiB)
          Interrupt:5

eth0.1    Link encap:Ethernet  HWaddr 70:4F:57:00:51:AE
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:106729 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1218251 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:33390921 (31.8 MiB)  TX bytes:1054045465 (1005.2 MiB)

eth0.2    Link encap:Ethernet  HWaddr 70:4F:57:00:51:AF
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1689922 errors:0 dropped:349 overruns:0 frame:0
          TX packets:393339 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1210230806 (1.1 GiB)  TX bytes:133360867 (127.1 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:642 errors:0 dropped:0 overruns:0 frame:0
          TX packets:642 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:56074 (54.7 KiB)  TX bytes:56074 (54.7 KiB)

wlan0     Link encap:Ethernet  HWaddr 70:4F:57:00:51:AC
          inet6 addr: fe80::724f:57ff:fe00:51ac/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:293895 errors:0 dropped:0 overruns:0 frame:0
          TX packets:383702 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:99486914 (94.8 MiB)  TX bytes:194289752 (185.2 MiB)

wlan0-1   Link encap:Ethernet  HWaddr 72:4F:57:00:51:AC
          inet6 addr: fe80::704f:57ff:fe00:51ac/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15014 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12335 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1962975 (1.8 MiB)  TX bytes:2056310 (1.9 MiB)

So far I have only been able to block traffic from individual IP addresses, but this is clumsy:

$ iptables -A forwarding_rule --source 192.168.1.110  --jump reject

Using the input and output interfaces, either br-wan or eth0.2, did not work:

$ iptables -A forwarding_rule -i wlan0-1 -o br-wan --jump reject

EDIT: Adding output of iptables-save

# Generated by iptables-save v1.8.3 on Thu Oct  7 21:18:59 2021
*nat
:PREROUTING ACCEPT [29740:1906622]
:INPUT ACCEPT [1917:191180]
:OUTPUT ACCEPT [9468:913173]
:POSTROUTING ACCEPT [0:0]
:postrouting_lan_rule - [0:0]
:postrouting_rule - [0:0]
:postrouting_wan_rule - [0:0]
:prerouting_lan_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_wan_rule - [0:0]
:zone_lan_postrouting - [0:0]
:zone_lan_prerouting - [0:0]
:zone_wan_postrouting - [0:0]
:zone_wan_prerouting - [0:0]
-A PREROUTING -m comment --comment "!fw3: Custom prerouting rule chain" -j prerouting_rule
-A PREROUTING -i br-lan -m comment --comment "!fw3" -j zone_lan_prerouting
-A PREROUTING -i br-wan -m comment --comment "!fw3" -j zone_wan_prerouting
-A PREROUTING -i eth0.2 -m comment --comment "!fw3" -j zone_wan_prerouting
-A POSTROUTING -m comment --comment "!fw3: Custom postrouting rule chain" -j postrouting_rule
-A POSTROUTING -o br-lan -m comment --comment "!fw3" -j zone_lan_postrouting
-A POSTROUTING -o br-wan -m comment --comment "!fw3" -j zone_wan_postrouting
-A POSTROUTING -o eth0.2 -m comment --comment "!fw3" -j zone_wan_postrouting
-A zone_lan_postrouting -m comment --comment "!fw3: Custom lan postrouting rule chain" -j postrouting_lan_rule
-A zone_lan_postrouting -m comment --comment "!fw3" -j MASQUERADE
-A zone_lan_prerouting -m comment --comment "!fw3: Custom lan prerouting rule chain" -j prerouting_lan_rule
-A zone_wan_postrouting -m comment --comment "!fw3: Custom wan postrouting rule chain" -j postrouting_wan_rule
-A zone_wan_postrouting -m comment --comment "!fw3" -j MASQUERADE
-A zone_wan_prerouting -m comment --comment "!fw3: Custom wan prerouting rule chain" -j prerouting_wan_rule
COMMIT
# Completed on Thu Oct  7 21:18:59 2021
# Generated by iptables-save v1.8.3 on Thu Oct  7 21:18:59 2021
*mangle
:PREROUTING ACCEPT [408155:279582022]
:INPUT ACCEPT [31411:6614761]
:FORWARD ACCEPT [376252:272911158]
:OUTPUT ACCEPT [51318:6113468]
:POSTROUTING ACCEPT [402428:277911525]
-A FORWARD -o br-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone wan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i br-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone wan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -o eth0.2 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone wan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -i eth0.2 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone wan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Thu Oct  7 21:18:59 2021
# Generated by iptables-save v1.8.3 on Thu Oct  7 21:18:59 2021
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:forwarding_lan_rule - [0:0]
:forwarding_rule - [0:0]
:forwarding_wan_rule - [0:0]
:input_lan_rule - [0:0]
:input_rule - [0:0]
:input_wan_rule - [0:0]
:output_lan_rule - [0:0]
:output_rule - [0:0]
:output_wan_rule - [0:0]
:reject - [0:0]
:syn_flood - [0:0]
:zone_lan_dest_ACCEPT - [0:0]
:zone_lan_forward - [0:0]
:zone_lan_input - [0:0]
:zone_lan_output - [0:0]
:zone_lan_src_ACCEPT - [0:0]
:zone_wan_dest_ACCEPT - [0:0]
:zone_wan_forward - [0:0]
:zone_wan_input - [0:0]
:zone_wan_output - [0:0]
:zone_wan_src_REJECT - [0:0]
-A INPUT -i lo -m comment --comment "!fw3" -j ACCEPT
-A INPUT -m comment --comment "!fw3: Custom input rule chain" -j input_rule
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m comment --comment "!fw3" -j syn_flood
-A INPUT -i br-lan -m comment --comment "!fw3" -j zone_lan_input
-A INPUT -i br-wan -m comment --comment "!fw3" -j zone_wan_input
-A INPUT -i eth0.2 -m comment --comment "!fw3" -j zone_wan_input
-A FORWARD -m comment --comment "!fw3: Custom forwarding rule chain" -j forwarding_rule
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A FORWARD -i br-lan -m comment --comment "!fw3" -j zone_lan_forward
-A FORWARD -i br-wan -m comment --comment "!fw3" -j zone_wan_forward
-A FORWARD -i eth0.2 -m comment --comment "!fw3" -j zone_wan_forward
-A FORWARD -m comment --comment "!fw3" -j reject
-A OUTPUT -o lo -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -m comment --comment "!fw3: Custom output rule chain" -j output_rule
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -o br-lan -m comment --comment "!fw3" -j zone_lan_output
-A OUTPUT -o br-wan -m comment --comment "!fw3" -j zone_wan_output
-A OUTPUT -o eth0.2 -m comment --comment "!fw3" -j zone_wan_output
-A forwarding_rule -s 192.168.1.110/32 -j reject
-A forwarding_rule -s 192.168.1.111/32 -j reject
-A reject -p tcp -m comment --comment "!fw3" -j REJECT --reject-with tcp-reset
-A reject -m comment --comment "!fw3" -j REJECT --reject-with icmp-port-unreachable
-A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN
-A syn_flood -m comment --comment "!fw3" -j DROP
-A zone_lan_dest_ACCEPT -o br-lan -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
-A zone_lan_dest_ACCEPT -o br-lan -m comment --comment "!fw3" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3: Custom lan forwarding rule chain" -j forwarding_lan_rule
-A zone_lan_forward -m comment --comment "!fw3: Zone lan to wan forwarding policy" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_input -m comment --comment "!fw3: Custom lan input rule chain" -j input_lan_rule
-A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_lan_input -m comment --comment "!fw3" -j zone_lan_src_ACCEPT
-A zone_lan_output -m comment --comment "!fw3: Custom lan output rule chain" -j output_lan_rule
-A zone_lan_output -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_src_ACCEPT -i br-lan -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_dest_ACCEPT -o br-wan -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
-A zone_wan_dest_ACCEPT -o br-wan -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_dest_ACCEPT -o eth0.2 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
-A zone_wan_dest_ACCEPT -o eth0.2 -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_forward -m comment --comment "!fw3: Custom wan forwarding rule chain" -j forwarding_wan_rule
-A zone_wan_forward -p esp -m comment --comment "!fw3: Allow-IPSec-ESP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -p udp -m udp --dport 500 -m comment --comment "!fw3: Allow-ISAKMP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -m comment --comment "!fw3: Zone wan to lan forwarding policy" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_wan_forward -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
-A zone_wan_input -m comment --comment "!fw3: Custom wan input rule chain" -j input_wan_rule
-A zone_wan_input -p udp -m udp --dport 68 -m comment --comment "!fw3: Allow-DHCP-Renew" -j ACCEPT
-A zone_wan_input -p icmp -m icmp --icmp-type 8 -m comment --comment "!fw3: Allow-Ping" -j ACCEPT
-A zone_wan_input -p igmp -m comment --comment "!fw3: Allow-IGMP" -j ACCEPT
-A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_wan_input -m comment --comment "!fw3" -j zone_wan_src_REJECT
-A zone_wan_output -m comment --comment "!fw3: Custom wan output rule chain" -j output_wan_rule
-A zone_wan_output -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
-A zone_wan_src_REJECT -i br-wan -m comment --comment "!fw3" -j reject
-A zone_wan_src_REJECT -i eth0.2 -m comment --comment "!fw3" -j reject
COMMIT
# Completed on Thu Oct  7 21:18:59 2021

EDIT: Adding output of uci export firewall

package firewall

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

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

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

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 src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        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 include
        option path '/etc/firewall.user'

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

EDIT: Adding output of ip link:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 1000
    link/ether 70:4f:57:00:51:ae brd ff:ff:ff:ff:ff:ff
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 70:4f:57:00:51:ae brd ff:ff:ff:ff:ff:ff
6: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 70:4f:57:00:51:ae brd ff:ff:ff:ff:ff:ff
7: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 70:4f:57:00:51:af brd ff:ff:ff:ff:ff:ff
8: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-wan state UP qlen 1000
    link/ether 70:4f:57:00:51:af brd ff:ff:ff:ff:ff:ff
9: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 70:4f:57:00:51:ac brd ff:ff:ff:ff:ff:ff
10: wlan0-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 72:4f:57:00:51:ac brd ff:ff:ff:ff:ff:ff

EDIT: Adding output of brctl show:

bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.704f570051ae       no              eth0.1
                                                        wlan0
                                                        wlan0-1
br-wan          7fff.704f570051af       no              eth0.2
215
0 + 0
us flag
Tero Kilkanen
Please add output of `iptables-save` to your question.
1
Reply
cn flag
Mircea Vutcovici
You can use cli or web luci frontend to configure the firewall in OpenWRT: https://openwrt.org/docs/guide-user/firewall/firewall_configuration Please add also the output of `uci export firewall`
0
Reply
eg flag
KevinM
@MirceaVutcovici I've looked at the luci frontend to edit the firewall, but I don't see how to drop traffic from the WiFi interface that is intended for the WAN interface.
0
Reply
eg flag
KevinM
@A.B I don't have `bridge` installed, and the `ip link show` command doesn't accept the `type` parameter. `ip` is provided by BusyBox v1.30.1.
0
Reply
eg flag
KevinM
@A.B The closest I've got is `ip neigh show` Does that help?
0
Reply
Score:3
A.B avatar Server
cl flag
A.B

OpenWRT is running a Linux kernel, but as an embedded system, some features might not be available, so I can't know if this answer, intended to work on a Linux system with a configuration similar to OP will work on it. This requires:

and depending on the chosen solution this might also require some of:

In the end the system is routing packets from the br-lan interface to the br-wan interface. At this step the fact that a frame entered the br-lan interface using the wlan0-1 interface bridge port was lost once the frame left the initial bridge to have its payload: IPv4, routed. So the initial action must happen before this information is lost: in the bridge path when the frame is still in the br-lan bridge.

Documentation might hint (bridge is mentioned) it's possible to handle bridge firewalling with OpenWRT's firewall application, but I don't have any knowledge about this part. So I'll use directly ebtables.

If one can rely on knowing the IP LAN topology on br-lan (192.168.1.0/24) then this can all be done simply in one single ebtables rule:

ebtables -A INPUT -p IPv4 -i wlan0-1 --ip-dst ! 192.168.1.0/24 -j DROP

which drops any IPv4 frame received from the wlan0-1 bridge port and bridged to the host (possibly for it or for further routing) that doesn't have a destination IP address within 192.168.1.0/24.

One could optionally insert before an exception for OpenWRT's public IP address if it's static and known in advance (eg: 192.0.2.2):

ebtables -I INPUT -p IPv4 -i wlan0-1 --ip-dst 192.0.2.2 -j ACCEPT

If this is fine, no need to use the following alternative.

Else if the rule has to stay generic without also involving the LAN IP addresses but only the interfaces (or needs to accept as destination the WAN IP address without knowing its value), routing has to be involved and I suggest to mark the frame using ebtables in the bridge path where the information is available, right before the frame's payload (IPv4) is about to be routed, and then drop later the marked packet/frame once it's certain it was routed toward Internet. The mark is preserved when decapsulating frames or encapsulating packets. OP's current iptables rules don't use any mark so chances are there won't be unfortunate interactions.

As in OP's case the egress interface used for routing is also a bridge (br-wan), to limit interactions with the higher level tool (firewall3) managing the firewall with iptables, one can drop the marked frame in the bridge path instead of dropping the marked packet in the routing path: no interaction with iptables rules.

Flow from LAN to Internet is as follow:

                                            ───── eth0.1 ─────── good
bad  ────── wlan0-1 ────── br-lan bridge ────── wlan0 ─────── good
                                 │
                                 │
                      Ethernet frame INPUT  (ebtables firewall here)
frame marked when from wlan0-1   M
                                 │ 
                                 
                               br-lan      frame is decapsulated to
                           self interface  IPv4. Mark is preserved
                                 │
                                 │
                         IPv4 packet routing (iptables firewall here)
                                 │
                                 │
                                  
                               br-wan      packet is encapsulated in
                           self interface  Ethernet. Mark is preserved
                                 │
                                 │
                      Ethernet frame OUTPUT (ebtables firewall here)
      frame dropped if marked    X
                                 │
                                 
                           br-wan bridge ────── eth0.2 ────── Internet

This will mark frames received from the wlan0-1 bridge port:

ebtables -A INPUT -i wlan0-1 -j mark --mark-set 0xbad

Then this will match and drop when emitting from host through the br-wan bridge a frame/packet previously marked:

ebtables -A OUTPUT --logical-out br-wan --mark 0xbad -j DROP

If --logical-out is not available for some reason, with the current topology it can be changed into br-wan's single output bridge port:

ebtables -A OUTPUT -o eth0.2 --mark 0xbad -j DROP

In this case as the packet is seen entering and leaving the routing stack, conntrack will create an entry for it even if it will dropped just after. Such entry will never reach the ESTABLISHED state since nothing will receive this packet and reply (see also notes).

Notes:

  • if OpenWRT was configured to have two distinct LANs (not bridged or on separate bridges each participating in routing), one for wlan0 and eth0.1 and another one for wlan0-1 with distinct IP addresses on them, then standard routing would apply everywhere and this problem could be solved easily all in iptables probably with configuration in firewall3 and with ebtables not needed.

  • current iptables rules suggest eth0.2 could be used (or used to be used) as a standard (non bridge-port) interface. If such was the case, the second solution would have to be changed and involve an equivalent rule in iptables which should be integrated in firewall3 if possible. It's also possible to use it for br-wan (but again is worth it only if integration with firewall3 is possible):

    This rule can currently work instead of the ebtables OUTPUT rule above:

    iptables -I FORWARD -o br-wan -m mark --mark 0xbad -j DROP

    and with eth0.2 directly a routing interface instead of a bridge port:

    iptables -I FORWARD -o eth0.2 -m mark --mark 0xbad -j DROP

    Both could be put at the same time, as it appears is currently done in other iptables rules with br-wan and eth0.2.

    Here since the packet is dropped in the routing path with iptables, the conntrack entry won't be committed and will not appear (eg: cat /proc/net/nf_conntrack won't show the attempt).

  • Using iptables in the bridge path by relying on br_netfilter features is usually a bad idea when not having total control of the configuration, and is disabled by default in OpenWRT. So iptables' physdev match which depends on this feature should not be used (and is probably not available) to solve this problem.

  • As this isn't stateful, incoming traffic from Internet to a system using wlan0-1 will still be allowed, but no reply will be possible. Anyway as the LAN is private this would require DNAT rules on the firewall to have this possibility (or for the 2nd solution where conntrack entries are still created, a remote 3rd party blindly synchronized to dropped attempts). It's possible to also drop the opposite direction: Internet traffic to wlan0-1 using the same methods as presented, if really needed.

0 + 0
A.B avatar
cl flag
A.B
Now thinking about it: the method using marks all with ebtables also works out of the box for IPv6.
1
Reply
eg flag
KevinM
I will see about installing `ebtables` and trying this out!
0
Reply
eg flag
KevinM
Since I am in control of the IP address assignment, I have been able to use the simple rule `ebtables -A INPUT -p IPv4 -i wlan0-1 --ip-dst ! 192.168.1.0/24 -j DROP`, and it works are desired. Thank you for the detailed explanation. I am sure it will benefit me in the future (and others, already).
0
Reply
eg flag
KevinM
I have to try your other suggestions, when using the simple rule, my devices can't get replies to DHCP requests, which is odd, since the DHCP server is on the same subnet (192.168.1.254). Perhaps it is because the DHCP requests are broadcast...
0
Reply
A.B avatar
cl flag
A.B
a DHCP client doing a DHCP discover sends it to 255.255.255.255: this address must be inserted as exception (like the example with 192.0.2.2).
0
Reply
A.B avatar
cl flag
A.B
Anyway thinking about it, other addresses will get problems depending on the devices: IPv4LL and multicast. So you might want to take a look at the other option which is more generic in its result (and would block IPv6 for the same price).
0
Reply
eg flag
KevinM
For whatever reason, I had to use `ebtables -A OUTPUT -o eth0.2 --mark 0xbad -j DROP`. Using the `ebtables -A OUTPUT --logical-out br-wan --mark 0xbad -j DROP` did not work - I was unable to access other devices on the internal network.
0
Reply
eg flag
KevinM
I spoke too soon. To get full functionality, including MQTT and SMB, for devices connecting to wlan0-1, I had to use `ebtables -A INPUT -i wlan0-1 -j mark --mark-set 0xbad` combined with the `iptables` rules: `iptables -I FORWARD -o br-wan -m mark --mark 0xbad -j DROP` and `iptables -I FORWARD -o eth0.2 -m mark --mark 0xbad -j DROP`.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.