Those scripts were adapted from mails that I sent to the list, but there are some funny things in the versions on the Wiki. The first version (with iptables) has comments that really aren't correct. You must have had other problems while debugging this, as neither "the if iptables ... construct does not work" nor "there must be no spaces or empty lines here" are true. Maybe you had files with CRLF line endings (Windows editor) and/or other issues that were resolved by other changes and this comment was left in there. if command then is the same as: command if [ $? eq 0 ] then there may be empty lines between the command and if, this is no problem, but of course there should be NO thing like "echo $?" between those lines! maybe you did that during testing. that will make it fail because the echo command will not only display the value of $? but also the new value of $? will then be set to the result of the echo command! -> always 0 In the second example, using "ipset", there is an "if ipset" command (see, here it is OK!) but the "then" and the "else" branch contain exactly the same code. I don't know how that came about, but of course in that case you can just remove the if, then and else and put 1 instance of the code left-shifted under that. Of course in this case you don't need the tempfile and can do everything in one go like this: ipset -N ipipfilter hash:ip 2>/dev/null ipset flush ipipfilter ipset -A ipipfilter $AMPRGW grep addprivate encap.txt | sed -e 's/.*encap //' | sort -u | while read ip do ipset -A ipipfilter $ip done In my own systems I use a temporary ipset and swap them after completing the above, to avoid the small time interval where the ipset is being filled and packets could be dropped. For an ordinary user gw it probably isn't worth the trouble as this interval is quite short. Of course, those filters are very useful against abuse of the gateway by people who send ipip packets but are not part of AMPRnet (they could use it to hide their IP or to work their way around parts of the firewall) but in practice I have found that most cases where this actually happens are in fact hams who have misconfigured their gateway. (e.g. the IPIP output goes out on another IP than they have configured as incoming for their gateway) Don't think that adding this will solve any problems you have been faced with unless you are certain that it was via IPIP abuse. There probably is another error in the firewall. Rob