Joined: 21 Aug 2019 Posts: 222 Location: Here, There And Everywhere
Posted: Mon Nov 24, 2025 9:41 Post subject:
@Wasp-Ink30
On my MR7500 iptables are present and work just fine. Did you flash dd-wrt-webflash.bin or factory-to-ddwrt.img (which is much smaller and may be missing iptables)?
Code:
root@MR7500:~ # which iptables
/usr/sbin/iptables
root@MR7500:~ # iptables
iptables v1.8.11 (legacy): no command specified
Try `iptables -h' or 'iptables --help' for more information.
Joined: 05 Oct 2008 Posts: 852 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Tue Nov 25, 2025 0:51 Post subject:
On my R7800 running this build iptables is somehow broken.
I had to revert to build 62606 to get back to normal.
Having seen some mention of iptables in this thread albeit for a different line of routers, I figured I might do some checking on my LAN.
Four FAH and BOINC servers are on a separate network (192.168.30.0), but by virtue of firewall rules (iptables) have been made accessible from my desktop and some other servers.
These firewall rules have been working fine for a long long time, but now on build 62778, there was no access to the servers on the separate network. LAN port #4 is assigned to a bridge called brV30 and used by all 4 servers. Only wired, no Wi-Fi on this subnet.
Output from iptables -vnL on the router showed no traffic registered for the rules concerned.
Disabling Ńet isolation in Networking settings did allow access, but that was not how I want it to be.
I was fortunate to check today, since in less than a week I will leave this location for many months and solving this kind of situation concerning the router from my new location is a source of stress as one may loose access from the internet to the LAN as a whole and vice versa, if something goes awry when changing router settings.
Reverting to build 62606 restored access to the isolated subnet and packets were again registered by iptables.
Last edited by ArjenR49 on Tue Nov 25, 2025 16:39; edited 1 time in total
On my R7800 running this build iptables is somehow broken.
I had to revert to build 62606 to get back to normal.
Having seen some mention of iptables in this thread albeit for a different line of routers, I figured I might do some checking on my LAN.
Four FAH and BOINC servers are on a separate network (192.168.30.0), but by virtue of firewall rules (iptables) have been made accessible from my desktop and some other servers.
These firewall rules have been working fine for a long long time, but now on build 62778, there was no access to the servers on the separate network. LAN port #4 is assigned to a bridge called brV30 and used by all 4 servers. Only wired, no Wi-Fi on this subnet.
Output from iptables -vnL on the router showed no traffic registered for the rules concerned.
Disabling Ńet isolation in Networking settings did allow access, but that was not how I want it to be.
I was fortunate to check today, since in less than a week I will leave this location for many months and solving this kind of situation concerning the router from my new location is a source of stress as one may loose access from the internet to the LAN as a whole and vice versa, if something goes awry when changing router settings.
Reverting to build 62606 restored access to the isolated subnet and packets were again registed by iptables.
I can confirm that. I have iptables configured for a VAP on a different subnet, redirecting the DNS to a second DNS server. I also tried using `$(nvram get IPTABLES)`, but it doesn't work.
Joined: 05 Oct 2008 Posts: 852 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Tue Nov 25, 2025 17:00 Post subject:
grc wrote:
I can confirm that. I have iptables configured for a VAP on a different subnet, redirecting the DNS to a second DNS server. I also tried using `$(nvram get IPTABLES)`, but it doesn't work.
┌─[✓]─[root@r7800:192.168.1.1]─[~]
└─`$(nvram get IPTABLES)`
-sh: iptables-nft: not found
┌─[✗]─[root@r7800:192.168.1.1]─[~]
└─echo $(nvram get IPTABLES)
iptables-nft
Joined: 04 Aug 2018 Posts: 1577 Location: Appalachian mountains, USA
Posted: Tue Nov 25, 2025 23:05 Post subject:
grc wrote:
I also tried using `$(nvram get IPTABLES)`, but it doesn't work.
Note that `foo` and $(foo) are equivalent, the older and newer (and preferred) way of doing the same thing. Don't use them together, one nested inside the other. _________________ On 61465: 3x Dynalink DL-WRX36, Linksys MX4200v2, 2x MR7350. WPA2personal/WPA3 w/ AES, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), Two SmartDNS/DoT providers and one DNSCrypt provider via VPNs. DNSmasq manages that plus ad blocking and local DNS.
Joined: 05 Oct 2008 Posts: 852 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Wed Nov 26, 2025 0:16 Post subject:
matjazk wrote:
Interesting. On my R7800 it works.
You report about the build version of this thread.
I didn't check IPTABLES variable and the iptables version when I had build 62778 installed, but downgraded ASAP to build 62606, when I found the problem.
My post above contains output for that build, but I posted it in this thread, because the problem appears with build 62778.
That is not to say that to me it seems logical in build 62606 to have an nvram variable IPTABLES pointing to iptables-nft, which doesn't even exist in that build:
┌─[✓]─[root@r7800:192.168.1.1]─[~]
└─echo $(nvram get IPTABLES)
iptables-nft
As said, on my R7800 build 62606 firewall rules work as intended, but not on 62778, which I noticed from loosing access to an isolated subnet previously allowed by the firewall rules below. I didn't check carefully if the other firewall rules on my R7800 had also become ineffective. Based on the comparatively short output of iptables -vnL on build 62778, I think they probably did.
I chickened out, using parlance I picked up lately ... (since I am due to leave the location of this router soon for several months and I need it to work).
Joined: 05 Oct 2008 Posts: 852 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Wed Nov 26, 2025 0:22 Post subject:
Should we perhaps replace all instances of iptables commands with iptables-nft starting from build 62778?
There might be a way around this, making iptables an alias for iptables-nft, but I don't have the time to experiment with that now.
Joined: 16 Nov 2015 Posts: 7090 Location: UK, London, just across the river..
Posted: Wed Nov 26, 2025 8:12 Post subject:
ArjenR49 wrote:
Should we perhaps replace all instances of iptables commands with iptables-nft starting from build 62778?
There might be a way around this, making iptables an alias for iptables-nft, but I don't have the time to experiment with that now.
hmmm...my R7800 also behaved odd...as i mentioned above in my previous post..
i guess it will be iptables and nf_tables together...and you decide if you use nftables rules or iptables rules...im just guessing... _________________ Atheros
TP-Link WR1043NDv2 -DD-WRT 62606 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 -DD-WRT 63600 GTW/SmDNS/DoT,AD-Blk,Forced DNS,AP&Net Isolation,x2VLAN,Vanilla
Netgear R7800 --DD-WRT 62606 Gateway/DNSCryptv2,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla,VPN cli
Netgear R9000 --DD-WRT 62606 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Dynalink DL-WRX36-DDWRT 62606
Broadcom
Netgear R7000 --DD-WRT 63600 GTW/DNScrypt-proxy2/AD-Block,IPset Firewall,Forced DNS,x4VLAN,VPN cli
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Joined: 05 Oct 2008 Posts: 852 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Wed Nov 26, 2025 10:17 Post subject:
Alozaros wrote:
ArjenR49 wrote:
Should we perhaps replace all instances of iptables commands with iptables-nft starting from build 62778?
There might be a way around this, making iptables an alias for iptables-nft, but I don't have the time to experiment with that now.
hmmm...my R7800 also behaved odd...as i mentioned above in my previous post..
i guess it will be iptables and nf_tables together...and you decide if you use nftables rules or iptables rules...im just guessing...
iptables-nft command is supposed to translate legacy iptables rules into nftables rules behind the screens, automatically.
Then there is a iptables translate command to translate a saved legacy iptables rule profile into nftables rules.
I tried that just to see what would happen. The saved profile was a very long text file. Much longer than the original rules. Just an observation.
The translate crashed early in the saved profile, at line 60. I don't have the terminal output anymore, but the reason was something called pds - not totally sure - which was not something that appeared as such in the original iptables rules.
Therefore I suspect the behind the screen translation would fail as well, if I would replace all iptables commands in my firewall script by iptables-nft.
I hope by the time I have good and well relocated from the Netherlands to Finland for the winter months, someone will have made some progress with this major change. In Helsinki I have an XR500 with a similar setup and firewall rules, so the work continues there anyhow.
The iptables commands in my firewall script that look more outlandish to me, and raise suspicion of causing the translation failure, are:
Joined: 16 Nov 2015 Posts: 7090 Location: UK, London, just across the river..
Posted: Wed Nov 26, 2025 15:44 Post subject:
yep it seams lots of 'manual labor' will be involved...
and im not sure if those rules do anything anyway..
# Block outgoing packets to ports 853 & 5353 (DoT & alt. DNS port)
iptables -I FORWARD -p tcp --match multiport --dports 853,5353 -j REJECT --reject-with tcp-reset
iptables -I FORWARD -p udp --match multiport --dports 853,5353 -j REJECT --reject-with icmp-port-unreachable
if im not wrong UDP doesn't do ----reject-with icmp-port-unreachable
never seen multiport to work...
unless some magic happened very recently..and iptables multiport works.....tried it in the past, many times and many multiport options...have you ever had something with it or test if it works ?
I may stay on the old build for a while....too.. _________________ Atheros
TP-Link WR1043NDv2 -DD-WRT 62606 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 -DD-WRT 63600 GTW/SmDNS/DoT,AD-Blk,Forced DNS,AP&Net Isolation,x2VLAN,Vanilla
Netgear R7800 --DD-WRT 62606 Gateway/DNSCryptv2,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla,VPN cli
Netgear R9000 --DD-WRT 62606 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Dynalink DL-WRX36-DDWRT 62606
Broadcom
Netgear R7000 --DD-WRT 63600 GTW/DNScrypt-proxy2/AD-Block,IPset Firewall,Forced DNS,x4VLAN,VPN cli
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Joined: 05 Oct 2008 Posts: 852 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Wed Nov 26, 2025 16:20 Post subject:
Alozaros wrote:
if im not wrong UDP doesn't do ----reject-with icmp-port-unreachable
never seen multiport to work...
unless some magic happened very recently..and iptables multiport works.....tried it in the past, many times and many multiport options...have you ever had something with it or test if it works ?
Whatever checking on the effectiveness of these rules I have done in the past, it is too long ago to remember. I was most probably satisfied with the result so that is what I have been using.
Background: I run Pi-Hole with Unbound (and WG, too) on a Raspberry Pi on my LAN (runs an NTP server as well). Most LAN clients are using the Pi-Hole server for DNS and NTP. Only IoT devices may not adhere, so I put them on an isolated subnet.
I didn't invent the following rules myself I took some 'advice' from the internet and did the best I can so the FORWARD chain contains these:
...
0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 853,5353 reject-with icmp-port-unreachable
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 853,5353 reject-with tcp-reset
...
and below is where 'psd' is mentioned, the word iptables translate to nftables functionality barks at. Also from the FORWARD chain. I have no idea what it is that results in those rules. Perhaps is is not something in my own firewall script.
...
0 0 DROP all -- wan * 0.0.0.0/0 0.0.0.0/0 recent: CHECK seconds: 3600 name: portscan side: source mask: 255.255.255.255
0 0 all -- wan * 0.0.0.0/0 0.0.0.0/0 recent: REMOVE name: portscan side: source mask: 255.255.255.255
0 0 portscan tcp -- wan * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139 recent: SET name: portscan side: source mask: 255.255.255.255
5319 1455K DROP all -- wan * 0.0.0.0/0 0.0.0.0/0 -m psd --psd-weight-threshold 15 --psd-delay-threshold 300 --psd-lo-ports-weight 3 --psd-hi-ports-weight 3
...
Posted: Thu Nov 27, 2025 12:55 Post subject: R62778 - Attempt #4
First off:
matjazk wrote:
@Wasp-Ink30
On my MR7500 iptables are present and work just fine. Did you flash dd-wrt-webflash.bin or factory-to-ddwrt.img (which is much smaller and may be missing iptables)?
No, I did not even download the factory-to-ddwrt.bin file until today, 26 Nov 2025.
Router/Version: Linksys MR7500
File: https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2025/11-21-2025-r62778/linksys-mr7500/dd-wrt-webflash.bin
Kernel: Linux 6.6.116-rt29 #4610 SMP Thu Nov 20 14:08:38 +07 2025 aarch64
Previous/Reset: R61848 --> Linksys OEM F/W --> r62778 factory-to-ddwrt --> r62778 webflash Obviously RESET was done by OEM F/W.
Mode/Status: Gateway device - NAS/Local FTP/Samba - OpenVPN server - DNSCrypt - A/P [WLAN0 : 1 SSID, 1 VAP] [WLAN1: 1 SSID, 1 VAP] [WLAN2: 1 SSID]
Issues/Errors: Cannot flash from or to R61848 directly, iptables rules consume vast amounts of memory that is already dangerously low, syslog & klog consumes too much memory storing the messages in /tmp/var/log/.
Note: Attempts #2 & #3 were additional attempts to flash r62778 webflash from r61848 that just proved to be exercises in futility.
-Starting with r61848 using SSH session to revert to OEM Firmware onto partition #1(Linux).
-Reboot
-OEM firmware started with stored configuration from mid-March.
-Flashed r62778 factory-to-ddwrt.bin from the OEM manual update URL.
-Got side tracked for couple hours while router rebooted.
-Changed username & password, clicked Save & Apply [Note: observed strange characters on save & apply button.]
-Used GUI to flash dd-wrt-webflash-r62778.bin without reset.
-Got sidetracked again during reboot.
-Logged in, enabled WAN port.
-Proceeded to manually reconfigure router with setting copied down from r61848.
-enabled syslog & klog and I executed nvram set console_debug=1
-ended up disabling syslog & klog and console debug as router kept crashing.
-Checked OOPS partition using strings /dev/mtdblock19. It was blank.
-Copy & pasted 44 IPTABLES rules in to Admin/Command dialog then clicked Save Firewall.
-After proofing and correcting a few typos I backed up my profile. Then power cycled router.
-I found router performance was rather sluggish and bandwidth was hovering around 1.8-2.2mbps out of the 1 Gbps available.
-Opened SSH session to check firewall activity - iptables -vnL & iptables -S
-The SSH session was incredibly slow, I watched each character being displayed/printed. It took almost 45 minutes to execute the two commands above. Reminded me of using a UNIX system via dot-matrix print terminal using 9,600 baud back in the 1970's.
-I found that the 44 entries I have in the FIREWALL script dialog on the admin tab some how turned into 564 entries. for every IPTABLES command there were 12 indentical copies of that one rule. The INPUT chain has 276 entries and the FORWARD chain had 288 entries. Copy of SSH session attached below. Didn't think I should paste 1,200 lines in this post.
-I turned off the router then rewrote my firewall rules using NFT commands. Example below.
Code:
iptables -A INPUT -i wan -s 66.132.148.0/24 -j DROP
rewritten as
nft 'add rule ip filter INPUT iifname "wan" ip saddr 66.132.148.0/24 counter drop'
-The example above does not produce any errors and appears in the ruleset list.
-However, the NFT rules are not being enforced. How do I know this? I submitted this post while the following rule is in place that is suppose to block all traffic to the IP ADDRESS for forum.dd-wrt.com (185.84.6.124). I tried adding a /32 to the end of daddr, but that caused an error.
Code:
nft 'add rule ip filter FORWARD ip daddr 185.84.6.124 counter drop'
-I tried using iptables-nft instead of iptables, which did not produce errors, nor did it save the rules. The command seems to do nothing other than return version information.
-I reverted back to the OEM firmware again since I learned flashing directly back to R61848 from R62778 results in a boot loop. Then flashed the r61848 factory-to-ddwrt.bin then flashed the r61848 webflash.bin then restored my save configuration from earlier today.
-Sometime this holiday weekend I will try R62606 since I read that USB is now working.
R62778-nftables.txt
Description:
SSH Session executing iptables -vnL & iptables -S. Copy & pasted into a text file.
I took some 'advice' from the internet and did the best I can 
