44net March 2020

44net@mailman.ampr.org

21 participants
29 discussions

GL.iNet openWRT Rip44 support?
by Tracy Markham 30 Dec '20

30 Dec '20

I had reached out to the good people at GL.iNet and asked for help getting one of their openWRT routers to run my 44 net assignment. I referred them to the page explaining openWRT setup ( wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenWRT) and requested they compile an executable for the processor in the router. Apparently they did it. It will be a bit before I can try to configure it but its a one click installation. It's available to anyone with a GL.iNet router product, just navigate to Applications -> Plugins and Update, then navigate to the R section. I have a screencap of all the dependencies it installed if anyone is interested. I reached out to them because I've failed on my previous attempts to set up an EdgerouterX for my assignment... I am by no means a network engineer, this is my foray into getting a gateway going. If anyone could confirm this works that would be great. If you're willing to help me get mine going that would be even better. Tracy N4LGH

7 10

Returning YV.
by Gabriel Medinas 01 Apr '20

01 Apr '20

Greetings to all, just to inform you that returning to teamwork at AmprNet, Venezuela is connected again, renewing some things in my local structure with the JNOS Linux program through yv5kxe.ampr.org (44.152.0.60). We are especially grateful to Chris - G1FEF who personally granted the possibility of this YV return on this network after 20 years. We are in settings, I am mainly working to adjust my old JNOS to the new dynamic of AmprNet especially to the RIP44d update that does not work in JNOS doing it manually, I am working on a project to use other compatible hardware to achieve other gateways for use APRS and the DXCluster yv5kxe. 73 de Gabriel YV5KXE yv5kxe.ampr.org

4 3

Ubiquiti AMPR-ripd
by Elias Basse 31 Mar '20

31 Mar '20

Is anyone familiar with ripd on the ubiquiti series of routers? I have a test device edgerouter pro that I am attempting to get working however I am unable to route through the ipip tunnel that has been built per both wiki articles. Any pointers would be appreciated. Many thanks, Elias Sent from my iPhone

1 0

BGP annuncement of same address Block from 2 sites ?
by R P 31 Mar '20

31 Mar '20

Hi there Is it possible to announce same Address Block from two different sites ? with preferred way for one site ? The idea is to have redundancy in case that one site connectivity fail the traffic will pass to the other site automatically Both site will be connected by radio as well so Network connectivity will not stop I know that BGP support it is it also the way in the AMPRNET BGP announcement ? Has anyone done it ? or doing it in the AMPRNET community ? Thanks Forward Ronen - 4Z4ZQ

3 2

BGP Announcment Procedure
by R P 31 Mar '20

31 Mar '20

Hi there Who deal today with BGP announcement procedure ? We want to start announce part of our 44 net BGP i started the procedure with Brian who take care of it now ? Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org

2 1

Re: [44net] Large increase in inbound suspicious traffic from public internet to systems on 44 net?
by Rob Janssen 31 Mar '20

31 Mar '20

> On Thu, 2020-03-12 at 11:30 -0500, Shawn M Garringer via 44Net wrote: > > I am wondering if anyone else is seeing the following: starting on 5 > > March 2020 and continuing through the present I have detected a large > > spike in inbound traffic to several of my AMPR 44 IP addresses (on > > 44.50.1.0/24). The spike has been large enough that my logging ELK > > stack is struggling to keep up. > A good number of folks have seen a spike in scans by botnets spoofing > IPs but not just on 44-net. Commercial ISPs have seen similar spikes of > traffic and have taken proactive measures to try and halt these brute > force attacks. I see no visible increase in the traffic graphs for our internet gateway, but of course I do confirm that there is a continuous stream of port scanning going on, partly from individuals and partly from jerks like censys.io, shodan.io, stretchoid.com, binaryedge.ninja etc etc who are continuously scanning the internet for vulnerabilities and keep searchable databases where their users can instantly locate who is running e.g. a MikroTik router when there is a new known vulnerability (of course only when it its firewall is not properly configured). All this together is responsible for 1-2 Mbit/s of traffic on our /16. So yet, it is quite noticable. Of course we do not log all that, but we do have some auto-block features that trigger when people scan for wellknown ports (like mentioned above) within unassigned address space. Rob

2 1

Large increase in inbound suspicious traffic from public internet to systems on 44 net?
by ampr＠shawngarringer.org 30 Mar '20

30 Mar '20

Hello group, I am wondering if anyone else is seeing the following: starting on 5 March 2020 and continuing through the present I have detected a large spike in inbound traffic to several of my AMPR 44 IP addresses (on 44.50.1.0/24). The spike has been large enough that my logging ELK stack is struggling to keep up. This traffic is coming from the public internet. Most of these are looking at standard ports 443, 80, 25, and 22. These are being directed to IP addresses in my subnet that are not in use, and therefore are being dropped (but logged) at the firewall. Nothing is running on these IPs so there is no way the traffic is in response to anything I can find coming from my network. I realize devices periodically scan the "entire internet" but this is more than that... in one day I saw 100,000 TCP SYN from a single public IP address. That is a significant spike and I am not certain why they sent so much traffic from a single IP to a single IP. Wondering if anyone else is seeing the same? 73 DE KC0AKY

7 9

Re: [44net] Security - Nested IPIP
by Rob Janssen 27 Mar '20

27 Mar '20

> So all traffic received on IPIP tunnels should be from net44 only in our case. Unfortunately not all of it is. > Can you elaborate on the traffic that isn't, please? > Is this traffic from another operator...or a non-operator? > Can you also elaborate if this traffic forwards in any cases? As I explained before, what I sometimes DO see is IPIP traffic from gateway A.B.C.D with an internal packet with source A.B.C.D and destination 44.137.X.Y (inside our network). That traffic should have been sent with source address 44.P.Q.R in the internal packet, where 44.P.Q.R is the net44 address of that specific gateway at A.B.C.D. As I got repeated logs in the firewall of these occurrences (one was from a Polish gateway, I remember) I added a firewall rule to allow such traffic. The reply will of course be routed directly over internet, not via the tunnel, so it is questionable if the connection would get established. Probably not, when the user has the typical stateful firewall on his internet connection. Yesterday I have removed the extra rule and I am watching the firewall log, but I have not yet observed another instance of this error after about 12 hours. So maybe some people have woken up and fixed their config already. Rob

1 0

Re: [44net] Security - Nested IPIP
by lleachii＠aol.com 26 Mar '20

26 Mar '20

Rob, You stated: So all traffic received on IPIP tunnels should be from net44 only in our case. Unfortunately not all of it is. Can you elaborate on the traffic that isn't, please? Is this traffic from another operator...or a non-operator? Can you also elaborate if this traffic forwards in any cases? That's what we're tying to stop. Please note, I haven't identified this is related to any IPENCAP issue specifically (except that it appears we may have some operators that forward traffic not destined for them). While I understand your concern, I'm not sure it's related to IPENCAP 100%. 73, - Lynwood KB3VWG

2 3

Re: [44net] Security - Nested IPIP
by Rob Janssen 26 Mar '20

26 Mar '20

> I'm now wondering how such a config is [incorrectly] made (i.e. the inside Header has the incorrect SRC)....likely because of no route policy...another discussion... Easy: when you take a default Linux system and add something like IPIP mesh with routes in the same table, and then you run services on the same system, an outgoing connect to a system within net44 will just consult the routing table, find an outgoing route and make a connection. You then have to rely on the "source address selection" done by the system, which may select your public IP as the source address. This may also be configured in the service itself (when the socket is not bound to 0.0.0.0 but to some specified address). The outgoing connect will now be routed through the IPIP tunnel, but it will have the public address as the source. To prevent this, the service would have to be bound to the net44 address, or it would have to be set as a default source address in the tunnel routes in the table. When you run a separate system as the IPIP router and an AMPRnet services host, you do not run into this problem because the services host has the proper external address within net44 and the router will not change it. But with both combined in a single host, you can still get it working correctly when you pay some attention. Which of course has to be done when you want a single system that can both be a general-purpose internet browsing system (directly via your ISP connection) and can be an AMPRnet services host at the same time (also for services available from public internet addresses). The routing has to be carefully set up when doing this, and setting a preferred source address is only part of that. In our network the problem you mention w.r.t. AMPRGW does not occur because internet traffic is routed directly to our gateway, not via an IPIP tunnel. The IPIP tunnel via AMPRGW only gets public internet traffic when our BGP announcement is down for some reason, that is why I kept it operational but it normally has zero traffic. So all traffic received on IPIP tunnels should be from net44 only in our case. Unfortunately not all of it is. When I "just drop" the bad traffic it appears in a log and it appears the originators of the traffic do not notice it, so it goes on and on. As I mentioned, I sent mail to gateway owners about it, but it rarely fixes the situation. Rob

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net March 2020