SOLVED Cloudron overrides iptables-persistent
I came to think about something like this:
- Run a script that monitors when cloudron is finished loading, and finished configuring iptables (after each restart/bootup)
- Then, when cloudron is complete restarted, script insert the needed custom iptables entries, and then run iptables-persistent.
There are probably much better ways to do it, but at least I am trying to think out a possible solution. But how to code that script and get it to do the stuff I want? Anyone able to help?
I run Plex on the same server as Cloudron (there's no official Plex app yet for Cloudron, although it's planned.)
I set up a script via cron that opens the necessary ports every XX minutes.
iptables -I INPUT -p tcp -m tcp --dport 32400 -j ACCEPT iptables -I INPUT -p tcp -m tcp --dport 32469 -j ACCEPT
You might have forgotten to dump the changed iptables configuration with:
Thanks @nebulon , that may be the problem, as I initially only ran the command
(I followed this guide: https://linuxconfig.org/how-to-make-iptables-rules-persistent-after-reboot-on-linux)
Now the iptables rules (inkl custom rules) persist after reboot, but then again...cloudron has had no reason to do changes.
So I provoked it by installing another app (wordpress-app). A few seconds after installation it said wordpress was running, but I could not access it. A few seconds later I could. So it seems it is working. (Maybe I should have tried another app, with other ports)
@necrevistonnezr maybe you could also benefit from looking at iptables-persistent? https://linuxconfig.org/how-to-make-iptables-rules-persistent-after-reboot-on-linux
@stoccafisso https://cloudron.io/documentation/security/#block-ips has the necessary commands to make iptable changes persist.
Now that we can whitelist ports (even though it might not work as expected?), does it interfere with iptables-persistent? Should one remove the package and / or entries in
It's better to use Cloudron's built-in IP block list and port white list. I think maybe iptables persistent probably still works OK but we don't really test it actively.
So can we delete
@girish Great, everything worked as expected.