I am dealing with the same issue. I upgraded my Flint2 firmware to OpenWRT v24. The firewall rules are either stock or implemented using LUCI, except for one. Following the "iptables overview" link in the warning banner, looks like there is one rule showing traffic "match-set GL_MAC_BLOCK src". However, this does not correspond to anything in the /etc/config/firewall.
Has a solution bee figured out for this yet?
config rule
option dest 'wan'
option dest_port '53 853 5353'
option family 'any'
option name 'Block-Public-DNS'
option proto 'tcpudp'
option src 'lan'
option target 'REJECT'
config rule 'guest_drop_leaked_dns'
option name 'guest_drop_leaked_dns'
option src 'guest'
option proto 'udp'
option dest_port '53'
option mark '!0x8000/0xf000'
option target 'DROP'
option enabled '0'
config rule 'wan_drop_leaked_adgdns'
option name 'wan_drop_leaked_adgdns'
option src 'wan'
option proto 'udp'
option dest_port '3053'
option mark '0x0/0xf000'
option target 'DROP'
option enabled '0'
config rule 'wan_drop_leaked_dns'
option name 'wan_drop_leaked_dns'
option src 'wan'
option proto 'udp'
option dest_port '53'
option mark '!0x8000/0xf000'
option target 'DROP'
option enabled '0'
config rule 'guest_drop_leak_adgdns'
option name 'guest_drop_leak_adgdns'
option src 'guest'
option proto 'udp'
option dest_port '3053'
option mark '0x0/0xf000'
option target 'DROP'
option enabled '0'
config defaults
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option flow_offloading '1'
option flow_offloading_hw '1'
option synflood_protect '1'
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'
list network 'wwan'
list network 'secondwan'
option input 'DROP'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
config forwarding
option src 'lan'
option dest 'wan'
option enabled '1'
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-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'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
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'
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 zone
option name 'guest'
option network 'guest'
option forward 'REJECT'
option output 'ACCEPT'
option input 'REJECT'
config forwarding
option src 'guest'
option dest 'wan'
option enabled '1'
config rule
option name 'Allow-DHCP'
option src 'guest'
config rule 'ovpnserver_drop_leaked_dns'
option name 'ovpnserver_drop_leaked_dns'
option src 'ovpnserver'
option proto 'udp'
option dest_port '53'
option mark '!0x8000/0xf000'
option target 'DROP'
config rule 'wgserver_drop_leaked_adgdns'
option name 'wgserver_drop_leaked_adgdns'
option src 'wgserver'
option proto 'udp'
option dest_port '3053'
option mark '0x0/0xf000'
option target 'DROP'
config rule 'ovpnserver_drop_leaked_adgdns'
option name 'ovpnserver_drop_leaked_adgdns'
option src 'ovpnserver'
option proto 'udp'
option dest_port '3053'
option mark '0x0/0xf000'
option target 'DROP'
config zone
option name 'IoT'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'iot'
config forwarding
option src 'IoT'
option dest 'lan'
config forwarding
option src 'lan'
option dest 'IoT'
config forwarding
option src 'IoT'
option dest 'wan'
config rule
option src '*'
option dest 'wan'
option name 'BlockThermostat'
list proto 'all'
list src_mac '***'
option target 'REJECT'
config rule
option src '*'
option dest 'wan'
option name 'BlockPrinterWAN'
list proto 'all'
list src_mac '***'
option target 'REJECT'
Since you must have been coming from the stock (gl-inet) firmware, you should reset to defaults. The vendor fork has options and syntax that is not compatible with official openwrt.
Reset to defaults.
Ruleset looks sane on surface though (no fool-cone, just offloads enabled)
What is in
ubus call system board
nft list ruleset | grep xt
iptables-nft-save # if command does not exist ignore
ip6tabes-nft-save # dito
iptables-legacy-save # dito
ip6tables-legacy-save # ddd
root@GL-MT6000:~# ubus call system board
{
"kernel": "6.6.110",
"hostname": "GL-MT6000",
"system": "ARMv8 Processor rev 4",
"model": "GL.iNet GL-MT6000",
"board_name": "glinet,gl-mt6000",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "24.10.4",
"revision": "",
"target": "mediatek/filogic",
"description": "OpenWrt 24.10.4 r28959-29397011cc",
"builddate": "1760891865"
}
}
root@GL-MT6000:~# nft list ruleset | grep xt
# Warning: table ip filter is managed by iptables-nft, do not touch!
xt match "set" counter packets 0 bytes 0 drop
root@GL-MT6000:~# iptables-nft-save # if command does not exist ignore
# Generated by iptables-nft-save v1.8.10 (nf_tables) on Tue Jan 6 18:12:10 2026
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [31867:7414806]
:OUTPUT ACCEPT [0:0]
-A FORWARD -m set --match-set GL_MAC_BLOCK src -j DROP
COMMIT
# Completed on Tue Jan 6 18:12:10 2026
# Generated by iptables-nft-save v1.8.10 (nf_tables) on Tue Jan 6 18:12:10 2026
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Tue Jan 6 18:12:10 2026
root@GL-MT6000:~# ip6tabes-nft-save # dito
-ash: ip6tabes-nft-save: not found
root@GL-MT6000:~# iptables-legacy-save # dito
-ash: iptables-legacy-save: not found
root@GL-MT6000:~# ip6tables-legacy-save # ddd
OK, there it is - rule not from fw4 uses ipset.
Save config
reset to defaults
Type back wifi and network
unzip archive
copy /etc/config/firewall as is.
Lines such as this have no meaning in the official OpenWrt firmware. Like I said before, the settings from the GL-inet version of the firmware are not compatible with official OpenWrt. Simply reset to defaults and configure from scratch.
No, this is not appropriate because the vendor fork has stuff in it that does not belong in the configs for official OpenWrt.
Next step would be to tap on each rule shown in fw4 check to fix it...
In this case, the next step is to simply rebuild from scratch. There is no use trying to 'fix' the issues with importing the GL-inet configs into OpenWrt as many of them are meaningless without their underlying changes to the firmware and/or other config elements (that also don't work on OpenWrt).
(This was a rule that could be made in fw3, but this is because fw3 exposed the iptables CLI "extra arguments" - as I believe they were called. But alas, it did not expose ipsets yet.)
Hahaha...ohhhhhh @brada4 , I have bricked this thing and locked myself out so many times trying to get it setup, I must've done the reset, unzip, copy back in config more than 20 times. This legacy rules thing is always there. Fixing one messed up rule does seem much simpler that rebuilding the OS. I'd give it a try, if I knew what you meant by fw4 check
Rebuilding from scratch is a bit daunting, but if there's not a simpler fix, then I'm already in this deep, why not? The promise of full UCI command line syntax would be nice, trying to navigate the GL-iNet BusyBox subset is a constant game of not found
A quick look at the guide: https://openwrt.org/docs/guide-user/installation/generic.sysupgrade ---looks like I can install the non-factory sysupgrade using the 'luci-app-attendedsysupgrade package. Fingers crossed this makes things better.
(https://openwrt.org/packages/pkgdata/luci-app-attendedsysupgrade).
I understand it is lazy sloppy approach, but i see 2 or 3 rules ythat needs refinement via luci...
@brada4 do you want to give me a bit more guidance on how to try your approach?
I got this error when trying to do the sysupgrade:
Yeah, very sloppy and bad form. Given that the rest of the config needs to be recreated, what is it in the gl-inet firewall that you believe is worth "saving" that is not covered by the existing default OpenWrt config and/or easily added when configuring fresh? Keep in mind, it's more work to extract a single file and move it over than to just use the defaults.
Not related to firewall, i
back up configuration
install default sysupgrade file from https://firmware-selector.openwrt.org/?version=24.10.5&target=mediatek%2Ffilogic&id=glinet_gl-mt6000
not keeping configuration
unzip bavkup and type back configurations via web interface.
...what a mess! So I did this - backup config, install sysupgrade. I can happily report that the legacy firewall warning banner has disappeared. However, trying to unzip the backup bricks the router, requiring a full reset.
So now I have an absolutely barebones OpenWRT install, with a blank slate for configs.
To top it off, can't even start installing packages because even okpg update fails
I guess I'll return back to this thread for firewall troubleshooting after I figure out how to fix all the other new problems.
You actively chose to ignore the sane advice of resetting to OpenWrt factory defaults and NOT restoring an incompatible and known-broken config backup. At this point you're left with two new-old options, either doing the reset properly this time or ignoring advice and meddling with it yourself (read, not here, we ain't interested in that self-inflicted pain; at least so far I haven't heard of any specific config that's so crucial to your well-being to justify this dance).
The firewall config is only one of the configs that are incompatible and actively harmful here (wireless and network will be next, among others(!)), you cannot move between OEM (and proprietary vendor drivers) and OpenWrt without a full reset and reconfiguring from scratch. Which is simpler and quicker than trying to find and fix all incompatible issues (and then still missing some crucial ones).
@slh , respectfully, I did not actively choose to ignore anything. I carefully read and considered each piece of advice provided, and then actively searched for and studied additional literature (in the official documentation) to try to do everything as best as I could. At this point, I have followed the instructions in the official OpenWRT guide to do a full sysupgrade 3 times (two methods, attended and not--then repeating the not after trying to unzip the backup), and then again following the official GL-iNET guide.
As far as specific configs - I want a functional firewall. Today's mission started out just trying to figure out why some devices that should be blocked at the MAC address level were still sending out DNS requests, which led to investigating the legacy banner, and now here I am trying to figure out how to rebuild an unfamiliar OS from scratch.
