# [SOLVED] Iptables Drop Connections on Restore

## Anquietas

Hello,

The issue is "Can iptables drop the current connections on restart/reload" ?

I have programmed crontab to reset my firewall every day... if something goes wrong, the original rules are restored back.

That is ok, it's working, no problem there... but,...

I saw that iptables is not dropping the current connections after reset.

For example, I've had someone with a VNC looking on my desktop (for this, there was a PREROUTING rule in my linux router).

Crontab reseted the firewall at 1:00 AM ... and that temporary rule I gave that person to connect to me was gone after the firewall reset... but his connection was not !

It should have dropped that VNC Connection and disconnect the user immediatly after firewall reload, because the rule granting vnc access was not present in the original restored firewall configuration.

After the person closed his vnc, I told him to try to connect, it didn't work.. Iptables reseted that rule.. but it did not act on the fly to resolve the problem. [50% efficiency only]

I don't know if I was explicit  :Smile: ) but, my point is, how can I make iptables to ACTUALLY RESPECT on the fly the rules that it originally restores, and DISCARD there and then any temporary rules set up during the day ?....

Effectively DROP all current connections that do not match the new restored original set of rules...

Another example is: I have a POSTROUTING chain... I effectively stopped the firewall, no firewall was running but my download was still going (because it has been initiated when the rules were still active)... it should have dropped that download the second I stopped the firewallLast edited by Anquietas on Sat Oct 18, 2008 7:27 am; edited 1 time in total

----------

## Dagger

It's hard to tell without actually seeing your rules.

 *Quote:*   

> 
> 
> Effectively DROP all current connections that do not match the new restored original set of rules... 
> 
> 

 

I'm guessing you've got 

```

-m state --state ESTABLISHED,RELATED

```

in the new ruleset, that's why existing connection is not reset.

```

Another example is: I have a POSTROUTING chain... I effectively stopped the firewall, no firewall was running but my download was still going (because it has been initiated when the rules were still active)... it should have dropped that download the second I stopped the firewall

```

What's your default policy?

It would make it easier if you could paste your rules.

----------

## Anquietas

```

infosky ~ # iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination

Chain FORWARD (policy DROP)

target     prot opt source               destination

ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED

ACCEPT     all  --  Gate                 anywhere

POSTROUTING  all  --  anywhere             anywhere

PREROUTING  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

Chain POSTROUTING (1 references)

target     prot opt source               destination

ACCEPT     all  --  Mainframe            anywhere 

ACCEPT     all  --  Terminal             anywhere 

ACCEPT     all  --  Terminal             anywhere

ACCEPT     all  --  Mainbase             anywhere 

ACCEPT     all  --  Mainbase             anywhere 

Chain PREROUTING (1 references)

target     prot opt source               destination

infosky ~ # iptables -L -t nat

Chain PREROUTING (policy ACCEPT)

target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)

target     prot opt source               destination

SNAT       all  --  192.168.0.0/29       anywhere            to:84.232.143.74

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

infosky ~ #

```

yes, it is Related and Established there...

----------

## Hu

As Dagger said, your rule for ESTABLISHED is the cause.  The firewall is doing exactly what it is supposed to do.  There is an established connection up.  Packets for that established connection are flowing, so the connection does not close.  The fact that the rule which permitted the initial handshake is gone is irrelevant, since the established connection is no longer performing the initial handshake.  If you want to break an open connection, kill the process that owns it or add a firewall rule to explicitly deny traffic associated with that connection.

----------

## Anquietas

ok, thank you

----------

