Xentrk
Part of the Furniture
Here is the link to the source code in the wikiIf the same code block is in place you run the very same risk on that router also. What this "legacy code" does from my brief look is;
I personally find the need for this code quite bad from a scriptwriters standpoint. I think that scripts should be smart enough to handle their own rules and "fix" themselves in the event something goes wrong. Because in this case, a wildcard rule has caused a complete loss of connectivity (the blocked countries rule would eventually cause issues too)
- A for loop listing all current loaded IPSets
- If the IPSet name matches a particular name, it checks for an IPTables rule via a very basic pattern check. If there are no grep matches it creates a new rule
- If the IPSet name doesn't match any of the listed patterns, it defaults to the wildcard match. This will basically force a IPTables drop rule regardless of the IPSets intended purpose.
Now the question is what exactly happened to your setup. I can see a point of failure being if Skynet is initially loaded correctly, then the firewall-start event is called again. During this event only IPTables rules are flushed (not the IPSets themselves). So upon restart this "legacy code" would have listed all Skynets IPSets still loaded in ram and defaulted to the wildcard drop entry listed. This means all 3 IPSets (including the Whitelist with a bunch of important Private IP's) would have had some generic drop entry.
Usually if this code wasn't present, Skynet is smart enough to deal with situations like this and proceed as expected. So I highly suggest removing this code from both routers.
You can just simply delete it, Skynet will generate the file during the install process with a shebang and the appropriate permissions etc.
https://github.com/RMerl/asuswrt-me...atchip-utility---search-ipset-lists-for-an-ip