44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 19 Apr '13

19 Apr '13

C.J. thanks for the examples. I think I know the answer to what I am going to ask, but.. Could an IPIP tunnel accomplish the same thing that OpenVPN can for the situation I described (NAT and no modification to a remote firewall)? Why not?

4 3

portal registration issue
by Geoff Armstrong VA7CWD 17 Apr '13

17 Apr '13

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

2 2

private tunnel?
by kb9mwr＠gmail.com 17 Apr '13

17 Apr '13

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.

5 6

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 17 Apr '13

17 Apr '13

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

6 6

Re: [44net] private tunnel?
by kb9mwr＠gmail.com 17 Apr '13

17 Apr '13

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

3 2

RIP44d issue/bug
by Marc, LX1DUC 12 Apr '13

12 Apr '13

-----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-----

3 2

Re: [44net] Gateways Unreachable after Dynamic IP Update
by Marc, LX1DUC 11 Apr '13

11 Apr '13

It seems that you have found the very same issue I have already documented: http://hamradio.ucsd.edu/mailman/private/44net/2013-March/000848.html https://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.

2 3

Re: [44net] Gateways Unreachable after Dynamic IP Update
by lleachii＠aol.com 07 Apr '13

07 Apr '13

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

5 6

Overlapping gateway subnets
by Michael Fox - N6MEF 29 Mar '13

29 Mar '13

I know this is fine in regular IP routing, but is it o.k. with the AMPRgw? I have a gateway that serves a /28 address space. I'd like to do some testing using a couple of the addresses in that space on a different gateway. So, I'd like to add another gateway entry for just those two addresses without modifying the existing gateway entry for the /28. Regular IP longest match should prefer the /32 matches for the new gateway over the longer /28 match for the existing gateway. But before I implement, I wanted to verify whether or not this would be o.k. with the portal database, the amprgw RIP routing mechanism, etc. BTW, this would be a nice, generalized solution for a backup gateway. That is, if the more specific route goes away, the more general route could be used. So, is this o.k. to do or not? If not, why not? Thanks much, Michael N6MEF

4 5

Newbie issue
by Marc, LX1DUC 27 Mar '13

27 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello and sorry to bother you with this. I have added a gateway (46.29.183.253) via the portal and I have added subnets to it. I can see the encap.txt has been updated and I do receive RIPv2 Multicast Messages from 44.0.0.1. I have setup rip44d and it is populating my routing table. Example: #ip route get 44.0.0.1 44.0.0.1 via 169.228.66.251 dev tunl0 src 44.161.229.126 cache window 840 However when trying to ping 44.0.0.1 from 44.161.229.126 I don't get any replies. I have followed the outgoing ICMP packets, they get encapsulated on my gateway and the outer IP destination address is 169.228.66.251. The packet travels without troubles thru AS51405 (the home network of 46.29.183.253) and I can actually see the packet going out to the transit network (currently AS5577, in case you're interested). So I'm really really sure that the IPIP packet containing the ICMP echo request makes it out into the Internet. I have also ran traces on all of the ingress connections towards AS51405 and I cannot see a single coming back from 169.228.66.251. Is there anything I'm missing? I really appreciate your help. BTW I'm allowing inbound packets carrying protocol 4 and ICMP on the gateway, but as I don't see packets addresses towards my gateway in the upstream network, I'm guessing it's not the firewall on my gateway H-i. vy 73 de Marc, LX1DUC - -- 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/ iQIcBAEBAgAGBQJRUrArAAoJEHFIN1T8ZA8vXkUP/38puOAwTWz38Y9UEinjz+HM kBLQKzeYUkVH/f1xjjVuqaiqzXss37XeAL9XeRIqkJ8znanWac8LznYl42Zvyrph BVaRvp6+M3m4CRnNpy7LuRFfTW+DVNIS88TR+jiD+GYxXFiXc7sQSL98ozPPHYSu QUl2pb4qqXXkVOmwjbcUami4HsBj18oCtcwE+qVwv73EBlW/S0ff6HiYawnuJPzK yznMEeStR58K1+9IfX+o6S406JT8VnBJDQ7W6WHU0aHv3qLA+FM7Mk5DBEtHJRE5 5lwkqFwq71XSmQAX2oGWaC1rTk6pBJoSgjGAEssioP7D1hqJAHuc2fR15zDQkxXW L7z39xc/J2z7sZleqlqldjeY9+7pA+w6opJTaZFjdMdf+yq/zuJPpWv36Pm616xy zPnNorLHwe2WJL79+4ZPzDZamp355ATO7LFF38sx8rHJiXGuP+wb1Udi2fSG9J1O 5jYM4XHKWQnVRdTeit2WkUoEW0c+pgN0nsQ4iReXEragXdmhnpXmQhagKZP10/S5 0TMplR1D/3LLVTMRnjhxyUfY9ZtA6dw1S9DyZQadeJh6Y0KD5QoistEOgXqMnoZS a+c5GN/cc/BSxdHrLnc+yk9FxjL+I2fuU6bwuf27fjcXuTSoGglqZMCMM636Rkj1 scOCTXhoQdfwIeA5aV/z =Yi7/ -----END PGP SIGNATURE-----

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net