44net March 2019

44net@mailman.ampr.org

41 participants
33 discussions

what version NNTP to put in
by R P 13 Mar '19

13 Mar '19

Hi there does anyone know what ver of server (1 2 3) i have to put on my cisco SNTP if i want to use the following NNTP server s ? 44.24.244.4 and 44.60.44.1 Thanks Forward Ronen - 4Z4ZQ

1 0

Re: [44net] 44Net Digest, Vol 8, Issue 35
by Roger 12 Mar '19

12 Mar '19

So I would be one of those with weak networking knowledge :( That said, would the proposed change have improved connectivity? I’m finding that not everyone is able to connect to my tunnel setup. I even noticed 3 days last week where N1URO.amor.org, was not reachable from untunnelled devices, like my cellphone and isp. If the changes would improve connectivity, even if people like me would need some instruction and tutoring, maybe it should be considered. Roger VA7VH > On Mar 12, 2019, at 12:00, 44net-request(a)mailman.ampr.org wrote: > > Send 44Net mailing list submissions to > 44net(a)mailman.ampr.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.ampr.org/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)mailman.ampr.org > > You can reach the person managing the list at > 44net-owner(a)mailman.ampr.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > Today's Topics: > > 1. Re: BGP routes in RIP transmissions -- CANCELLED > (Toussaint OTTAVI) > 2. Re: BGP routes in RIP transmissions -- CANCELLED (Brian Kantor) > 3. Re: BGP routes in RIP transmissions -- CANCELLED (Marius Petrescu) > <mime-attachment> > <mime-attachment> > <mime-attachment> > _______________________________________________ > 44Net mailing list > 44Net(a)mailman.ampr.org > https://mailman.ampr.org/mailman/listinfo/44net

1 0

Re: [44net] BGP routes in RIP transmissions -- CANCELLED
by Rob Janssen 12 Mar '19

12 Mar '19

> Of course a special version of ampr-ripd could be made that ignores those routes when some flag is given. Or rather: add a flag that specifies an alternate route table number where those routes will be stored instead of the main table or the table specified with -t A special value (0, -1) could be used to entirely ignore those routes. Rob

1 0

BGP routes in RIP transmissions
by Brian Kantor 12 Mar '19

12 Mar '19

Hello, Beginning on March 15th, the pseudo-RIP transmissions from amprgw will include the various subnet prefixes which are being advertised by BGP. They will show a next-hop address of 169.228.34.84, which is amprgw. Marius assures me that this will cause no harm, and will enable tunnel-only AMPRNet hosts to reach those destinations via the tunnel. He says that many tunnel-connected hosts have a semi-default route to amprgw that has to be manually installed when the system is set up; this would now be automatic when employing the various ampr-rip programs. Quoting Marius: So, wouldn't it make sense to publish BGP routed networks that do not have 'tunnel ' set in the portal as RIP routes using amprgw as gateway? This would solve some issues: - Users could actually see all reachable destinations in their route list - Users could easily identify BGP networks by checking 169.228.34.84 as their gateway - they could drop the setting of that 'default' route in the ampr routing table, allowing a (implicit) throw to the main table. This will make it easier to reach local or directly connected ampr networks (which now need routes placed in the ampr table). Also, unknown destinations would be NATed to the system's gateway, without putting any additional traffic to amprgw. - it would also allow to have all routes in a single routing table while being able to reach tunneled and BGPd networks using their AMPR address without policy routing. Existing set-ups would not affected by such a change in any way. Marius, YO2LOJ Please be sure to let me know if there are any problems with this change; it can be reverted in a matter of moments if an unexpected difficulty does arise. - Brian

3 5

Connected via VPN, now what?
by Mike Saeger 07 Mar '19

07 Mar '19

I connected via VPN. IPv4 Address. . . . . . . . . . . : 44.139.11.22 Subnet Mask . . . . . . . . . . . : 255.255.255.252 My DHCP server is 44.139.11.21. I am not able to ping that server. I can't ping ampr.org. Actually, I tried pinging several IP addresses and nothing is returned. I'm trying to figure out if connecting via VPN is of any useful value? Mike N9MS

4 3

Re: [44net] Port-forwarding of 44-addresses
by Rob Janssen 06 Mar '19

06 Mar '19

Marius, Ok that is an interesting solution! It solves the "route lookup" issue, but in the case of using BGP there isalso the issue that BGP only distributes the subnet route when there is an actual matching route in the table that it is managing. Of course this can by circumvented by unchecking the "synchronize" option. And on our local AMPRnet we distribute the default route via the same BGPinstance as the remainder of the routes. So that would have to be changed. I'm inclined more towards a script that reads the interface routes from the main table and copies them into the amprnet table... Rob

1 0

EdgeRouter and EdgeRouterX
by Marius Petrescu 06 Mar '19

06 Mar '19

I updated the startup scripts for the EdgeRouters to properly route back replies of requests from the internet via tunnel. So if you like to use the new setup, download again and reinstall the package... Also, with the new setup, the status wizard also needs to be updated (remove and install). Find the EdgeRouter setup package here: http://www.yo2loj.ro/hamprojects/Ampr_EdgeRouter.tgz (mips64) For the EdgeRouterX setup use this one: http://www.yo2loj.ro/hamprojects/Ampr_EdgeRouterX.tgz (mipsel) Status Wizard: http://www.yo2loj.ro/hamprojects/Ampr_Status_Wizard.tar Marius, YO2LOJ

1 0

Re: [44net] Port-forwarding of 44-addresses
by Rob Janssen 06 Mar '19

06 Mar '19

> The forwarded packets > that were supposed to go to my 'inner' server were also routed back to > the AMPR GW, which of course did not know anything about my local > addresses (192.168...). > However, after adding this line: > ip route add 192.168.19.0/24 dev enp0s6 table 44 > everything felt in place and I'm now a happy man. Unfortunately this is a detail that is soooooo easy to oversee that it frequently happens. But of course it is always educational to encounter this and fix it yourself! E.g. I recently helped someone with a MikroTik router to setup this kind of policy routing and on that router the direct routes to attached interfaces also only appear in the main routing table and not in those additional ones. There really should be an option to do that automatically, but until then indeed you have to add them manually. The kernel would lookup the route in the main table when it cannot find a route in the additional table, but of course that only works when there is no default route there. And autorouting protocols like BGP won't distribute the route when it is in the wrong table. Rob

2 2

Fixed the problem
by Mike Saeger 05 Mar '19

05 Mar '19

There were 2 RSA keys in my n9ms keys file. The 2nd one was the correct one. Then I got an error message telling me that OpenVPN couldn't connect due to a weak algorithm. Adding the following line to the .opvn file fixed it. Mike tls-cipher "DEFAULT:@SECLEVEL=0"

1 0

Trying to use VPN
by Mike Saeger 05 Mar '19

05 Mar '19

I'm already using OpenVPN and it works great. Now, I'm trying to use OpenVPN to establish a tunnel to AMPR.ORG. I followed the instructions at: http://wiki.ampr.org/wiki/AMPRNet_VPN I get the following message in my OpenVpn Log: Tue Mar 05 12:19:13 2019 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead. Tue Mar 05 12:19:13 2019 SIGUSR1[soft,private-key-password-failure] received, process restarting Tue Mar 05 12:19:13 2019 MANAGEMENT: >STATE:1551813553,RECONNECTING,private-key-password-failure,,,,, Tue Mar 05 12:19:13 2019 Restart pause, 5 second(s) --- and it repeats ---

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net March 2019