Does firewall-start Script Ever Run Twice With Same iptables Rules?

[HarryMuscle]

I just wanted to confirm, do I have to check if any iptables rules that I'm adding via the firewall-start script have already been added before? In other words does the firewall-start script ever run more than once with the same iptables rules or do all the iptables rules always get wiped and recreated before the firewall-start script gets called?

Thanks,
Harry

 

[drinkingbird]

I just wanted to confirm, do I have to check if any iptables rules that I'm adding via the firewall-start script have already been added before? In other words does the firewall-start script ever run more than once with the same iptables rules or do all the iptables rules always get wiped and recreated before the firewall-start script gets called?

Thanks,
Harry

It gets called twice at startup and anytime you change firewall in the GUI. Your script should always delete the rules before adding them to prevent duplicates.

In other words, every rule you add, do the exact same rule with -D right above it, 2 copies of each rule in your script. If the rule doesn't exist, no harm, if it does, it makes sure no duplicates.

The only time custom rules are removed is when you reboot the router.

 

[Ranger802004]

I build all of my firewall rules in there with if statements to check and see if they already exist before creating them.

 

[drinkingbird]

I build all of my firewall rules in there with if statements to check and see if they already exist before creating them.

A more elegant but also more complex method, I'm lazy so I just delete before adding

 

[SomeWhereOverTheRainBow]

A more elegant but also more complex method, I'm lazy so I just delete before adding

Another more complicated method is just to de-dupe each table at the end of each firewall run.

/usr/sbin/iptables-save | awk '/^COMMIT$/ { delete x; }; !x[$0]++' | /usr/sbin/iptables-restore
/usr/sbin/ip6tables-save | awk '/^COMMIT$/ { delete x; }; !x[$0]++' | /usr/sbin/ip6tables-restore

 

[Maverickcdn]

Am I wrong in thinking that whenever the firmware calls firewall-start (including service restart_firewall) it first runs iptables -F to flush all the tables and then reloads the default rules plus whats in firewall-start

I've never seen duplicate rules, but I just removed a for loop in firewall-start that was setup to delete rules first then add... this conversation has me second guessing if I should re-add it

 

[drinkingbird]

Am I wrong in thinking that whenever the firmware calls firewall-start (including service restart_firewall) it first runs iptables -F to flush all the tables and then reloads the default rules plus whats in firewall-start

I've never seen duplicate rules, but I just removed a for loop in firewall-start that was setup to delete rules first then add... this conversation has me second guessing if I should re-add it

Not doesn't flush on restart only reboot. I had duplicates (2 after each restart and more as time went on) until I added the deletes.

Well I guess I should say I don't know if restart does or not as I didn't test that specifically but the script gets called twice at startup (not sure if it does a firewall restart then or not) and some GUI changes would result in more.

 

[ColinTaylor]

Am I wrong in thinking that whenever the firmware calls firewall-start (including service restart_firewall) it first runs iptables -F to flush all the tables and then reloads the default rules plus whats in firewall-start

Yes that's pretty much it. It rebuilds the ruleset and then uses iptables-restore rather than explicitly flushing the rules with iptables -F though. You can see the rules it's using in the /tmp directory. It then runs your custom firewall-start script.

Bear in mind that the firewall-start script is called with the interface as the parameter which caught me out once when I was using a dual WAN setup. So it might be prudent to check that parameter depending on your circumstances.

The biggest problem is really from other bespoke scripts that directly modify the rules. These changes are often lost when the firewall is restarted. Conversely, I wrote a script that inserted firewall rules when OpenVPN started up and found these just kept on accumulating every time I restarted the VPN.

 

[Maverickcdn]

Not doesn't flush on restart only reboot. I had duplicates (2 after each restart and more as time went on) until I added the deletes.

Well I guess I should say I don't know if restart does or not as I didn't test that specifically but the script gets called twice at startup (not sure if it does a firewall restart then or not) and some GUI changes would result in more.

I don't reboot (AsusWRT-Merlin is too stable haha)

Thanks at @ColinTaylor for the clarification.

I wrote a script that inserted firewall rules when OpenVPN started up and found these just kept on accumulating every time I restarted the VPN.

I may have never noticed an issue as I have a separate script with cron @ 2mins that verifies my rules in INPUT/FORWARD and will run service restart_firewall if an error is found as the majority of my rules are related to my ovpn and web servers. I do notice like you mentioned that the ovpn server startup(restart) will always place the vpn port accept rule as #1 in INPUT and my verification script runs and corrects this. I would assume you had your rules you were adding tied to an openvpn event?

 

[ColinTaylor]

I would assume you had your rules you were adding tied to an openvpn event?

Yes, mostly. I also had some rules in openvpnserver1.postconf at one time. But you have to do the "delete then insert" dance because these scripts aren't really designed for firewall changes. You end up having to duplicate the rules in firewall/nat-start anyway as restarting the firewall doesn't run the OpenVPN scripts, and restarting OpenVPN doesn't restart the firewall. All very tedious.

 

[Ranger802004]

Yes, mostly. I also had some rules in openvpnserver1.postconf at one time. But you have to do the "delete then insert" dance because these scripts aren't really designed for firewall changes. You end up having to duplicate the rules in firewall/nat-start anyway as restarting the firewall doesn't run the OpenVPN scripts, and restarting OpenVPN doesn't restart the firewall. All very tedious.

I found it best to put rules for OpenVPN in the openvpn-event script.

 

[ColinTaylor]

I found it best to put rules for OpenVPN in the openvpn-event script.

Yes that's what I mostly did (as implied by my reply to Maverickcdn's post). However that led to the problems I described.

 

[SomeWhereOverTheRainBow]

Yes that's what I mostly did (as implied by my reply to Maverickcdn's post). However that led to the problems I described.

I have observed the same issues as well. I am always taken back when all the nay say'ers come out to say that delete rules are not needed. It is easier to use delete rules then to "check" for rules, before adding. However, I think when you delete a ton of rules in a row (instead of flushing) it is kinda like Nuking the IPtables. No tellin' what kind of instability it will create with a large set of rules.

 

[drinkingbird]

I have observed the same issues as well. I am always taken back when all the nay say'ers come out to say that delete rules are not needed. It is easier to use delete rules then to "check" for rules, before adding. However, I think when you delete a ton of rules in a row (instead of flushing) it is kinda like Nuking the IPtables. No tellin' what kind of instability it will create with a large set of rules.

As long as you're specific and delete exactly the rule you're adding, it shouldn't be an issue, of course if you have a massive ruleset then it makes more sense to find a better solution (like flush and reload the default ruleset before adding yours, or using a check method like others have posted).

For my relatively basic ruleset the delete before add has worked perfectly. No VPN or anything though, just for controlling communication between guest and main etc.