No, it is not ok.
It is working because of connection tracking if YOU access the page.
Here the output ofhttp://yo2tm.ampr.org/nettools.php ping:
Ping Output:
PING 44.153.32.97 (44.153.32.97) 56(84) bytes of data.
--- 44.153.32.97 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 2999ms
Indeed, it is not working correctly. He sent me a mail telling me that he could ping me at 44.137.41.97 and I happened to be at the computer when it came in, I immediatelu tried to ping back and it worked.
Then I waited an hour, tried again, and again it did not work.
So all symptoms point to a stateful firewall of IPIP traffic, probably in his ISP router.
I suspect that some NAT routers do a connection tracking firewall even when the DMZ HOST is set in the config. The DMZ HOST only receives all TCP and UDP traffic, but not protocol-4. However, just like all other hosts on the LAN, it can send out protocol-4 traffic and receive the "reply" traffic. So doing outbound connections works, but inbound on an idle tunnel is not working.
It would be interesting to investigate which routers suffer from this bug, so a list can be made on the WiKi page. I think quite some gateway stations have this fault. The operator believes he has a working gateway because he can connect whatever other gateway station he tries, but incoming connects do not work when there has been no prior traffic.
(of course the same thing happens when DMZ HOST is not set at all, so this has to be properly investigated)
Rob
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.
On 18/10/2016 10:33 PM, lleachii--- via 44Net wrote:
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.
My FritzBox 7270 seems to pass inbound IPENCAP packets fine using the DMZ function. I can certainly get access from outside, and I've never seen any of these intermittent issues.
My TP-Link TL-MR 3420v2 is O.K. in regard to that matter too.
Best regards. Tom - SP2L
-
lleachii＠aol.com -
Rob Janssen -
SP2L -
Tony Langdon