Some of the addresses you mention are not in the DNS and will therefore not be reachable from the Internet even if they are reachable via AMPR tunnels. - Brian On Fri, Aug 02, 2013 at 10:02:01PM -0000, lz4ny(a)mail.bg wrote:

The issue is that there are gates (misconfigured IMHO) which respond properly when accessed from the internet (via the gateway) and are NOT reachable via tunnel. -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: Saturday, August 03, 2013 01:25 To: AMPRNet working group Subject: Re: [44net] ipip tunnel (Please trim inclusions from previous messages) _______________________________________________ Some of the addresses you mention are not in the DNS and will therefore not be reachable from the Internet even if they are reachable via AMPR tunnels. - Brian

Hi Lynwood, The source address of the packages to be encapsulated has to be your ampr address. Only the IPIP outer envelope is NAT-ed. NAT doesn't care about the data content of the IP frame which in this case is another IP frame. So a correct ipip frame is something like this: [Ip header from external interface/local interface to be nat-ed to gateway proto 4][ip header from local ampr address to remote ampr address proto 1, 6 or 17][tcp/udp/icmp header] ...payload... [checksums] This is what you should see on your external interface (nate-ed or not). Marius. -----Original Message----- From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of lleachii(a)aol.com Sent: Saturday, August 03, 2013 15:54 To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] ipip tunnel (Please trim inclusions from previous messages) _______________________________________________ Marius, My tunl0 IP address is currently 44.60.44.2/24; please test and update us. You noted that you cannot reach http://44.60.44.13/startampr Is that from the public Internet as well? It may help if you could review the script, so we'll be discussing the same configuration. Also, I've confirmed that my tunnel is encapsulating with the correct source (192.168.x.x - which is NATed to my public IP) and destination IP addresses (the destination 44Gateway in my route table). My gateway DOESN'T use the tunl0 IP address unless I enter 'ping -i tunl0' on the console. Thanks to all who troubleshoot, we've been trying to understand why we have issues between some gateways for quite some time. -Lynwood KB3VWG On 08/02/2013 06:37 PM, marius(a)yo2loj.ro wrote: ------------------------------------------------------------------------ No matter the architecture (which I can not see because it doesn't work) there shall either be a tunnel endpoint with a 44 source address or a regular private route. Not a tunnel end point with a private source address. Marius.

Hello Lynwood, Please find below results of my tests. 1. From my gateway IP 44.165.2.2 - I do not see your http://44.60.44.13/startampr script - no response to pings 2. From my Windows 8 PC, via AMPRnet VPN IP 44.139.11.10 (IP belongs to Hessu, OH7LZB IP's range) - same as above 3. From my Windows 8 PC, public IP 87.251.250 110 - I CAN SEE http://44.60.44.13/startampr script !!! - no response to pings Best regards. Tom - sp2lob

Is this update for the Perl or C based software? We may want to consider a different name for each type; since they had the same name, version numbers, etc, it is somewhat confusing. -Lynwood KB3VWG

I'm confused about the nuances as well. And, I must say, the distinctions made below may be clear to some, but not to me. I know Hessu was trying to be brief, but in the brevity, I see no difference. It would be VERY helpful if someone would compare and contrast the options. Why would I use A vs. B vs. C? Are there any advantages of this one vs. that one? ... etc. I'm not looking to start a "mine is better than yours war". But as a non-programmer, non-linux-expert, who hasn't ever written any Perl, and hasn't written any C in 30+ years, I surely have no idea which one to use and why/when. So I (and probably others) could use help in understanding more completely when/why A vs. B vs. C. Thanks much, Michael N6MEF -----Original Message----- From: 44net-bounces+n6mef=mefox.org(a)hamradio.ucsd.edu [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Heikki Hannikainen Sent: Tuesday, August 13, 2013 9:32 AM To: AMPRNet working group Subject: Re: [44net] rip44d update (Please trim inclusions from previous messages) _______________________________________________ On Tue, Aug 13, 2013 at 5:49 PM, <lleachii(a)aol.com> wrote: They have different names, actually: rip44d is my Perl implementation. ampr-ripd is the C implementation, pretty much like rip44d in other respects, both use Linux kernel IPIP tunneling and just manage the routing table. amprd is an encapsulation daemon with RIP, a bit like the old ipip daemon (IPIP encapsulation in user space) but with RIP built in. - Hessu

Hello Lynwood, Put your machine into DMZ zone, just to give it a try... Best regards. Tom - sp2lob

All, Please verify my gateway is reachable over AMPR. It appears the problem was not having an iptables rule allowing IPENCAP. ping and traceroute ping GW- 44.60.44.1 DNS at 44.60.44.3 HTTP at 44.60.44.10, 11, 12 and 13 Public Echolink Proxy 44.60.44.253:443 and 44.60.44.254:80 -Lynwood KB3VWG On 08/03/2013 09:28 PM, lleachii(a)aol.com wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Your gateway replies with a private IP: 3 172.31.255.254 (172.31.255.254) 203.731 ms 233.349 ms 233.076 ms You should initialize your tunnel interface (tunl0, ampr0, etc) with an address from 44/8. You may reuse an IP from your internal LAN, for example if you gateway has 44.60.44.1/24 on the inside, you may assign 44.60.44.1/32 to your tunnel interface. This will solve multiple issues: 1) your gateway will use 44.60.44.1 as source IP for any connections that will be initiated from the gateway host via the tunnel interface. So other AMPR stations will actually be able to reply to your gatway's packets. 2) Should your gateway ever have to reply with some ICMP message, the source IP will correctly identify where the ICMP message was generated. 73 de Marc, LX1DUC On 19/08/2013 22:24, lleachii(a)aol.com wrote:

All, I'm not sure it's safe to suggest that someone having issues with their gateway behind a firewall simply add it to the DMZ, especially in DD-WRT. I have been working with DD-WRT, the following should work under Administration > Commands > (Save Firewall): Command if Static IP: iptables -t nat -I PREROUTING -p ipencap -d <GW Public IP> -j DNAT --to-destination <GW LAN IP> iptables -I FORWARD -p ipencap -d <GW LAN IP> -j ACCEPT If dynamic IP - using the interface (WAN is vlan1 in DD-WRT in OpenWRT it is eth0.1): iptables -t nat -I PREROUTING -p ipencap -i vlan1 -j DNAT --to-destination <GW LAN IP> iptables -I FORWARD -p ipencap -d <GW LAN IP> -j ACCEPT If you have a firewall on your 44 Gateway, be sure to allow IPENCAP into the device: iptables -t filter -I INPUT -p ipencap -d <GW LAN IP> -j ACCEPT 73, Lynwood KB3VWG