firewall-start: Something Else Is Inserting a Firewall Rule?

[Kevin K]

I inserted a firewall rule via /jffs/script/firewall-start to drop traffic from 10.8.0.0. However, something else inserted an accept-everything rule afterward, so my traffic doesn't get dropped. I'm guessing that something related to OpenVPN did it.

When I insert my drop rule manually, after the router is fully started, it is the first rule in the chain.

How can I ensure that *my* firewall-start rules get applied after other sources?

My firewall-start:

#!/bin/sh
iptables --insert FORWARD -s 10.8.0.0/16 -d 192.168.8.0/24 -j DROP

My FORWARD chain:

Chain FORWARD (policy DROP)
target     prot opt source               destination       
ACCEPT     all  --  anywhere             anywhere         
DROP       all  --  10.8.0.0/16          192.168.8.0/24   
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
DROP       all  --  anywhere             anywhere         
DROP       all  --  anywhere             anywhere             state INVALID
ACCEPT     all  --  anywhere             anywhere         
NSFW       all  --  anywhere             anywhere         
ACCEPT     all  --  anywhere             anywhere             ctstate DNAT
ACCEPT     all  --  anywhere             anywhere

I could put a "sleep 60" in my firewall-start, but that is icky.

UPDATE: It *is* the VPN which is adding the accept-all. I can't just put my VPN-related firewall rules in firewall-start. And I can't just put them in the VPN event script, because if I start/stop the VPN a few times, I'll wind up with duplicate rules. I need to prevent the OpenVPN component from updating the firewall scripts.

Maybe the sensible thing to do is to put "service restart_firewall" at the end of my VPN postconf?

 

[Adamm]

I could put a "sleep 60" in my firewall-start, but that is icky.

That's about the only solution, the firewall-start event is pretty weird, it gets called up to x3 times per boot and you can easily run into race conditions as the rules are flushed during this process if you run a lockfile system like I do. In Skynet I handle this by sleeping for 20s before modifying the FILTER table.