I spent some time with this 44 spoofing issues and reached some conclusions... First of all, spoofing a 44 address while being outside the 44 tunnel system and using one of its addresses is actually not possible. Beacuse even if the 44 destination in a subnet can be reached via whatever means, the replies will either go directly to the proper tunnel, which hosts will ignore them since it did not originate that traffic, or will go through the local gateway and through amprgw, which drops 44 to 44 traffic (which is good). So a no go here. Second, let's say the attacker implements a direct IPIP tunnel spoofing. Since its routes are not in encap/rip, there will be no return route other than the default route or the original proper tunnel. While the default route will usually NAT to the public IP, the original src address is lost and the communication will be probably compromised and the now orphan replies sent to the non-spoofed originator by amprgw. Again no go here. Going up one level, let't assume that the attacker could hijack a 44 subnet by injecting some fake BGP route into the global table. In this case, it will affect only the bgp-announce subnets or undefined network ranges, since the others are protected by the internal routings of the full mesh. So I don't think that spoofing is an efficient attack path in our case, allthough, by tracking the gateway traffic, it seems that there are either a lot of tentatives outside, or that some persons use our 44 address space as private space, and there is some traffic leak in their configuration. Marius, YO2LOJ