David, 1. OpenWrt is Linux; and my previous gateway ran Ubuntu Linux (no *nos) - I cannot speak to other Routing Planes running IPENCAP tunnels. Also note machines running tnos have the machine's kernel and userland software to possibly interact with a packet. I only surmise without firewalls, some of the basic routing concepts apply to other Network Operating Systems too. 2. We're running AMPR gateways, so routing would be ON - I'm lost at the remark about IPv4 Forwarding = OFF. It seems as if you're suggesting to "disable routing on the router". I can only speak for Linux-based devices that are also performing functions as an actual router. Servers (i.e. with net.ipv4.ip_forward=0 and net.ipv6.ip_forward=0) merely receiving all of your IPENCAP packets should not apply here. Even when I originally ran a Linux server as my APMRNet device - downstream of my border router, I still had a /24 (253 other usable IPs) - so I've always had the need to route some IPs. You asked: Are these users trying to break into our AMPR hosts due to gaps in our firewalls or are they exploiting incomplete firewalls to use them as relay hosts to SOURCE attacks out on the Internet? Answer: Both are logically possible with an unfirewalled router or device and/or policy route isolation of the interfaces (in the case of a router). I described a scenario where a malicious actor can use the asymmetry of the routing to get a login screen (e.g. of your router or server) only accessible locally. It also seems as if DDoS is a consequence, or the modus operandi, of some traffic (e.g. TCP reflections cause 100% open connections at the router or a machine). 2b. These would be firewall rules to mitigate. 3. I have provided: tcpdump outputs and netflow records, the tcpdump command to observe the nested IPENCAP and a netflow log of a packet which (had it not been firewalled) could have double routed across my device - let me know what additional filters are needed. Also, the device running the dump must be your registered gateway (to which these actors are directing the traffic in this discussion), not a random device on the Internet. https://linux.die.net/man/8/tcpdump Nested IPENCAP: tcpdump -vvv -n -i tunl0 proto 4 I haven't thought of a tcpdump to observe all Header 1 routing - as the vice versa SRC/DST could be valid in some instances - this command only shows traffic entering or exiting tunl0 without your IP...it will also hit FALSELY on the RIP44 packets, hence the last part: tcpdump -vvv -n -i tunl0 src net not 44.60.44.0/24 and dst net not 44.60.44.0/24 and not host 224.0.0.9 4. I have posted the Second header scenario and it's remains available at the Wiki page. There should be no 3rd header scenario - that's the malicious activity the Second Header firewall rule blocks. http://wiki.ampr.org/wiki/Firewalls (and see previous emails on this topic) - FYI, there's nothing 44net-specific to the rules I suggested - # THIS PREVENTS NESTED IPENCAP (BCP 38) iptables -t raw -I PREROUTING -p 4 -i tunl0 -j DROP HTTP Rule (OpenWrt syntax - iptables-based): config rule                        option target 'ACCEPT'                 option proto 'tcp'         option name 'AMPR_WWW'         option family 'ipv4'                                      option dest_ip '44.60.44.10'         option dest_port '80'         option src '*'                          option dest 'amprnet'         option extra '-m limit --limit 25/minute --limit-burst 100 -j ACCEPT' Block first TCP packet not SYN (again, OpenWrt syntax - iptables-based): config rule                             option proto 'tcp'         option name 'Block_In_Not_SYN'         option src '*'                      option target 'DROP'                option extra '! --syn -m conntrack --ctstate NEW' (Also the normal SYN Flood and INVALID rules). 5. Yes you can have DNS records and not receive traffic from AMPRGW - just block it and/or remove its route. Following the Wiki (for an Linux or OpenWrt setup), the only allowed traffic from anywhere by default are routes from AMPRGW, so long as the machine's default iptables rule is drop or reject. So it's alarming to hear inquiries like this. This will not stop the actual IPENCAPed packets from the Internet via AMPGW for the IPs in the DNS zone. Please keep in mind though, the malicious traffic I observed did not originally come from AMPRGW. I originally observed the nested IPENCAP traffic from a Polish Public IP that's still currently registered as an AMPRNet gateway. 73, - Lynwood KB3VWG