I agree with Rob. For years, my node had similar behavior, causing various kinds of intermittent issues. The problem was solved when I added an iptables rule permitting inbound IPENCAP: iptables -t filter -I INPUT -p 4 -i <INTERFACE OF YOUR WAN> -j ACCEPT # For more security, there are scripts that will dynamically add only AMPR node IPs seen in RIP44 updates. It was discovered when others used my web-based ping and traceroute tools from the Internet to their AMPR nodes, causing a stateful outbound connection (of the IPENCAP packet); that this permitted the return traffic from their nodes. Those who maintain a default route to the Internet via AMPRGW don't usually notice this behavior from non-44 IPs; because, generally, some packets from your Localhost have already attempted to connect outbound (DNS, NTP, e-mail, messaging, Windows Network Map, etc.), thereby establishing the stateful [firewall] connection with AMPRGW. NATed hosts must be connection tracked for outbound (which is why his node can be reached by the remote after he initiates pings). "DMZ" settings usually apply only to TCP and UDP (in most consumer devices, at least). This is also further indication that our common recommendation on this list for operators to place their AMPRGW in the DMZ may not be a risk necessary to take. I should note, I've NEVER been able to use a router with AMPRNet by simply enabling the "DMZ feature" on a consumer device. We may need to compile a list of makes/models where the DMZ feature works with IPENCAP. 73, KB3VWG PS: The above rule is on the firewall wiki page I'm working on; I'll add details regarding why it's necessary to configure on a stateful firewall.