top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

IPtables: if you reboot the machine configurations are not loaded?

+1 vote
421 views

I have a problem with iptables on CentOS 6.2.

I configured:

chkconfig iptables on
and the file /etc/sysconfig/iptables

If you reboot the machine configurations are not loaded. iptables-L gives me the default configurations (not assigned) if I (a machine booted): service iptables start then then it works. How can I fix?

posted Oct 10, 2013 by Kumar Mitrasen

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

+1 vote 
chkconfig iptables on

fixes the problem..

answer Oct 10, 2013 by Sumit Pokharna
I had already given the command but do not load configurations
commented Oct 10, 2013 by anonymous
+1 vote

After service iptables start do:

service iptables save

This saves your configuration for the next restart / reboot

answer Oct 10, 2013 by Ahmed Patel
thank you for your help, I solved the problem but until now it had never happened with the VPS.
iptables first started out and then edit the file /etc/sysconfig/iptables
and chkconfig iptables on
commented Oct 10, 2013 by anonymous
Similar Questions
+1 vote
Getting iptables not to reply

If you have an 'accept' rule for a service that is not currently running, is it possible to have iptables to simply not respond instead of reporting the port as 'closed'? During a port scan at grc.com, if the router doesn't reply the port will be reported as 'stealth'.

0 votes
IPTables not flushing on Fedora?

I'm playing around with iptables and have inserted a few new rules. Now, I want to flush them all so I use

iptables -F

Then, I restart the firewall with

service iptables restart

and everything looks like it's restarting alright. But when I list the rules using

iptables -L

I get a list of rules THAT INCLUDE all of the rules I've defined before the flush! Am I reading this wrong or is something weird with my iptables?

+2 votes
how to replace the next iptables rule with nft?

Can someone help on how to replace the next iptables rule with nft:

iptables -t raw -A PREROUTING -i eth0 -j CT --notrack

Is this possible with nft or not?

0 votes
iptables with logging vs denyhosts

I have been using denyhosts for almost a year. To date I have only prevented one person logging in and that is ME ( I used the wrong login name).
Also, I know of no successful break-ins.

My iptables is as follows:

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N block
-A INPUT -j block
-A FORWARD -j block
-A block -i wifi_card -p tcp -m tcp --dport 12123 -j ACCEPT
-A block -i Nic_external -p tcp -m tcp --dport 12123 -j ACCEPT
-A block -i Nic_enternal -j ACCEPT
-A block -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A block -i lo -m conntrack --ctstate NEW -j ACCEPT
-A block -j DROP

First, I think that the above will keep the bad guys out, Is that a true statement?

Sencondly, I have added a LOG rule just above the DROP rule and I have been monitoring it for about 1 1/2 weeks. As each entry is logged I have been adding it to /etc/hosts.deny. Currently there are 4318 ip adresses in the file and the number of packets that have been logged is 51592.

Denyhosts is for stopping ssh attempts and nothing else as I understand it.

Having over 4300 lines in /etc/hosts.deny causes almost no delay in logging in remotely.

Am I being to paranoid about keeping the bad guys out or is the iptable above completely adequate?

I would very much like to here your opinion on this,

+1 vote
what would be the best strategy to intercept traffic from one machine to another

According to your experience what would be the best strategy to intercept traffic from one machine to another and process some (not all) request in a transparent way.

I explain, i have two machines:

192.168.1.1/24  192.168.1.2/24

All I want to do is to intercept traffic from a specific port(s), i.e. 4000/tcp and process it in a 'machine in the middle'.

192.168.1.1/24  machine-in-the-middle  192.168.1.2/24

The idea is that when 192.168.1.1 connects to 192.168.1.2:4000 then the machine in the middle will answer those requests, but the remaining traffic from 192.168.1.1 to 192.168.1.2 keep forwarding as is, and the same for the opposite direction.

...