Is changing Iptables in Asuswrt-Merlin considered acceptable network management practice?

[CornfieldWin]

I am soliciting input whether or not this Google AI generated advice is considered correct and acceptable Asuswrt-Merlin network management practice or not, and thank you for your responses:

Create or Edit the Startup Script:

• Connect to your router via SSH or SCP (e.g., using PuTTY or WinSCP).
• Navigate to the /jffs/scripts/ directory.
• Create a new file or edit an existing one, such as firewall-start or nat-start, depending on the type of iptables rules you are adding.
  • firewall-start is executed when the firewall service starts.
  • nat-start is executed when the NAT service starts, suitable for NAT-related rules (e.g., port forwarding).
    

3. Add iptables Rules to the Script:

• Open the chosen script file (e.g., firewall-start) with a text editor.
• Add your iptables commands to this script. Ensure the script begins with #!/bin/sh.
  

Code

iptables -I INPUT -p tcp --dport -j ACCEPT</span><br>
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 8080 -j DNAT --to-destination192.168.1.100:80
4. Make the Script Executable:

• After saving the script, make it executable using the chmod command:
  

Code

chmod +x /jffs/scripts/firewall-start
(Replace firewall-start with the actual script name if different.)

5. Reboot the Router:

• Reboot your router to ensure the script is executed and the iptables rules are applied during startup.
  

 

[bennor]

@CornfieldWin, it may help if you explain why you are seeking to modify the iptables. What specific issue are you having or trying to address that you are seeking to modify the iptables to address?

If you haven't done so already, there are many examples of iptables scripting that can be found using the forum search feature. Many use the scripting to address specific issues or accomplish specific things.

PS: Just one example to address a specific issue. Basic directions for setting up and using a /jffs/scripts/firewall-start script file to accomplish a specific task:
https://www.snbforums.com/threads/t...st-network-pro-limitations.94438/#post-952345
More on Asus-Merlin firmware custom scripting can be found at the Asus-Merlin Wiki:

Custom config files

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

Iptables tips

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

 

[CornfieldWin]

@CornfieldWin, it may help if you explain why you are seeking to modify the iptables. What specific issue are you having or trying to address that you are seeking to modify the iptables to address?

If you haven't done so already, there are many examples of iptables scripting that can be found using the forum search feature. Many use the scripting to address specific issues or accomplish specific things.

Because I was told by Colin Taylor and RMerlin himself that it was wrong, all firewalls rules are involate as "built-in to the firmware". The above as summarized was wrong and that was somehow disrespectful of people I never met nor meant to insult. I don't understand this groups dynamics but I will never engage or attempt to contribute to it again. Passive surveillance is enough with a heavy trust but verify because I don't like being intentionally demeaned.

 

[bennor]

Because I was told by Colin Taylor and RMerlin himself that it was wrong, all firewalls rules are involate as "built-in to the firmware". The above as summarized was wrong and that was somehow disrespectful of people I never met nor meant to insult. I don't understand this groups dynamics but I will never engage or attempt to contribute to it again. Passive surveillance is enough with a heavy trust but verify because I don't like being intentionally demeaned.

Not sure if something is getting lost in context or maybe through language translation or cultural translation. For those wondering, the following link is what is being referenced.
https://www.snbforums.com/threads/where-are-the-default-iptables-stored.40042/#post-969155

As the developer indicated, eight years ago, the "default rules" (which is what the original poster was asking about) are configured by the firmware code. The end user can add their own custom code that modifies, or adds to, the "default rules" through the use of custom scripting. @ColinTaylor likewise pointed out like the developer did that "non-custom rules" are generated by the firmware.

 

[RMerlin]

Because I was told by Colin Taylor and RMerlin himself that it was wrong, all firewalls rules are involate as "built-in to the firmware".

I never said that. What I said was they were generated by the firmware, and not by a user-editable script.

And in fact, I implemented the firewall-start and nat-start scripts specifically to allow users to customize the rules that the firmware generated. These two scripts do not exist in the stock firmware, and they are intended to allow users to modify the rules generated by the firmware.

 

[CornfieldWin]

Not sure if something is getting lost in context or maybe through language translation or cultural translation. For those wondering, the following link is what is being referenced.
https://www.snbforums.com/threads/where-are-the-default-iptables-stored.40042/#post-969155

As the developer indicated, eight years ago, the "default rules" (which is what the original poster was asking about) are configured by the firmware code. The end user can add their own custom code that modifies, or adds to, the "default rules" through the use of custom scripting. @ColinTaylor likewise pointed out like the developer did that "non-custom rules" are generated by the firmware.

Sorry, in my most respectful Canadian way, I ask does the following sound wrong or worthy of reprimand:

"The rules are built by shell scripts computing and issuing iptables commands, so there is no passive and declarative file, just the /jffs/scripts/firewall-start script doing its thing to kickoff the entire nearly incomprehensible process.

The convention to add your own rules or override the defaults is to put your iptables commands at the end of /jffs/scripts/firewall-start or possibly create /jffs/scripts/nat-start and make it executable for nat rules. When the router boots or the services restart those scripts will run."

To which Colin Taylor replied:

"Why are you replying to a post that's over eight years old? [Ok, that's highly cultural. Then why do you leave them open?] Your answer is also incorrect. The non-custom rules are not built by those user shell scripts but rather they are generated by the firmware code as previously stated by the developer." Who had replied: "There are no "default rules", everything is configured by the firmware code" [errata: configured in package generation but Iptable entries are literally built at run time by the shell script]. For the past fifty years, there are no UNIX/Linux rules in the usual sense, only iptables commands generally embedded in shell scripts with further computational conditions that manipulate a dynamically created linearly scanned internal packet filtering rule set which many non-UNIX users do not understand as the OP almost certainly did not.

It is somewhat unusual to confuse code generation with the running of the code generated which is all that the user sees and that is a shell script invoked in a single line by a service restart script. There may be legitimate confusion with the upstream software generation (possibly in C or awk or yacc) that creates the executable shell script, but end users are not in that loop so why even mention it. I was doing this in 1980 including then unheard of self installing scripts for NASA fluid dynamics software as a bizarre specialty. This comment was followed by another terse comment: "They're in the firmware, but those are in the realm of the 3rd rail - touch them in the firmware, and you'll die. [Note: of course you can't, users never see the upstream stage]. There is a mechanism to extend them via scripts - there's plenty of posts/threads on how to do this..." which nobody can say why my simple explanation above was wrong as claimed by Colin Taylor.

RMerlin then shut the thread thereby blocking clarification leaving me with a reprimand that is inaccurate and no way to respond. When I asked how was I wrong, I could get no response. The technology has not changed. Custom internal Iptables rules are built by the same shell script that runs when the user does a restart, extending them is not a third rail but requires careful thought, and this is done by modifying the system supplied startup script exactly as described. It is very reasonable to assume the OP was seeking such a means as was I at that point which is generally what a user means when they ask how to modify default behavior of a system feature.

 

[Ripshod]

 

[bennor]

Sorry, in my most respectful Canadian way, I ask does the following sound wrong or worthy of reprimand:

"The rules are built by shell scripts computing and issuing iptables commands, so there is no passive and declarative file, just the /jffs/scripts/firewall-start script doing its thing to kickoff the entire nearly incomprehensible process.

The convention to add your own rules or override the defaults is to put your iptables commands at the end of /jffs/scripts/firewall-start or possibly create /jffs/scripts/nat-start and make it executable for nat rules. When the router boots or the services restart those scripts will run."

For context and completeness, lets post your entire post including the first sentence which you neglected to include in your reply to my post:

Hard to believe these comments have lasted so long as I have had to begin the same journey. First, Merlinwrt is the firmware which is an embedded linux system, get over it.

The rules are built by shell scripts computing and issuing iptables commands, so there is no passive and declarative file, just the /jffs/scripts/firewall-start script doing its thing to kickoff the entire nearly incomprehensible process.

The convention to add your own rules or override the defaults is to put your iptables commands at the end of /jffs/scripts/firewall-start or possibly create /jffs/scripts/nat-start and make it executable for nat rules. When the router boots or the services restart those scripts will run.

What is your point to belabor complaining about the earlier 8 year old necroposted thread being locked?
Do you have a specific issue or problem that you wish to address by modifying the default iptables through the use of a firewall-start custom configuration file? If so what is it? What problem or issue do you seek to address by using a custom configuration file to modify the default firmware/GUI iptables?

 

[CornfieldWin]

Now that I got that off of my chest, here's my summary as one who went from systems programmer, general salt mine programmer, system architect, application architect, business analyst, and program manager. The user asked a simple question how to control the behavior of an important system feature whose operation was exposed to them but not the nature of the internal mechanism. A reasonable question. The developers answered in narrow terms that as an architect I would have corrected. Further as a program manager I would have had them treat the customer with more respect.

The proper answer showing equal deference to all would have been to say that it is not recommended to change the default firewall behavior with which the system starts but with great care it is possible to augment it after starting. Due to the nature of the system internals, there is no simple way to configure this with a fill-in-blanks in the GUI as it is for some other simpler features. Making these augmenting changes is not be undertaken lightly because it requires adding Iptable entries in the CLI to the end of the firewall starts script. Do you want further details? [No need to threaten execution if the answer is yes].

So there you go, maybe it was a culture issue after all, developer versus pesky end user.

 

[CornfieldWin]

For context and completeness, lets post your entire post including the first sentence which you neglected to include in your reply to my post:


What is your point to belabor complaining about the earlier 8 year old necroposted thread being locked?
Do you have a specific issue or problem that you wish to address by modifying the default iptables through the use of a firewall-start custom configuration file? If so what is it? What problem or issue do you seek to address by using a custom configuration file to modify the default firmware/GUI iptables?

It was not locked. I think ego is driving the objections. My point regarded the general approach as was the question and response sequence. Yeah I have questions and will post them post them separately as such. Believe it or not, I like this forum but do not like being sniped at for the whole world to see.

 

[bennor]

It was not locked.

Yes it was after the back and forth. Note the text at the top/bottom of that thread, it states: Not open for further replies.

 

[RMerlin]

Custom internal Iptables rules are built by the same shell script that runs when the user does a restart, extending them is not a third rail but requires careful thought, and this is done by modifying the system supplied startup script exactly as described.

There is no startup script. This isn't a SystemV or systemd Linux system. This is all handled by the monolithic rc process which dynamically generates and executes the iptables commands when a "restart_firewall" requests is sent to it. Once that's done, then it will check if there is a firewall-start script that exists, and if so, execute it after it's done, giving users a chance to modify what was already applied.