The main problem with spoofing of course is not that it "attacks" our systems, but that our systems are being hit by backscatter from others that are being attacked, or that we attack others when we are used as reflectors. So be careful to have the right filters so you don't send too much traffic "back" to senders with spoofed addresses. It is correct that you need to allow protocol 4 only on the external network card and NOT on the tunl0 interface. If you do, you allow tunnel-within-tunnel packets, and they could be malicious, but in any case they are incorrect. In the past we have sometimes seen encap loops where some incorrectly configured system kept putting packets into another encap layer and forward them, and this kind of looping can easily be stopped by not allowing protocol 4 over protocol 4. There is an additonal filter that you can make, and which I explained earlier on the list. With Marius' ampr-ripd you can call an external script when the encap route table is changed, and in this script you can maintain an address list of valid IPIP peers, and use that in the firewall to accept IPIP packets only from peers that are announced by the RIP daemon. This will guard you against funny IPIP packets sent by random hackers. Of course it is not sufficient against the determined people, because they can spoof the IPIP packet to come from one of the gateways in the list, and it will be accepted anyway. Blocking "non-44 source addresses on tunnel interface" of course is only possible when you do not want to communicate between net-44 and the rest of internet. However, you can always use the regular firewalling techniques like blocking all incoming traffic with a source address that is local to your network (and of course all RFC1918 traffic like 192.168.0.0/16), and use connection tracking (-m state --state ESTABLISHED, RELATED) to block most incoming traffic that is not a reply to outgoing connections, and then carefully allow what you like to come in. This has to be done separately for the external interface and the tunnel interface, as the things you want to allow on those two interfaces are completely different. Lots of firewall howto's only show you how to put lots of rules in the INPUT or FORWARD table, which quickly make things inefficient and difficult to maintain. It is usually better to setup a number of tables with iptables -N tablename, each with the rules for a specific interface or even for a protocol, and put rules in the INPUT and FORWARD tables that match on some input/output interface and branch to the table for that case. iptables -N eth0ipip .... iptables -N eth0input iptables -A eth0input -p 4 -j eth0ipip ... iptables -N tunl0input iptables -A INPUT -i eth0 -j eth0input iptables -A INPUT -i tunl0 -j tunl0input ... Rob