Hello,
I have tried on a number of occasions to register on the Portal. I
have not received a confirmation email once.
Anyone else having this issue?
Thanks,
Geoff
VA7CWD / VE7KA
I am running a gateway using rip, etc. I really only have wifi radio range
to a couple other hosts. And that is working well.
We have a couple other small wireless networks in town that I can't reach
by radio. They could be connected to the internet but unfortunately would
be behind firewalls that we cannot control.
So till we get things realigned and such, I am looking for examples on how
to create a private tunnel from my gateway to those locations.
It doesn't really make sense to put another gateway in the portal, as I
doubt the rip packets will pass though.
Yes the separate clusters each have separate NAT/firewalls protecting them.
Again, I am not going to be able to convince the people donating that
bandwidth to set our internal ip on their network as a DMZ host.
I plan to write about it, if I ever figure out how to punch a two way
tunnel from me (a place where I have control over such things) to these
places.
What I envision is from the rest of the amprnet, 44.92.21.0/24 comes here
via an IPIP tunnel; and various smaller chunks /29 or /28 go back out from
here via some other capable tunnel to these remote sites till we convince
folks we need to get something up on a decent tower.
It doesn't need to be encrypted or authenticated, whatever is easiest and
will do the job.
--Quote--
I'm unclear on the topology of your network; I'm going to assume that
the separate clusters each have a separate NAT/firewall protecting them.
In that case, I believe you may get the IPIP traffic to pass through the
NAT/firewall to the internal host by designating the internal host as a
DMZ host. You would then register the NAT/firewall's public IP address
as the gateway host.
I'd wager it depends on the software in the NAT/firewall so some may do it
and others may not. I heard that OpenWRT does handle IPIP encapsulation.
I've not tried that myself so others who have done so should comment on
whether this approach actually works.
I'd much appreciate you writing up what you wind up doing and publish
it on the wiki so others may share your experience.
- Brian
First off I don't claim to know much about VPNs and encapsulation.
Everyone I talk to tells me openvpn should do what I want.
I take it that is a state full type of connection?
Brian, the problem I see if if I setup another rip44 listener gateway, how do I
direct the encapped traffic to our natted, internal IP? An entry in the portal
will get it to their router (outside address), but having them place a
forwarding rule to get it from there to out 192 internet address probably won't
happen.
---- Quote------
On Wed, Apr 17, 2013 at 12:38:01AM -0500, kb9mwr at gmail.com
<http://hamradio.ucsd.edu/mailman/listinfo/44net> wrote:
>* It doesn't really make sense to put another gateway in the portal, as I*>* doubt the rip packets will pass though.*
The AMPRNet internal RIP packets from 'amprgw' are sent encapsulated,
so if you can do IP-IP tunnels at all, the RIP should get through too.
One way to see whether a firewall will pass IP-IP tunnels is to add
its address as a gateway and see if you get tunnel traffic on the other
side. Since the internal RIP is sent every 5 minutes, it can be a simple
test of your incoming connectivity.
- Brian
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Good morning,
I saw some odd routing during my tests. So I analyzed the routes added
by RIP44d. I modified the code to log the command string to add
routes, my suspicions where confirmed: rip44d v1.2 adds every route
with a prefix length of /32:
(examples)
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.161.0.0/32 via 141.75.245.225 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.129.0.0/32 via 118.22.1.194 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.147.0.0/32 via 121.99.232.227 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.183.0.0/32 via 130.208.168.63 dev tunl0 window 840 onlink table 44
Mar 29 00:45:03 debian rip44d[19323]: LANG=C /sbin/ip route add
44.94.0.0/32 via 141.224.128.8 dev tunl0 window 840 onlink table 44
All these routes should be /16
I'm trying to figure where the issue comes from, but I'm not a perl
addict, so any help is welcome. I have already confirmed that the RIP
message contains the correct netmask:
IP Address: 44.161.0.0, Metric: 1
Address Family: IP (2)
Route Tag: 4
IP Address: 44.161.0.0 (44.161.0.0)
Netmask: 255.255.0.0 (255.255.0.0)
Next Hop: 141.75.245.225 (141.75.245.225)
Metric: 1
73 de Marc
- --
http://lx1duc.mcs.tel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRVNjWAAoJEHFIN1T8ZA8vteEP/2oD1ic40dvnuZSOOdvS+NNw
BZEaIlI9gmIZ6P2FqJO4ZOs/kXLdKnxDa9hNgAV5+4bZAZyiGQIHFd1+rwIAaZKN
quzJ1h7SzYKOJYDRiMIQO8nYdDzNMYKb4H5GhSpCiDWGHnt+OJA+uV8ZXHClj7QV
y2AvJDKgrcRaf3Lr4kwghVnIHlmqibxPI2fFv8DuG8sBvIkxjtUJ21MOUq6nJD8z
HaCpJRS8169Syl3jq/8DogEvKfjkehaNmczyxWfWcN1t93Lxh+pPGu88iDhh1pNS
3CpVw7nY1aV88fQUURMNRJqB5IEDLyL9z/A6oU8t4u095SS6wj3wbzs7HpY37Oc4
UsLbqLlH88wkc1AnW5PrrzNLNyjEX4/3y1zywhwJFaVWUGRTAVKC3fB8Q4hhg0/M
r6q5LfjbFJzvZYppvsoqDMCAYHsAcg5lTP92+I1/86avntSW1Kj8bIJnrr/wGfZz
zbURMk+9U2WJlX6mnmm/Z0a/Lo+l3/T74CzXDDmr8dvEaMB9r7AeTx3M7h6H/jBi
yNrFZtwCg/ZMDcCR8jtAN8dqNOYht5uL/+N9dPZy50cyMhLjxVItl6BXrUYdXGqD
2p8zXKjwc8iPLuirvXs3cFK4dioDyJviMDTPSXss01zMBpLqj80UVltIV+xmMRf9
x6fcW9WXhFYoLN56hrti
=0CVp
-----END PGP SIGNATURE-----
It seems that you have found the very same issue I have already documented:
http://hamradio.ucsd.edu/mailman/private/44net/2013-March/000848.htmlhttps://github.com/hessu/rip44d/issues/7
Unfortunately I haven't heard back from the author or someone else and
I'm not a perl developer, so I cannot fix it myself.
Best regards,
Marc
Quoting lleachii(a)aol.com:
The populated route reads:
44.182.21.0 via 89.122.215.236 dev tunl0 onlink window 840
44.182.21.0 is a valid IP address on the ICANN Internet and does not
imply a subnet in any form.
It should contain a /24 notation as in the AMPRPortal:
44.182.21.0/24 via 89.122.215.236 dev tunl0 onlink window 840
No AMPR networks on my routing table (populated by RIP44d) contain the
proper CIDR notations.
Dear Bob VE3TOK (and thanks to VE3ZDA and N2NOV),
Your entry is on my route table, I'm using rip44d (not encap), so my
updates are live. The IP of my gateway is correct in the Portal. I use
the -a switch to remove my own route (and have updated it to the correct
IP); and I still receive rip44d updates over AMPR (showing that I have
not lost connectivity to the Main AMPRGW).
From testing connectivity to your subnet, I have determined that my
44GW is operational; and that some gateways may not have yet updated
their encap.
Thanks for your help; I waited a few days to to be sure that was not the
case; as I know all stations do not have dynamic routing updates, I'll
wait longer next time.
73,
Lynwood
KB3VWG
http://44.60.44.10/tools
@kb3vwg-015:~$ ping 44.135.85.1 -c 10
PING 44.135.85.1 (44.135.85.1) 56(84) bytes of data.
From 44.135.85.30: icmp_seq=7 Source Quench
From 44.135.85.30: icmp_seq=8 Source Quench
From 44.135.85.30: icmp_seq=9 Source Quench
From 44.135.85.30: icmp_seq=10 Source Quench
--- 44.135.85.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9003ms
@kb3vwg-015:~$ traceroute 44.135.85.30
traceroute to 44.135.85.30 (44.135.85.30), 30 hops max, 60 byte packets
1 kb3vwg-001.ampr.org (44.60.44.1) 0.724 ms 0.238 ms 0.218 ms
2 linux.ve3mch.ampr.org (44.135.85.151) 51.890 ms 55.835 ms 60.720 ms
3 port.ve3mch.ampr.org (44.135.85.30) 63.642 ms 62.613 ms 66.477 ms
@kb3vwg-015:~$ ping 44.135.85.30 -c 5
PING 44.135.85.30 (44.135.85.30) 56(84) bytes of data.
64 bytes from 44.135.85.30: icmp_req=1 ttl=39 time=53.9 ms
64 bytes from 44.135.85.30: icmp_req=2 ttl=39 time=51.8 ms
64 bytes from 44.135.85.30: icmp_req=3 ttl=39 time=87.4 ms
64 bytes from 44.135.85.30: icmp_req=4 ttl=39 time=52.7 ms
64 bytes from 44.135.85.30: icmp_req=5 ttl=39 time=51.9 ms
--- 44.135.85.30 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 51.899/59.607/87.406/13.919 ms
