Skynet Skynet v8 - Router Firewall & Security Enhancements

[dave14305]

Is saveipset a safe permanent substitute for save in the hourly cron?

No, saveipset doesn’t exist. Is this a recommendation from AI?

 

[rosco9911]

You're correct and I appreciate the correction. That recommendation came from AI assistance and was wrong — saveipset is not a valid v8 command. What I'm actually trying to solve is: Skynet's hourly firewall save triggers notify_rc restart_firewall, which causes YazFi to rebuild all guest network chains for ~19 seconds every hour, dropping all VLAN devices. Is there a supported way in v8 to save ipsets without triggering a full firewall restart? I have custom MAC-based RETURN rules in PREROUTING inserted via a YazFi userscript that appear to be flagged as integrity violations.

 

[dave14305]

I have custom MAC-based RETURN rules in PREROUTING inserted via a YazFi userscript that appear to be flagged as integrity violations.

I was going to say that the firewall should not restart unless an ipset or iptables rule is missing. What specifically does the log say about rule integrity? What does your custom rule look like?

 

[rosco9911]

Here's what I have. The raw table only has 6 rules total, but the integrity violation reports missing rules at positions #14 and #15:

Chain PREROUTING (policy ACCEPT)
num pkts target prot in
1 LOG all br+ (outbound block log)
2 DROP all br+ (outbound block)
3 LOG all eth0 (inbound block log)
4 DROP all eth0 (inbound block)
5 LOG all wgs+ (outbound block log)
6 DROP all wgs+ (outbound block)

The table ends at rule 6 — rules #14 and #15 simply don't exist. Skynet appears to place rules at those higher positions on initialization, but something is stripping the raw table back to 6 rules (my guess is YazFi's hourly firewall rebuild via its */10 * * * * check cron), which Skynet then detects as missing and triggers restart_firewall to restore them.

My custom Ring bypass rules are in iptables -t nat, not raw table, so those are unrelated.

Is the YazFi interaction rebuilding the raw table and displacing Skynet's rules the likely cause here? And if so, is the correct fix to have the YazFi userscript re-insert Skynet's raw table rules after each rebuild, or is there a better approach?

 

[dave14305]

The table ends at rule 6 — rules #14 and #15 simply don't exist.

Failures for #14 and #15 are related to iot ports and rules within Skynet. It's not a rule number, but a check number. Did you configure iot blocking in skynet? What do you get from this command?

iptables -S FORWARD | grep Skynet

 

[rosco9911]

Failures for #14 and #15 are related to iot ports and rules within Skynet. It's not a rule number, but a check number. Did you configure iot blocking in skynet? What do you get from this command?

iptables -S FORWARD | grep Skynet

Update on the integrity violation for #14 and #15:

After reviewing the full FORWARD chain, I found two custom rules at positions 7 and 8 that I had previously added to allow my trusted LAN (br0) access to a printer on the IoT VLAN (wl0.1). I have removed both of those rules from the live chain to eliminate them as a variable. The integrity violation persists after removal — firewall debug info still shows [Failed] with Rule Integrity Violation - [ #14 #15]. Those custom rules were not the cause.

Current state: Skynet IoT blocking is Enabled. The 6 IoT rules are present at positions 1–6 in FORWARD, and no custom rules are present below them.

Output of iptables -S FORWARD | grep Skynet:

-A FORWARD -i br+ -o eth0 -p icmp -m set --match-set Skynet-IOT src -j ACCEPT
-A FORWARD -i br+ -o eth0 -p tcp -m set --match-set Skynet-IOT src -m tcp -m multiport --dports 80,443,53,123 -j ACCEPT
-A FORWARD -i br+ -o eth0 -p udp -m set --match-set Skynet-IOT src -m udp -m multiport --dports 80,443,53,123 -j ACCEPT
-A FORWARD -i br+ -o wgs+ -m set --match-set Skynet-IOT src -j ACCEPT
-A FORWARD -i br+ -m set --match-set Skynet-IOT src -j LOG --log-prefix "[BLOCKED - IOT] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A FORWARD -i br+ -m set --match-set Skynet-IOT src -j DROP

Note: My hourly cron was temporarily changed to firewall saveipset yesterday as a troubleshooting attempt, which silently did nothing and masked the restarts. Reverting it to the standard firewall save is what caused the drops to reappear — the underlying violation seems to be pre-existing.

Is there something specific about the logging flags or the way these rules are formatted that would cause checks #14 and #15 to fail even though the rules are present?

 

[dave14305]

-A FORWARD -i br+ -o eth0 -p tcp -m set --match-set Skynet-IOT src -m tcp -m multiport --dports 80,443,53,123 -j ACCEPT
-A FORWARD -i br+ -o eth0 -p udp -m set --match-set Skynet-IOT src -m udp -m multiport --dports 80,443,53,123 -j ACCEPT

Is there something specific about the logging flags or the way these rules are formatted that would cause checks #14 and #15 to fail even though the rules are present?

Skynet is sadly looking for a string match of the rule, but the output of the output interface in your example is in a different position than Skynet expects:

-A FORWARD -i br+ -m set --match-set Skynet-IOT src -o $iface -p udp -m udp -m multiport --dports $iotports -j ACCEPT
-A FORWARD -i br+ -m set --match-set Skynet-IOT src -o $iface -p tcp -m tcp -m multiport --dports $iotports -j ACCEPT

It was easier when Skynet used to check for the rules using iptables -C (for check). It's a bug since 8.0.0.

 

[Radon]

Skynet v8 - Router Firewall & Security Enhancements

The largest upgrade in Skynet’s 11-year history

Built exclusively for ASUSWRT-Merlin, Skynet v8 delivers a fully modernised codebase with major performance, reliability, and maintainability improvements - while keeping the familiar interface users already know.

What’s New in v8 (full list of changes available on GitHub)

Firewall, DNS, and IPSet improvements

• Unified IPSet handling through new IPSet_Wrapper()
• Converted core ipset code to wrapper (rollout ongoing)
• Domain lookup timeout control - prevents long stalls
• CIDR attribution accuracy improved in stats
• Country lookup only when enabled, with safer handling of malformed data

Race condition & concurrency fixes

• New lock management using flock
• Runtime/age of locks shown in logs for easier diagnosis
• Safe stale lock cleanup with ownership checks
• Trap-based cleanup on exit to prevent orphaned locks
• Race conditions reduced in parallel execution paths

Stability & network hardening

• Refactored Check_Connection() and DNS lookups
• Reduced IPTables workload (no more process flooding)
• Improved NTP sync validation

Menu system modernisation (in active development)

• Show_Menu() - easier, more consistent menu creation
• Prompt_Input() / Prompt_Typed() - validated user input
• Unified navigation and clearer error handling
• Reduced nesting for simpler, more readable flow

Stats & event logging enhancements

• New Run_Stats() system for cleaner statistics
• Added Show_Associated_Domains()
• Improved block reasons, including CIDR correlation
• Startup banners preserved (last 3) instead of being purged immediately
• Custom log size support:
  

  sh /jffs/scripts/firewall settings logsize 20

Code quality & compatibility

• ShellCheck compliance improvements across the script
• Shorter curl paths and safer download logic
• VSCode formatting / phrasing issues resolved
• "debug run xxx" now supports arguments for easier testing
• Improved internal documentation and function comments

Swap + storage handling

• Simplified swap detection logic
• Detect and repair dnsmasq additional config permissions
• New find_install_dir() helper for locating the install path

------------------------------------------------------------

------------------------------------------------------------
How To Install

SSH:

/usr/sbin/curl -fsL "https://raw.githubusercontent.com/Adamm00/IPSet_ASUS/master/firewall.sh" -o "/jffs/scripts/firewall" && chmod 755 /jffs/scripts/firewall && sh /jffs/scripts/firewall install

Or install from AMTM:

amtm

Example startup output:

Nov 15 10:26:54 Skynet: [i] Startup Initiated... ( skynetloc=/tmp/mnt/USB/skynet )
Nov 15 10:27:15 Skynet: [#] 33467 IPs (+0) -- 2365 Ranges Banned (+0) || 0 Inbound -- 0 Outbound Connections Blocked! [start] [20s]

------------------------------------------------------------
Support & issue tracking

For reproducible issues, enhancement requests, or deeper technical investigation:

Please use the GitHub Issue Tracker where development is active and changes are tracked.

General questions and discussion are welcome in this thread.

------------------------------------------------------------
Open Source - Free Forever

Skynet is hosted on GitHub.

If you'd like to support ongoing development:

• PayPal donation link

Every contribution helps - from funding test hardware to covering development time.

------------------------------------------------------------
Looking ahead

• Full IPv6 Support
• Continued menu modernisation
• Improved WebUI (Community assistance required)

Thank you for this awesome FW. Nothing particular on the country blocking, just keeping the WWW not so Wide.

 

[rosco9911]

Skynet is sadly looking for a string match of the rule, but the output of the output interface in your example is in a different position than Skynet expects:

-A FORWARD -i br+ -m set --match-set Skynet-IOT src -o $iface -p udp -m udp -m multiport --dports $iotports -j ACCEPT
-A FORWARD -i br+ -m set --match-set Skynet-IOT src -o $iface -p tcp -m tcp -m multiport --dports $iotports -j ACCEPT

It was easier when Skynet used to check for the rules using iptables -C (for check). It's a bug since 8.0.0.

Thank you Dave, that explains it perfectly. It's a relief to know the IoT rules are actually functioning correctly and this is purely a string-matching bug in the integrity checker since v8.0.0.

Since the hourly integrity check failure is triggering restart_firewall and dropping my VLANs for ~20 seconds every hour, I need a workaround while waiting for Adamm to patch it. Would running firewall iot disable be the appropriate temporary fix, or is there a better approach you'd recommend?

 

[dave14305]

Since the hourly integrity check failure is triggering restart_firewall and dropping my VLANs for ~20 seconds every hour, I need a workaround while waiting for Adamm to patch it. Would running firewall iot disable be the appropriate temporary fix, or is there a better approach you'd recommend?

I created a pull request to fix it. Hopefully it's the same output on all the various firmware branches.

fix IOT rule checks for proper param order by dave14305 · Pull Request #194 · Adamm00/IPSet_ASUS

Creates false integrity violations when iotports is populated. Actual output from 3006.102.7_2 iptables: -A FORWARD -i br+ -o eth0 -p tcp -m set --match-set Skynet-IOT src -m tcp -m multiport --dpo...

github.com

 

[rosco9911]

I created a pull request to fix it. Hopefully it's the same output on all the various firmware branches.

fix IOT rule checks for proper param order by dave14305 · Pull Request #194 · Adamm00/IPSet_ASUS

Creates false integrity violations when iotports is populated. Actual output from 3006.102.7_2 iptables: -A FORWARD -i br+ -o eth0 -p tcp -m set --match-set Skynet-IOT src -m tcp -m multiport --dpo...

github.com

Thank you for filing the fix so quickly — much appreciated! I'll run firewall update -f to check if it's already available. If the PR hasn't been merged yet, I'll temporarily disable IoT blocking to stop the hourly restarts in the meantime. Will re-enable once the patch is live.

 

[jksmurf]

A recent amtm 'u' update check showed SkyNet had a 8.0.10 → MD5 upd.

When I go into the Skynet menu and select (10), (1) for a check and intsall update, I get an error:

Lock file busy but metdata invalid (pid=' ') - another Skynet instance is running - Exiting

When I try to disable it temporarily with (9), same error.

How do I get past this please?

[EDIT] OK fixed it I think. Issued this, redid the udpate check. No idea how it got stuck though.

rm -f /tmp/skynet.lock