On the machine hosting the tunnel endpoint, there must be a proper source nat done so that outgoing packets use ampr addresses as source. Anything else results in icmp responses being routed back through regular internet, returning via another interface, thus getting ignored by the system. Connection tracking implies that responses are received on the same interface on which the request was sent. And no packet other than 44.x.x.x registered in the encap file should go via the tunnel interface (and be sent directly to their end points). 44.0.0.1 should be reachable by ping on every machine, since this is a real internet address on the public internet. The failure to reach it is the result of the existence of a 44.0.0.1 entry in the encap file, which is invalid and which results in trying to reach the ampr gw via tunnel. 44.0.0.1 via 169.228.66.251 actually doesn't work... And also 44.0.0.0/8 doesn't, since forwarding via the gw needs an established link (to permit responses from the regular internet), while 44 destinations have to be reached directly by encapsulation. So 44.0.0.1 and 44 addresses not in the encap file should be routed like any regular public address, and NAT-ed to your own public IP address.. They have to go via public wan ip -> ampr gw (44.0.0.1) -> (ipip tunnel) -> ampr host and back. Not encaped via tunnel. Marius, yo2loj -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of kb9mwr(a)gmail.com Sent: Monday, January 21, 2013 00:48 To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] 44Net Digest, Vol 2, Issue 8 I have noticed there is something with 44 addresses and Windows too. I have never been able to ping a 44 address from Windows, while they work proper from a Linux terminal. All pings to 44 address from Windows result in "Destination host unreachable" (even 44.0.0.1) It's no big deal for me, but have never really figured out why this is.