Regarding the other thread about which firewall rules to use, the gateway is a little more complicated but for my home router I (normally, not last night in case you saw differently) have the equivalent to:

iptables -t filter -A FORWARD -i tunl0 ! -d 44.131.14.128/26 -j REJECT iptables -t filter -A FORWARD -o tunl0 ! -s 44.131.14.128/26 -j REJECT

I think this pretty much covers the requirements for a basic end network?

For the outgoing side, yes. It would be very helpful when everyone had a filter like that. For the incoming side it is a bit too simple. It covers the case where hackers send packets that you would then forward, but that can also be covered with a

iptables -A FORWARD -i tunl0 -o tunl0 -j DROP

However, it would still be advisable to:

- only accept tunnel traffic from registered gateways (I have shown on the list how to do that a couple of times) - attempt to screen the source address of the tunneled traffic a little (e.g. accept non-44 traffic only from the gateway, as shown earlier today, and even better: to reverse path checking for tunnel traffic, i.e. only accept traffic from each tunnel whose source address matches the subnets registered for that tunnel)

If the main gateway receives an invalid encapsulated packet from a known gateway or a 44net address, would it be helpful to return an error instead of dropping it? An ICMP Administratively Denied packet is more likely to generate an obvious error message than packets going missing. The gateway would probably need to rate-limit the number of errors it will send out to prevent abuse, though.

This does not bring much, it would only help when someone is actually watching the traffic, and it appears not many people do. When a decapsulating gateway sends an ICMP unreachable packet to the encapsulating gateway, that gateway will not normally attempt to translate it into an ICMP packet related to the inner packet and send that back to the originating system. So the user behind the keyboard will never know.

Rob