# Where are Iptables Rules Restored from and how to Reset Rule

## RAPHEAD

I cloned a server which was running shorewall previously.

I shut it down permanently but could not make connections to the system.

Then I figured out that there were these rules even after stopping shorewall:

```
    $ iptables --list-rules

    -P INPUT DROP

    -P FORWARD DROP

    -P OUTPUT DROP

    ...some more...

```

They persist even after reboots!

So I checked `/etc/init.d/iptables` but it's disabled.

And `/var/lib/iptables/` is empty.

So my question is, where are those rules stored and

what is restoring them after reboots?

I finally could successfully reset them with `iptables --flush` and then `iptables-save`

but I don't know why this worked.

----------

## charles17

Did you check the directories listed by equery?

```
$ equery f iptables | grep /var
```

Also, https://wiki.gentoo.org/wiki/Iptables#General_Rules might help.

----------

## RAPHEAD

cool way of checking the potential locations   :Smile: 

Yes, I checked and they are empty (except for `.keep_net-firewall_iptables-0`).

----------

## i92guboj

 *RAPHEAD wrote:*   

> cool way of checking the potential locations  
> 
> Yes, I checked and they are empty (except for `.keep_net-firewall_iptables-0`).

 

Then see what else lives in the directory where that file is  :Wink: 

----------

## RAPHEAD

Again, it is empty! Neither in the ipv4 nor in the ipv6 dir there is somehting.

----------

## i92guboj

Sorry. I don't know how I read that  :Laughing: 

iptables usually saves the files into /var/lib/iptables/, but there are many ways to run iptables.

It could be a bash script in /etc/local.d/, or some init script in /etc/init.d. Maybe even a cron script.

If it's under /var/lib/iptables, then they should stop to load if you rc-update del iptables, but, as said, there are many ways to run them.

----------

## charles17

 *RAPHEAD wrote:*   

> They persist even after reboots!
> 
> So I checked `/etc/init.d/iptables` but it's disabled.

 "disbabled" - Does that mean you are not having iptables/ip6tables in a runlevel?

----------

## RAPHEAD

yes, `rc-update | grep iptables` returns no result.

----------

## jonathan183

 *RAPHEAD wrote:*   

> So my question is, where are those rules stored and
> 
> what is restoring them after reboots?

 

On my system there is /etc/conf.d/iptables which has an entry

```
IPTABLES_SAVE="/var/lib/iptables/rules-save"
```

I actually have never use the save feature and run iptables from a script /etc/local.d/001-firewall.start

----------

## RAPHEAD

@i92guboj

Good hint with /etc/local.d/ I actually had a forgotten script there once ut not in this case  :Sad: 

@jonathan183

On the system in question, I have an /etc/conf.d/iptables like:

```

# Location in which iptables initscript will save set rules on 

# service shutdown

IPTABLES_SAVE="/var/lib/iptables/rules-save"

# Options to pass to iptables-save and iptables-restore 

SAVE_RESTORE_OPTIONS="-c"

# Save state on stopping iptables

SAVE_ON_STOP="yes"

...commented stuff

```

But my understanding is that this would only be used, if /etc/init.d/iptables would run. And again `/var/lib/iptables/rules-save` is empty.

----------

## pietinger

IF

- the skript iptables isnt in your runlevel

AND

- you have firewall rules activated

THEN something other must activate it.

I would temp. rename /sbin/iptables and look if a skript throws an error ....

----------

## cboldt

iptables-save, on its own, just writes to stdout, so unless you are redirecting the output to some persistent place, all you've done is get a view of the firewall as currently constituted.

When the firewall is completely flushed, it will have three policies (which is what you showed), one for each of three empty chains.

You can see this by running `iptables -F; iptables -X; iptables-save | less`.  You will be looking at an empty firewall.

If it gets populated (you can check anytime with `iptables-save | less`), then something is running iptables commands, either a string of separate `iptables` commands, or `iptables-restore`.  If I was running into the firewall being built, I'd look for the typical firewall builders (I don't know the names of all of them, but ipkunfu is one); and if none of those are present, then I'd run grep against /etc

grep -r iptables-restore /etc

grep -r iptables /etc

I'd run against iptables-restore first, because a match on that might get lost in a sea of matches on iptables

----------

## RAPHEAD

Hi cboldt,

many thanks for your insights.

The tables were definitely not empty *just three entries)

but at some points they were and I can still not say 

what solved it in the end -- see described procedure.

I know that the only firewall related script I had installed

was shorewall which I deactivated.

Maybe it was some forgotten own script that I cleaned up

on the go.

----------

## cboldt

One other point, that I forgot to mention - the policies are persistent, meaning that if you flush the firewall and remove all the rules, the policies, whatever they are, remain.  If the INPUT policy is DROP, you are locked out.

If shorewall built a firewall, and set the policies to DROP, and you remove shorewall, the policies are "stuck" on DROP until somehow changed, even if you flush the firewall and remove all the other rule chains.  An iptables command can change the policy (iptables -P INPUT ACCEPT), and the default on rebooting is to have the three primary chains (INPUT, FORWARD, and OUTPUT) on a policy of ACCEPT.  I would guess that even this default can be modified by informing the kernel.

Glad to hear your situation was resolved.  If you are a bit like me, the issue bugs me persistently until I figure out what the heck was going on!  Sometimes the light comes on many months after the issue.

----------

