New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
iptables not loading rules on CentOS 6.8
I need some help to find what I clearly am missing here....
I'm usually an debian user but it should be pretty same setup.
Problem I'm having:
Iptables is in status "not running" after every reboot, meaning no rules are loaded.
This is what I've done so far:
- my rules are defined in /etc/sysconfig/iptables ( iptables-save )
I've ran
chkconfig --level 345 iptables on
result:iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:offif I login and run
service iptables startall rules are loaded and all is good. After a restart it's not automaticly loaded.
What have I missed?????? Help!
Comments
Do you have a rule with a domain name?
Do you have other stuff that runs later in the initlevel which resets iptables?
Check if firewalld is installed if its there and you want iptables then you want to remove the firewalld
And this may help http://unix.stackexchange.com/questions/71661/iptables-rules-not-reloading-on-centos-6-x
When I was new with CentOS (Im working mainly with SUSE) I had this problem too.
But I have no time to find out the cause so I just come with barbaric solution by using shell script invoked by systemd.
and it worked perfectly until today.
No. All rules are written as IP. when rules are loaded, the RDNS shows instead of the IP, that is by design I guess?.
This might actually be the reason ... I have virtualizor running and I wouldn't be surprised if they have their own config files saved somewhere and that way controlling what to run.
Let me get back to you on that.
Thanks so far, sometime you need to step away from the issue at hand to see the real problem.
quick update, virtualizor uses the same config files. It just doesn't start the firewall.
Would like to avoid that solution unless it's the only solution.
do you use ipsets in your rules?
those won't get saved by iptables-save and without the hashsets created your rules might fail on load. may be some other scripts create the necessary ipsets during bootup, but later then iptables tries to restore its rules - that might explain why you can't restore them manually when the system is up.
not using ipsets, not intentionally
Rules are saved, not loaded on boot. I have to manually run
service iptables startorservice ipteables restartto successfully load the rules.So there is nothing wrong with the rules since it can load it, it just won't on boot.
that's quite odd have you checked which runlevel you are on?
That's the last re-sort mate let's fix it for once and all
i guess there might be issue with firewall configuration
run-level 3 2017-03-13 09:02I can start it manually so the iptables config is working. It's just not starting at boot.
ln -s /etc/init.d/iptables /etc/rc3.d/S99iptables_doitbitchAt boot time, iptables is started before the network is up.
When you run it manually, the network is up.
So there could be something in your saved rules that is preventing it from starting at boot.
Post your /etc/sysconfig/iptables....
https://gist.github.com/mikho/0fe34977626d2f57dca6946b9f6c3f3b
This could be the reason.... it's Hetzner and the network is dhcp assigned. I will test with a static IP and see what happens.
That didn't change a thing
I'm pretty sure firewalld is a RHEL/CentOS 7 only thing.
For reference and comedy: https://www.centos.org/forums/viewtopic.php?t=57051
There are some questions. Which of the scenarios below fits the situation?
1) After a reboot,
service iptables statusreturns "It's dead Jim."service iptables restartstarts iptables without any problems, andiptables -L -nshows the correct tables.2) After a reboot,
service iptables statusreturns "OK", butiptables -L -nreturns nothing but empty tables. A third-party script to "restart" iptables is run, and afterwardsiptables -L -nshows the correct tables.Honestly, I would cut everything in the pre and post routing chains, and make sure the basic rules worked. Then bisect the rules which were cut to figure out where the error is.
after a reboot
service iptables statusreturnsiptables: Firewall is not running.iptables -L -nreturnsChain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
empty iptable
I'm currently leaning on the solution that the network is not up and therefor iptables cannot start.
Guess my last resort is in the link that @simonindia posted
--permanent should be added at the end of syntax.
Have you tried with just a single basic rule and see if it allows iptables to load after reboot? If so, something is wrong with your rules at bootup.
Are you sure you aren't using hostnames in /etc/sysconfig/iptables ?
Last resort: Add a command to restart iptables in /etc/rc.d/rc.local
check the /etc/rc... folders to see if there are correct symlinks for iptables to start at all (see @WSS comment above) with renaming of the link and therefore changing the order you might influence the time iptables gets started...
I'm a Debian user - so take what I say with a pinch of salt (as applied to RedHat etc.).
One issue that I had some time back (proxmox!) was with systemd (I don't usually use systemd but proxmox needs it) and iptables.
Due to the way iptables works, it grabs a lock and if there are multiple iptables operating processes, the lock can cause them to quit (and not do anything). Systemd runs things concurrently and so there may be instances of locking if you're doing anything different/unusual for iptables.
The way I fixed this was to manually run things via rc.local after putting in a sleep for about 10s (ugly but works consistently).
While this may not solve the problem, it may give you a clue.
Also, enabling the verbose setting for networking may give you a bit of a clue via logs.
YMMV.
Tried with virtualizor default rules. Same issue.
See my gist posted above.
I'm leaning towards this.
Have you checked the output of
dmesgfor anything relevant.Or /var/log/messages...
@sleddog
No errors in the logs, only notices that its available and module is loaded.
Guess I have to resort to do a "fix" for it.
Thank you all for brainstorming.
well..... the test to manually adding iptables-restor in rc.local failed. Firewall wasn't running after a reboot. With that in mind it must be something that shut it down after a reboot.
look what I found in /etc/init.d/virtualizor
if [ -f /etc/redhat-release ] ; then # Distro check for centos 7 if [ -f /usr/bin/systemctl ] ; then /bin/systemctl stop iptables.service >> /dev/null #/bin/systemctl stop firewalld >> /dev/null else /etc/init.d/iptables stop >> /dev/null fi fi@virtualizor
Why?
And where do I make sure that iptables is running after a reboot?
For now I've commented out the
iptables stopcommand...You mean you didn't run
grep -irl iptables /etc/to check on things and wasted all our invaluable time with this?I mean you do realize how much harder I'd have idled. Sigh. I could have just kept refreshing LETs home page instead of reading through the various sensible posts on this thread.
Now to get back to some of the drama threads that I've missed.
They really shouldn't be doing that. There are plenty of reasons to have iptables running, and only one not to (bad initial rulesets).
I'd recommend shooting them a message to point out how dumb that script is.