I did not mention in the mail that I had to resolve those catch-22 effects as well... In my system, I initialize the firewall using a shell script that has a long list of iptables commands in it. I prefer that over manipulating it ad-hoc and then saving it using iptables-save, because I can put comments in the script, use variables to hold values like the external and internal IP addresses, etc. Inside this script, after the commands to erase any existing rules, I first call the update script I posted that populates the ipipfilter so I can add that in the rule for incoming -p 4 traffic without getting a nonexisting chain error. (it is not possible to forward-reference chains in iptables) For other purposes I now use "ipset" to hold such lists of addresses instead of a long list of rules that matches them one by one. Is more efficient as well, but in my Linux version it is not possible to keep hit counters for ipset members, which I would like to do (to occasionally check which gateways actually send traffic to us). Using an ipset could resolve the issues that you have been facing, as one can create the empty ipset before setting up the iptables, put the public address of amprgw in it (hardwired), then start ampr-ripd and let it receive the tunnel information and put it in the ipset. You never have unresolved values while doing that. You can use ipset like this: ipset create gateways hash:ip ipset add gateways 169.228.66.251 and then in the firewall: iptables -A INPUT -p 4 -m set --match-set gateways src -j ACCEPT The script called from ampr-ripd would then use "ipset add", "ipset del" and "ipset list" commands to manipulate the set similar to what I did with iptables. Rob