- 44net - mailman.ardc.net

netflow vs privacy
by Brian Kantor 23 May '17

23 May '17

I was in the process of selecting a netflow viewer -- most of them are web-based -- when it occured to me that someone using it could discover every connection that someone has made through the amprgw router. The flow data records source and destination address and ports, how much traffic was transferred, the time of day, and how long the connection lasted. Every flow record is about 50 bytes of data, and there can easily be a hundred of them per second. In aggregate, it's a lot of data. And it has privacy implications. I was originally considering making an interactive netflow inquiry tool available on the gateways section of the gw.ampr.org website so gateway operators could see what traffic their AMPRNet router is handling. But because there's no way to restrict it so that someone could only view flows involving their own endpoint or subnet, I think it's too much information to be made freely available for people to browse. And there is the consideration that inquiries could wind up presenting a significant load on the system. I think that presenting anonymized aggregate data wouldn't be a problem, so I'm going to look into that. Probably some traffic density graphs would be ok. And I'm willing, once the tools are installed and working, to make extracts of the data for a gateway operator who is having a problem with his traffic flow. What's people's opinion of this? - Brian

6 8

probbing and attacks on my router
by R P 23 May '17

23 May '17

Hi I was "playing" with my AMPR Router yesterday I had a open user (on purpose) and saw that from that user few IP (not my ones) were logged in after some more research i have discovered that this users was opening connections to other hosts .... That made me suspicious on what going on .... I have checked one of the IP that was connected and back resolve showed customer.worldstream.nl comming via SSH I understand something not good happening i have closed this user rebooted the router (to clear the connection ) and then i started to get alot of connections to port 22 to my router from that host I had to put Firewall rule (drop) for that address and destination port (22)(although im against fire-walling) After less then 24 hours the traffic stopped from that host the trafic (Via UCSD (Encapped) went down from 19 KBytes/sec to less then 1 Kbyte/sec now. I know how to deal with the technical aspects (firewall .etc) What is not understand to me is what is the purpose ... If it is a robot what is the point of fluddling SSH connections is it brute force ? or anything else ? and how come that after 24 hours it stopped it supposed to be endless loop if it is an automated process Please light my eyes on that if you have more experience then me currently the router is "quiet" without non wanted users logged in and un necessary connections I see on the log here and there breake attempt mainly to Ports 23 22 and SIP from various hosts but it is few in a minute Regards Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

7 13

Non BCP38 senders or dynamic blocking of scanners
by lleachii＠aol.com 23 May '17

23 May '17

All, Consider the following - a virus, malicious person, or by accident, a source address is set to 8.8.8.8 - you run a port scan to your job, a test IP, etc. - They have intrusion detection - They use Google DNS It seems a DDoS attack could be very easily launched. Perhaps those folks could sill consider making an ipset of allowed outbound IP addresses. Also be careful how you block your own rules, an attacker spoofing the IP of common addresses could cause DoS. If you were attempting to connect to your IP, a man-in-the-middle attack (or someone who otherwise learns the destination IP and port) would make it seem as you were always blocked (but your firewall hits are greater than you expect). Theres probably common if you change the port and your corporate network team at work begin to see low bandwidth encrypted links on an unknown port. 73, -Lynwood KB3VWG

1 0

ampr-ripd 2.0 -I -E questions
by lleachii＠aol.com 23 May '17

23 May '17

Marius at al, I'm wondering if anyone has tried the new feature that sends RIP44. If so I have a question. If you use the -a, does it remove those routes? I need to account for this in a script I'm writing depending on if the downstream device is on a WAN or if they have a private route/connection between themselves. Since I use policy-based routing, I can keep the false record for my own subnet on table 44 and encap file; but for others (and other projects for AMPRNet), I can see this used to be placed on a second device to provide a real-time looking-glass tool, etc. - Lynwood KB3VWG

2 1

Traffic not routing to my gateway
by Craig Brauckmiller 21 May '17

21 May '17

Hey all, I recently got my gateway and ip block allocations all setup including the DNS piece thanks to Brian and others. I've got the tunnel defined on my router. When I run a TCPDUMP on the physical interface that is hooked up to m169.228.66.251y cable modem, I am not seeing any traffic from the 169.228.66.251 tunnel endpoint. Nor, obviously, am I seeing any traffic on my tunnel interface. How do I troubleshoot this? Thanks Craig KC1ETB

7 20

Re: [44net] ampr-ripd 2.0 released
by Rob Janssen 21 May '17

21 May '17

> Do you have a firewall that drops by default? > On my machine, I have to allow 520/udp from 44.0.0.1 to 520/udp at > 244.0.0.9. I have a firewall rule but it remains at zero. It is unclear where this packet gets lost, when I run "tshark" the RIP transmission is seen, but when I insert a rule "iptables -I amprinp -p udp -s 44.0.0.1 --dport 520 -j ACCEPT" at the top of the list (this rule is selected by "iptables -A INPUT -i tunl0 -j amprinp") it too does not see any traffic. This worked OK in the past but it has suddenly stopped working some time ago, I think about two years. That happened when there was a kernel update, no other changes. Rob

1 0

ampr-ripd 2.0 released
by Marius Petrescu 21 May '17

21 May '17

Hello everyone, I created a new ampr-ripd release according to some wishes of our members. Changes: - brought back option -r, to allow using multicast sockets by default and raw sockets as a backup for systems with multicast issues. This will hopefully sort out the firewall filtering inability on previous releases since 1.13. - added 2 new command line options, -F and -E (capital letters) which allow the forwarding of raw AMPR-RIP messages on a specific interface (-F) and optional to a specific address (-E), similar to the -f and -e options. These RIP messages are raw copies of the incoming ones: password it there and they appear every 5 minutes and will be missing if no data arrives from the AMPR gateway. - added the setting of the proper 44.0.0.1/32 route to conform to the latest gateway changes. Download: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.0.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.0.tgz Have fun, Marius, YO2LOJ

1 0

Re: [44net] Traffic not routing to my gateway
by Rob Janssen 20 May '17

20 May '17

> BTW, the encap file does not change much. On average, one line in it > will change per hour, as a gateway with a dynamic address updates its > address (and it's often the same gateway flipping between two or three > addresses), but gateways come and go at a much lower rate -- I'd guess > one or two a week. So you'd be pretty safe just FTPing and processing > a new encap file perhaps once a day if it winds up being a chore. The automation in the classic FTP client is a bit difficult to use, especially when you want to use it for different sites, but the "wget" and "curl" programs can easily fetch a fixed file from a fixed server with a fixed user/password by combining them all into a URL: ftp://user:pass@server.domain/path/to/file Of course when you fetch and process the file once a day, you will not be able to use those gateways that change IP address once a day due to local provider policy. But probably you'll never notice that... :-) Rob

1 0

Re: [44net] Traffic not routing to my gateway
by Rob Janssen 20 May '17

20 May '17

> I expect you could have more luck by looking in to SLAX scripting as it > should not be to hard to do this fully from the junos api's > I did not check this but i don't think the ipip driver would be > standard. Well, it is not very straightforward so when it is your first script you are probably going to have a hard time... In Linux there is a point-to-multipoint IP tunnel, much as was the case in JNOS when this whole IPIP mesh was designed. You configure only a single IP tunneling interface, usually called tunl0, and you put a set of routes in the route table with the destination subnets, the tunl0 device, and the remote endpoint of the tunnel as the gateway address. Like this: 44.2.2.0/24 via 216.218.207.198 dev tunl0 onlink 44.2.7.0/30 via 73.185.12.233 dev tunl0 onlink 44.2.10.0/29 via 104.49.12.130 dev tunl0 onlink The onlink attribute is required to suppress the "gateway not reachable" warning you would normally get when the gateway is not directly reachable from the system. With this facility, the updating is relatively easy: just make sure the actual routing table agrees with the distributed information, by adding and deleting single routes. Without such point-to-multipoint tunneling, you will have to create a separate tunnel interface for each gateway, and setup routes to the remote subnets pointing to the correct gateway tunnel. Remember there are (way) more subnets than gateways, you need to find the routes with the same remote gateway, and create only a single tunnel device for those combinations, and point the matching subnet routes to that device. To obtain the information about the subnets, you either listen to the RIP broadcasts made by amprgw, or you regularly download the "encap.txt" which has this format: route addprivate 44.2.2/24 encap 216.218.207.198 route addprivate 44.2.7/30 encap 73.185.12.233 route addprivate 44.2.10/29 encap 104.49.12.130 so you need to parse that and get the subnet and gateway fields from it. (this format is the commandline format that JNOS used) There is no separate "list of endpoints" so you have to create that yourself from that list of routes (take the last field and put it in a list, removing duplicates). Now when you have written a script to transform this into commands to create the proper tunnel devices and add the routes, the real fun begins! The next time you get the information, you need to check if there are changes. When there are, there usually will be a change of tunnel endpoint address (for a gateway that is on a dynamic internet address). You will find several entries in the information that suddenly have a different next hop address, but of course they are not grouped together, they are scattered through the lines you received. You will need to locate the correct tunnel device (which you will need to look up using the *previous* table of received information) and change its endpoint. But, there are other possibilities, ocurring less often: a subnet could have been added or removed from a gateway (and maybe moved to another), a new gateway can be added, or a gateway can be removed (with all its subnets). And of course, combinations of the above, e.g. a gateway has its endpoint address changed and at the same time adds or deletes a subnet. That is probably a rare occurrence, but it should not cause disaster (like a crash). Of course you could simplify things by just deleting everything (routes and devices) and rebuilding it from zero whenever there is some change. But that could cause brief interruptions of the routing and/or high load on the CPU. Sure, it can be done. But for someone who is not experienced in programming in general, and has to learn the scripting language for the particular platform as well, it will be tough. I would certainly advise to look at Marius' script for MikroTik, as it of course has the algorithms described above. It would have to be rewritten in a different language and the constructs to add/delete tunnel devices and routes will have to be changed. Rob

3 3

Re: [44net] Gateway in EC2?
by Rob Janssen 19 May '17

19 May '17

> I'm wondering of anyone has successfully got a gateway running in Amazon's EC2 service? > I was thinking of using a raspberry pi with a tinc VPN to the EC2 instance to tie into my RF connection regardless of my IP address. > I hit a wall when it came to getting ampr-ripd running. It is a bit difficult to help you with such a problem description, but in general (I have no experience with EC2) you should be aware that such services do not give you a fully virtualized machine where you can do what you want, but rather they use Xen Paravirtualization where a modified kernel is running, and it often does not include the module required for IPIP tunneling. That may be the wall you are hitting, but it would not be the problem of getting ampr-ripd running but to actually get the tunl0 interface working. So you need to explain better what your problem is. Maybe it can be worked around using another program by Marius: amprd. I have a Raspberry Pi running at a hosting company and running the usual configuration for a gateway under Linux, and of course that does not have that limitation. I have a VPN to it from home. Indeed it is a nice way to get a gateway running without the trouble of getting the IPIP traffic to your home system. (but it is not used much anymore as I now have a radio connection to the network) Rob

2 1

inbound traffic
by Brian Kantor 19 May '17

19 May '17

I built a new inbound ports display https://gw.ampr.org/router/ports.svg which shows a significant amount of traffic that SANS and others identify as being aimed at vulnerable ports on various pieces of equipment. I don't want to just block them, as they have legitimate uses, but if you're running your own firewall, you might want to block them yourself if you don't have any need for the legitimate use. - Brian

2 3

Connection Problem
by vk2tv 19 May '17

19 May '17

I'm trying to access one of Brian's help documents but the connection attempt to http://n1uro.ampr.org/linuxconf/amprnat.txt times out. Is there an issue somewhere that might impact on my attempts? Ray vk2tv

3 10

What happened to the missing inbound encap traffic
by Brian Kantor 19 May '17

19 May '17

As you can see from the graph https://gw.ampr.org/router/encapinpkt.svg, there was a precipitous decline in inbound encap traffic about 19:00 UTC on May 16th. I've been wondering what happened to all that traffic. Well, it turns out that the amount of traffic coming in before that cutoff was anomalously high. There was a host called chocolate-nebula.mit.edu (18.96.0.110) which was sending over 95% of the inbound traffic to amprgw, and had been for several days, before the graph started. I jumped to the conclusion that that amount of traffic was normal, when in fact it was not. So what has really happened was that inbound traffic has returned to normal after 16 May at 19:10. chocolate-nebula.mit.edu is registered on the portal as amprnet-gateway1.amolbhave.com, the gateway for subnet 44.44.7.224/28, belonging to KC1EDX. I don't yet know why it was sending all that traffic, nor why it suddenly stopped. So most of the mystery is solved. Maybe KC1EDX will pop up here and explain what was going on. - Brian

1 0

Gateway in EC2?
by Mark Scrano 18 May '17

18 May '17

Hey, I'm wondering of anyone has successfully got a gateway running in Amazon's EC2 service? I was thinking of using a raspberry pi with a tinc VPN to the EC2 instance to tie into my RF connection regardless of my IP address. I hit a wall when it came to getting ampr-ripd running. If anyone has such a configuration working I would love to pick your brain about your setup. Regards, Mark Scrano K2EXE -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

1 0

Re: [44net] Traffic not routing to my gateway
by Rob Janssen 18 May '17

18 May '17

> Guys, I think I may be missing something here. I've seen a couple > references to RIP being required. I didn't see that mentioned in any of > the on-line docs. Perhaps I've missed it, and if so, I apologize. I'll go > look at the Wiki to see if it is there. > Is this required or optional? It is optional, but I think it will be very unpractical or even impossible to get the IPIP tunneling working on your SRX. Note that it is NOT sufficient to setup a single IPIP tunnel to the amprgw and route all net-44 traffic over that. You need to setup a tunnel to each of the (about 430) gateway systems and route the defined subnets (about 615) over those tunnels. And the IP addresses of some of the endpoints are changing all the time because users are on a dynamic internet IP. To keep that config uptodate in your router, you either need to do AMPR-RIP, or you need to setup elaborate scripting to reconfigure the router whenever required. (regularly downloading the encap.txt file and generating config for it) In practice, you need a Linux box to do the routing, or a MikroTik router that has scripting powerful enough to do the above on its own. With your SRX you will need a separate machine that does the updating. Rob

2 1

amprgw inbound traffic protocol analysis
by Brian Kantor 18 May '17

18 May '17

I got curious about what all the inbound traffic we're experiencing (and mostly rejecting) was all about. Here's a very elementary breakdown of a one minute sample of what I saw on the inbound Ethernet: 22434704 packets read from savefile 344 non-IP packets discarded proto 1 (ICMP) count 87478 proto 2 count 14 proto 4 (IPIP) count 26162 proto 6 (TCP) count 20467723 proto 17 (UDP) count 1829610 proto 41 count 330 proto 47 (GRE) count 23041 proto 103 count 2 I'll do some additional analysis when I have time. - Brian

2 1

Re: [44net] AMPRNet outage?
by Rob Janssen 18 May '17

18 May '17

> I suspected at some point that there is a network using 44 addresses > internally, had some leaks on them and that the garbage (DNS replies, > ICM rejects, IP fragments and such stuff) were the replies from hosts on > the internet receiving that traffic and sending replies back via the > ampr-gw. I think that is not a legitimate use but an attack group that spoofs sender addresses when sending their attacks and they use net-44 addresses as well. To have that go down, more ISPs should implement BCP38 (source address filtering). Unfortunately, there is little incentive for ISPs to do that, because it benefits only others and not themselves. Rob

4 5

Re: [44net] AMPRNet outage?
by Rob Janssen 18 May '17

18 May '17

> This is rather disturbing. Many of the gateways in the gateway > statistics are showing ZERO encap packets coming from them. One of > the busiest normally is the gateway for Germany, 141.75.245.225, which > has not sent ANY encap packets to amprgw since the current stats began Is that still the case? I receive plenty of traffic from that gateway, so when you don't there could be someone who inserted a protocol 4 filter along the way. I can still ping 44.0.0.1 via the tunnel... traceroute to 169.228.66.251 (169.228.66.251), 30 hops max, 60 byte packets 1 xs4all-router (213.222.29.193) 0.262 ms 0.304 ms 0.276 ms 2 0.ae10.xr4.1d12.xs4all.net (194.109.5.57) 0.322 ms 0.ae11.xr4.1d12.xs4all.net (194.109.5.77) 0.341 ms 0.276 ms 3 asd2-rou-1043.NL.eurorings.net (134.222.93.144) 0.320 ms 0.355 ms asd2-rou-1044.NL.eurorings.net (134.222.97.17) 0.370 ms 4 asd2-rou-1022.NL.eurorings.net (134.222.48.222) 0.615 ms 0.544 ms 0.500 ms 5 chg-s1-rou-1041.US.eurorings.net (134.222.48.90) 95.532 ms 95.539 ms 95.543 ms 6 eq-exchange.tr01-chcgil01.transitrail.NET (206.223.119.116) 95.616 ms 95.675 ms 95.644 ms 7 ae-1.80.rtsw.chic.net.internet2.edu (64.57.20.150) 95.879 ms 95.901 ms 95.890 ms 8 et-3-1-0.4072.rtsw.kans.net.internet2.edu (64.57.20.89) 106.891 ms 106.906 ms 106.909 ms 9 ae-0.80.rtsw.salt.net.internet2.edu (64.57.20.146) 126.801 ms 126.922 ms 126.846 ms 10 ae-2.80.rtsw.losa.net.internet2.edu (64.57.20.144) 139.339 ms 139.437 ms 139.436 ms 11 64.57.20.83 (64.57.20.83) 139.681 ms 139.675 ms 140.043 ms 12 dc-tus-agg3--lax-agg6-100ge.cenic.net (137.164.11.7) 140.662 ms 140.780 ms 140.919 ms 13 dc-sdg-agg4--tus-agg3-100ge.cenic.net (137.164.11.9) 142.328 ms 142.342 ms 142.395 ms 14 dc-ucsd-1--sdg-agg4.cenic.net (137.164.23.54) 141.823 ms 141.889 ms 141.998 ms 15 nodem-core--mx0-30ge.ucsd.edu (132.239.254.163) 142.100 ms 142.099 ms 142.086 ms 16 ebu3b-6509-nodem-core-interconnect-vl910-bcast-255-131.ucsd.edu (132.239.255.131) 142.068 ms 142.094 ms 142.162 ms Rob

6 13

Re: [44net] AMPR stats ...
by Rob Janssen 17 May '17

17 May '17

> it is strange that my one camera consume half of the bandwith of all the 44 net bandwith Oh but that is only the traffic from tunneled hosts talking to the internet via amprgw! We output about twice that amount (700kB/s) continuoously on our gateway for only network 44.137.0.0/16. And that is after the Brandmeister hosts have been disconnected for internet addresses due to the DDoS. Before that, it was several MB/s, up to about 8 MB/s last february. Rob

1 0

Re: [44net] AMPRNet outage?
by Rob Janssen 17 May '17

17 May '17

> Perhaps it's time to revisit UDPIP. Does Linux support the use > of UDP port 94 for encapsulation? It appears it has been introduced in kernel 3.18 which is quite recent and will mean there are some issues for many users. (requirement to install a backported kernel and "ip" program that supports the newly introduced "ip fou" subcommand. It is not supported on the systems we are currently running. (Debian Wheezy and Jessie) It also is not supported on MikroTik routers. Rob

2 1

AMPR stats ...
by R P 17 May '17

17 May '17

May someone explain to me how the "Firewall: inbound raw vs outbound encapsulated traffic" show that the encap data is bigger then the raw input ? may i misunderstand something ?

3 9

Re: [44net] AMPRNet outage?
by Rob Janssen 17 May '17

17 May '17

> Perhaps someone in the path between > us and Germany inserted a protocol 4 block That is what I suggest... it is up for us, and we can reach you, so it is probably not a problem in either Germany nor inside your network. Try a traceroute to a few gateways with zero traffic to find if there is a common path or provider. Rob

2 1

DNS Additions
by Craig Brauckmiller 17 May '17

17 May '17

Does anyone know if the network coordinator for MA USA watches this list? I emailed him about adding a couple A records for me to get my 44 net going but haven't heard back. I got his callsign off the portal network page and then had to go to QRZ to find his email. Not sure if he still checks the email or not...so I figured I'd ask here. Better question, why do we need to create a DNS entry for hosts to start routing traffic from the 44 net to my gateway? Thanks Craig KC1ETB

2 3

amprgw statistics
by Brian Kantor 17 May '17

17 May '17

I moved the statistics files and graphs around and added some. https://gw.ampr.org/ still redirects you to www.ampr.org Non-sensitive info is in https://gw.ampr.org/router/ Available without a password. This is traffic counters and graphs. Gateway-related info is in https://gw.ampr.org/private/ A username and password are still required to access this. - Brian

4 6

Re: [44net] the current worldwide Windows ransomware situation
by Rob Janssen 17 May '17

17 May '17

> The reason I prefer IPv6 over IPv4 NAT is it gives me the option to use > the same ports on multiple hosts on my network. IPv4 NAT is quite > crippling for some of ujs (who also happen to know how to manage our > firewalls ;) ). Yes of course NAT is a pain when doing special things, but for most internet users it is not a problem at all. Especially now that the internet has evolved from a peer-to-peer network into a traditional client-server network where a few big companies run all the services and the users connect only to there, even when they want to communicate with another user. What I like about IPv6 is that it gives me out-of-band management of IPv4 networks. Yesterday I did a major restructuring of our AMPRnet-Internet gateway, where a MikroTik CCR has been added to the existing PC Linux solution to take over part of the services, and I could make all the network topology changes with confidence that I would not lock myself out, using IPv6. That is also handy when managing the very complicated IPv4 firewall. In fact so many users have been completely accustomed to NAT that they even apply it to AMPRnet... Putting their systems on RFC1918 addresses and translating it to net-44 addresses in the router. I would not do that... Rob

4 4

some amprgw filtering statistics
by Brian Kantor 16 May '17

16 May '17

Just some data points: in the last 16 hours, the firewall on amprgw has dropped over 43 million attempts to connect to the implicated ports: 623,664,16992,16993,16994,16995. We've also dropped about 2 billion attempts to connect to the other SMB ports: 111,135-139,445, etc. This is AFTER having already dropped all packets from known 'security' scanners like shodan, which therefore aren't counted in those totals. We've dropped 63 million of those. But by far, the most popular inbound is attempts to connect to the telnet port (23) on amprnet hosts; we've dropped 6 billion of those. And we've dropped another 7 billion other packets that were destined for other ports on non-registered amprnet addresses. I don't have details of which ports these are, but I know that port 80 (http) is one of them. At 25 MB/s inbound traffic, receiving packets and filtering them is taking about 10-12% of the machine, leaving it around 85% idle. The DNS nameserver accounts for about 2% of the load. The encap/decap process resource consumption is negligible. It spends about 95% of its time waiting for packets. - Brian

7 13

how to route Mikrotik Gateway Commercial IP to the ISP and not to UCSD ?
by R P 16 May '17

16 May '17

Hi there I have investigated the High drops that my Router get from UCSD with the help of the new PCAP files that Brian Made available for us it tern out that my router MikroTik that sit on the DMZ of the Cable modem Is Probed from the outside world in its Commercial IP and send its Trafic to the UCSD interface which is its default route How can I redirect packets from the outside world that sent to the router commercial IP to go back to the ISP and not go to the UCSD interface ? is there any Mikrotik Expert that can tell me what to do ? I need only to route the ip of the router that sit on the DMZ I saw that another Mikrotik on the AMPRNT get a lot of drops and it looks it have something similar Any help is welcome As i Stated before Im willing to give web telnet Or SSH access Just for Info the router connected on the DMZ of the Main Cable router it uses 192.168.1.x address and the DMZ point to this address Regards Any info is more then welcome Regards Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

3 3

Re: [44net] some amprgw filtering statistics
by Charles 16 May '17

16 May '17

Yes, please. <div>-------- Original message --------</div><div>From: Brian Kantor <Brian(a)UCSD.Edu> </div><div>Date:05/15/2017 19:26 (GMT-05:00) </div><div>To: AMPRNet working group <44net(a)hamradio.ucsd.edu> </div><div>Cc: </div><div>Subject: Re: [44net] some amprgw filtering statistics </div><div> </div>(Please trim inclusions from previous messages) _______________________________________________ I see from the web server logs that some people are attempting to retrieve the graphs but don't have login credentials. My apologies for the hassle; email to me and I'll send some to you. - Brian _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Newbie Question
by Craig Brauckmiller 15 May '17

15 May '17

Hey all, I am new to the 44 net stuff and had a couple basic questions. I went to the archive site and didn't see a search feature so I figured I would start here. I've got my block allocated and am trying to setup my Juniper SRX firewall to tunnel to the 44 net. However, I can't seem to find a place where the tunnel destination address is listed or if there is anything special I need to do on the AMPR site to activate traffic tunneling. I'd be happy to share the config of my Juniper SRX with the community once I get it working. Thanks Craig Brauckmiller KC1ETB

2 1

VA co-ordinator
by Mark Phillips 15 May '17

15 May '17

Would the person handing out numbers in VA please contact me off-list. I need a subnet for Floyd, VA. Thanks!! Mark G7LTT/NI2O

1 0

Re: [44net] the current worldwide Windows ransomware situation
by Rob Janssen 15 May '17

15 May '17

> Some consumer quality routers assume that all LAN addresses *MUST* be > in an RFC1918 range, e.g., 192.168.n.n. The routers usually allow the > user to set the third octet, but not the first or second, and they > reserve the last octet for DHCP and/or local fixed addresses. IIRC, > most allow the user to set the subnet mask's last octet too, but > that's as much flexibility as users get. Some ISPs manage the router and assign a fixed address to the LAN. > Sometimes, the same restrictions apply to the other devices on the > LAN, especially printers, and so it's often easier to put a 44net > address on the "WAN" side of a router and do NAT. Well, I think the main reason why people are doing this is limitations in typical consumer-quality operating systems. One widely used OS appears to have been dumbed down to the level that it is no longer possible to set a second address on a network interface (was possible in older versions!), let alone to configure policy routing. People want to be able to access the AMPRnet using their devices that they also use for internet browsing. It would be straightforward to set an extra 44.x.x.x address on the network and a route for 44.0.0.0/8 pointing to the router used for that, and it would basically work. I do this on my workstation but I also have policy routing to send traffic with my AMPRnet source address to the AMPRnet. So I can also allow access from internet addresses and send the return traffic the right way. But that widely used OS cannot do that, at least not from the GUI (registry hacks probably still work). There are ways to work around it: you can install a second network card, or you can add a VLAN to your network. Unfortunately, that again is not a feature of the rudimentary network code of that OS, it is to be provided in the drivers of the network card. Sometimes it is possible to download drivers from the card manufacturer site and do VLAN, but when the manufacturer does not care about that or places this in a different market segment, you are out of luck. With all those limitations, I can understand why people install a more capable router (e.g. MikroTik) to let it handle the job that is too difficult for MS, and resort to NAT to make their systems available on both internet and AMPRnet. But, doing it that way is even more tricky. It can work correctly, but you carefully have to consider all the possible paths and handle them correctly using suitable NAT rules, routing policy, and multiple route tables. Unfortunately even some professional "firewall devices" are unable to operate in transparent mode and always assume they have to do NAT. There are examples of that in our network as well. People take home left-over big name devices from work and try to use them in our HAMNET, usually encountering all kinds of limitations and also bugs due to the old firmware. Support has ended or there never has been any support without separate, expensive, contract. It is normally more cost-effective to buy e.g. a MikroTik hEX3 and use that, if only because of the huge savings in energy costs... Rob

1 0

Re: [44net] the current worldwide Windows ransomware situation
by Gabriel Medinas 14 May '17

14 May '17

Yes Ruben that is ok but is used the platform .orion to precisely not be located and remain anonymous through thor browser with proxy relay. Any of there attack attemps that we stopped may passed you these links (think are obsolete now) so you can verify for yourself whether they are legal or not. http://sonuh5glplozc2m.tor2web.org/A4113B9D69E5094A http://sonuh5glplozc2m.onion.to/A4113B9D69E5094A or via thor: sonuh5glplozc2m.onion/A4113B9D69E5094A Follow the instructions of the site and then with the ID:A413B9D69E50F94A !!! and good luck with this... 73 de Gabriel YV5KXE Venezuela AMPR-Coordinator Message: 9 Date: Sun, 14 May 2017 15:29:41 +0000 From: Ruben ON3RVH <on3rvh(a)on3rvh.be> To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] the current worldwide Windows ransomware situation Message-ID: <1B69D7CC-274E-4635-8D90-C162A950A5FF(a)on3rvh.be> Content-Type: text/plain; charset="us-ascii" Just a small correction as I don't like to see this kind of misinformation, but .onion is the Tor network and Tor is not underground. It's not because criminals like to use it that it is underground. There are legit sites too within the .onion domain. Ruben - ON3RVH > On 14 May 2017, at 16:59, Gabriel Medinas <gmedinas(a)gmail.com> wrote: > > (Please trim inclusions from previous messages) > _______________________________________________ > Grettings to the group, this Rasomware theme is an evolving project, some > employe just opened an infected email and it was an attack vector on the > internal platform that runs around the LAN via the port 445 SMB protocol > using a security hole that already Microsoft solved two months ago. > > Precisely the attackers know that many companies do not update the OS of > their internal pc for issues of licensing and budget that make them > vulnerable, also do not pay much attention to the safety of their > equipment, here was shown how fragile it is the windows platform for these > attacks and is the bulk of the equipment that these large companies have, > such as the case of Telefonica in Spain, FEDEX, hospital networks in > England, etc. > > These themes are every day in BBVA Corporation in my IT Security > (Cybersecurity) Venezuela work, see this problem in a important evolution > but it is more to come because they will continue looking for new > possibilities to be able to collect the money with the Bitcoins. > > On the question of the domains, those that are in the common Internet those > are not relevant, only the important are the .onion underground that they > use to recolet the extortion money from people-companies through these > crypto tools attacks. > > As Brian says, linux and mac are safe for now... > > 73 de Gabriel YV5KXE > Venezuela AMPR-Coordinator > > > Message: 2 > Date: Sat, 13 May 2017 04:51:33 +0000 > From: R P <ronenp(a)hotmail.com> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] the current worldwide Windows ransomware > situation > Message-ID: > <BY2PR14MB04246C791B6C331478C3B033C7E30@BY2PR14MB0424. > namprd14.prod.outlook.com> > > Content-Type: text/plain; charset="iso-8859-1" > > IM not sure that this is the right group but as i wrote before here we > have top experts in it field so Ill try > > I read the explain on the virus in the sites ... > > The domain is well known .. someone pay for it > > is it so problem to catch the person who paid for this domain ??? > > what about shutting out this domain and by that stop the spread of the > software ? >

1 0

Re: [44net] the current worldwide Windows ransomware situation
by Gabriel Medinas 14 May '17

14 May '17

Grettings to the group, this Rasomware theme is an evolving project, some employe just opened an infected email and it was an attack vector on the internal platform that runs around the LAN via the port 445 SMB protocol using a security hole that already Microsoft solved two months ago. Precisely the attackers know that many companies do not update the OS of their internal pc for issues of licensing and budget that make them vulnerable, also do not pay much attention to the safety of their equipment, here was shown how fragile it is the windows platform for these attacks and is the bulk of the equipment that these large companies have, such as the case of Telefonica in Spain, FEDEX, hospital networks in England, etc. These themes are every day in BBVA Corporation in my IT Security (Cybersecurity) Venezuela work, see this problem in a important evolution but it is more to come because they will continue looking for new possibilities to be able to collect the money with the Bitcoins. On the question of the domains, those that are in the common Internet those are not relevant, only the important are the .onion underground that they use to recolet the extortion money from people-companies through these crypto tools attacks. As Brian says, linux and mac are safe for now... 73 de Gabriel YV5KXE Venezuela AMPR-Coordinator Message: 2 Date: Sat, 13 May 2017 04:51:33 +0000 From: R P <ronenp(a)hotmail.com> To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] the current worldwide Windows ransomware situation Message-ID: <BY2PR14MB04246C791B6C331478C3B033C7E30@BY2PR14MB0424. namprd14.prod.outlook.com> Content-Type: text/plain; charset="iso-8859-1" IM not sure that this is the right group but as i wrote before here we have top experts in it field so Ill try I read the explain on the virus in the sites ... The domain is well known .. someone pay for it is it so problem to catch the person who paid for this domain ??? what about shutting out this domain and by that stop the spread of the software ?

3 2

Re: [44net] the current worldwide Windows ransomware situation
by Rob Janssen 14 May '17

14 May '17

> Yes, I can see your example. Fortunately, one thing I have seen so far > is routers being supplied with all inbound connections stopped. > Furthermore, mine doesn't allow you to totally disable the firewall, > only for specific hosts (which I have done for some key Linux systems), > or for specific ports on specific hosts (which I did on Windows for > testing - I never leave Windows exposed to the net). Now with a router > like mine, your scenario wouldn't work, because the temporary IP > addresses would never be allowed to pass. > So, there are ways to build it into the router design to make it harder > for people to shoot themselves in the foot. :) Yes, I think there has been some ISP/Manufacturer working group to get this cleared up and defined. My ISP waited with IPv6 rollout until this was resolved, and the router they deliver does exactly what you describe above. When IPv6 was designed, the idea was still that every host should be able to communicate with every other host. That has proven to be a bad idea on an open network, so IPv6 had to be crippled to make it viable. But that at the same time removes one of the major incentives to roll it out, as NAT can be used as an alternative solution in most situations. Many places have still not started IPv6 rollout... Rob

2 1

the current worldwide Windows ransomware situation
by Brian Kantor 14 May '17

14 May '17

If you're interested in reading more about the current Windows worm/ransomware, these two sites have brief articles explaining what's up. http://blog.talosintelligence.com/2017/05/wannacry.html https://securelist.com/blog/incidents/78351/wannacry-ransomware-used-in-wid… Note that they recommend blocking ports 139 and 445 to help prevent the spread of the worm infection. Amprgw has been blocking those ports for quite some time, but that doesn't prevent the infection from spreading within a group of computers or an organization. It is strongly suggested that people running Windows should be sure that all issued patches have been applied. As usual, systems running non-Windows OS's (Linux, etc) are immune to this attack. - Brian

8 12

Where is the statistics page ?
by R P 13 May '17

13 May '17

I could find only the Erros s (firewall drops ) page but not the statistics

1 0

router stats
by Brian Kantor 13 May '17

13 May '17

I know that very few of you are looking at the amprgw router statistics, but for those who do care: the current statistics (packet/byte counts) accumulate since router boot time. Would it be more helpful/meaningful if the totals reset at midnight so that they reflect daily trends? Also, some of the numbers are getting large enough that they're not intuitively meaningful. There's no convenient way to insert thousands separators. Would 'scientific notation' (eg, 1.56e9) be helpful? (This is the 'g' format specifier in 'C'.) Or alternatively, notation such as 1.5k, 2.4M, 8.1G, or 1.2T could possibly be generated. - Brian

4 13

Re: [44net] the current worldwide Windows ransomware situation
by Rob Janssen 13 May '17

13 May '17

> Patches are often applied late because it's not rare to experience serious disruption. > Anyway the software being patched is poorly made in the first place. > The problems caused by patches are actually another sign of very poor software design. And not the least: after 25 years of development on Windows the patching mechanism still is in a sad state, requiring unreasonable time and resources to find and install required patches. It is very clear that quality isn't a priority for Microsoft *at all*. They only care about making money, what happens to their customers and how much time they waste on using and maintaining their products does not matter to them as long as they keep buying. Rob

1 0

Re: [44net] Critical vulnerability in Intel Active Management Technology (CVE2017-5689)]
by Rob Janssen 12 May '17

12 May '17

> To help prevent this from affecting AMPRNet systems, I am now blocking > inbound port 16992 at the amprgw gateway. I hope this won't cause you > any difficulties. Thanks for the hint. It is surprisingly difficult to get technical information from the Intel documents. Do you block TCP only or also UDP? And what about ports 16993 and 16994? (and maybe even 623 and 664?) The nice thing about such new vulnerabilities is that they allow you to identify the aforementioned scanners and put them on the permanent blacklist. Aside from shodan.io (that were already on the blocklist) I also see 52.174.52.33 census01.project-magellan.com Yet another annoying "research" project... You could try to get 44.0.0.0/8 opted out via research(a)project-magellan.com Rob

2 2

RIP44 send speed
by Brian Kantor 12 May '17

12 May '17

In the past there have been complaints of some RIP44 packets not reaching their destination, enough so that routes sometimes vanish from the RIP44 table on the receiver. Although there is currently little I can do about packet loss on the network, I have slowed down the rip sender by 100 microseconds per sent packet to avoid saturating buffers on busy networking equipment and thereby avoid causing possible congestion loss. This means that it now takes a little over a second to send the complete set of (currently) 26 RIP44 packets to each of (currently) 435 gateways. I don't know if this was the cause nor whether this will help, but it's a cheap fix and it may help. Slightly slower packet delivery shouldn't negatively affect anyone. RIP44 transmissions are still sent every five minutes. - Brian

1 0

Critical vulnerability in Intel Active Management Technology (CVE2017-5689)]
by Brian Kantor 12 May '17

12 May '17

On May 1st, Intel released a security advisory regarding their Active Management Technology. It's a nasty one, but luckily it doesn't seem to affect home (non-datacenter) PC firmware. > https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&lang… Intel has released a mitigation guide: > https://downloadcenter.intel.com/download/26754 Security researchers have since been able to uncover more details and release proof-of-concept exploit code. There is now a free nmap .nse plugin available to scan for this vulnerability: > https://nmap.org/nsedoc/scripts/http-vuln-cve2017-5689.html To help prevent this from affecting AMPRNet systems, I am now blocking inbound port 16992 at the amprgw gateway. I hope this won't cause you any difficulties. - Brian

1 0

Re: [44net] unreachable gateways
by Rob Janssen 11 May '17

11 May '17

> I've been curious how many of the 435 registered gateways were reachable, > so I collected ICMP unreachable messages during a recent RIP transmission > (which of course sends to every gateway) and got the following: > 33 gateways aren't reachable or are rejecting inbound IPIP packets I think it would be a good idea to somehow keep track of this information and remove or at least mark inactive those gateways for which this condition persists for some amount of time. Especially when protocol 4 is rejected. Host unreachable could be because the internet is down or the power is out, but an explicit protocol 4 rejected indicates nonexistent configuration, that could temporarily exist because e.g. new system has just been installed that has not been configured yet, but should not persist for longer than say 2 weeks. The operator can alwayes re-enable or re-add the gateway when he has found the opportunity to re-install it. Rob

3 3

AMPR + VyOS
by Miguel Rodriguez 11 May '17

11 May '17

Hello everyone! Does anyone have any experience setting up VyOS for use on the AMPR network? I have the IPIP tunnel to UCSD set up, however, I don't know how to proceed from there in terms of RIP. This is what I did so far: set interfaces tunnel tun0 set interfaces tunnel tun0 local-ip 'wanip' set interfaces tunnel tun0 remote-ip 169.228.66.251 set interfaces tunnel tun0 encap ipip set interfaces tunnel tun0 descr "Tunnel to AMPR Gateway" set interfaces tunnel tun0 multicast enable set protocols static table 1 interface-route 0.0.0.0/0 next-hop-interface tun0 set policy route SOURCE_ROUTE rule 10 set table 1 set policy route SOURCE_ROUTE rule 10 source address 44.0.0.0/16 set interfaces ethernet eth1 vif 44 policy route SOURCE_ROUTE set protocols rip interface eth1.44 set interfaces ethernet eth1 vif 44 ip rip authentication plaintext-password [therippass] -- Miguel Rodriguez 12th Grade Student MIGUELR-DN42 / KM4VYU miguemely101(a)gmail.com Tel: *561-758-0631* *Accredited District Since 2008; Re-certification - January 2013* Home of Florida's first LEED Gold Certified School *Disclaimer*: Under Florida law, e-mail addresses are *public records*. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing.

4 12

Odd Features/Bug? ampr-ripd
by lleachii＠aol.com 11 May '17

11 May '17

All, I need to ask if any of the following have been noticed or by anyone before. As I try to test a few things today, I: - cannot forward IPENCAP traffic to another LAN destination while running ampr-ripd 1.16 on my router - cannot block IPENCAP traffic whatsoever at my WAN while running ampr-ripd 1.16 on my router - cannot block receipt of RIP44 packets from AMPRGW running ampr-ripd 1.16 on my router Procedure: When setting up LEDE: -I observed that I no longer had firewall hits for RIP44 from AMPRGW - I removed the rule, and I still receive routes Testing receipt of MACs on tunl0 today: - I removed my rule allowing -p 4 from the IPSET of our GW IPs - I made a port forward rule for -p 4 to a LAN machine I setup with a tunl0 of 44.60.44.2 - I set up routes to use tunl0 - I pinged - Using Wireshark I never received traffic - My router saw no hits - I connected to http://44.60.44.10 to perform a traceroute to 8.8.8.8 - It still worked, even though I have no firewall rule! - the device is still in this configuration - and I noticed one 'leaked' packet that never made it to my test tunl0 interface - I notice that ampr-ripd 1.16 listens on protocol 4 instead of udp/520 as version 1.13 did BUG: It appears my firewall rules regarding IPENCAP/A.K.A. 'dev tunl0' packets - after upgrading from 1.13 to 1.16 are infective. Need to test: - If I configure a valid 44 IP on my router's tunl0, I assume ALL iptables rules for it COULD POSSIBLY be ineffective (since the RIP44 rule is) - If I can send routes in this configuration - If I can receive routes from someone else (with correct PW, of course) - If I receive IPENCAP packets from a non GW (since I have no method of it blocking, except if it exists ampr-ripd.c). Note - I'm not requesting this feature I will test later today. - Lynwood KB3VWG

2 7

unreachable gateways
by Brian Kantor 11 May '17

11 May '17

I've been curious how many of the 435 registered gateways were reachable, so I collected ICMP unreachable messages during a recent RIP transmission (which of course sends to every gateway) and got the following: 33 gateways aren't reachable or are rejecting inbound IPIP packets. So if any of the following gateways have been wondering why they weren't getting any AMPRNet traffic, this may be why. - Brian ICMP 24.247.95.42 protocol 4 unreachable ICMP 40.143.112.188 protocol 4 unreachable ICMP 54.146.4.133 protocol 4 unreachable ICMP 71.226.154.52 protocol 4 unreachable ICMP 73.227.91.174 protocol 4 unreachable ICMP 73.229.62.200 protocol 4 unreachable ICMP 75.145.123.237 protocol 4 unreachable ICMP 81.99.51.155 protocol 4 unreachable ICMP 96.82.54.108 protocol 4 unreachable ICMP 97.84.0.85 protocol 4 unreachable ICMP 104.236.122.16 protocol 4 unreachable ICMP 107.150.38.138 protocol 4 unreachable ICMP 107.172.42.138 protocol 4 unreachable ICMP 107.223.221.1 protocol 4 unreachable ICMP 158.69.169.207 protocol 4 unreachable ICMP 159.203.42.8 protocol 4 unreachable ICMP 162.157.83.249 protocol 4 unreachable ICMP 172.114.102.251 protocol 4 unreachable ICMP 172.90.97.192 protocol 4 unreachable ICMP 177.131.213.13 protocol 4 unreachable ICMP 185.10.249.21 protocol 4 unreachable ICMP 189.27.214.32 protocol 4 unreachable ICMP 195.187.71.116 protocol 4 unreachable ICMP 205.171.203.226 protocol 4 unreachable ICMP host 69.181.181.170 unreachable ICMP host 73.146.173.214 unreachable ICMP host 78.236.231.196 unreachable ICMP host 104.131.81.118 unreachable - admin prohibited ICMP host 104.5.53.79 unreachable ICMP host 179.190.230.27 unreachable ICMP host 188.230.236.122 unreachable ICMP host 201.227.57.207 unreachable ICMP host 216.161.250.188 unreachable ~

1 0

Re: [44net] storm blocking
by Rob Janssen 11 May '17

11 May '17

> Yes, it's subsided quite a bit. The amprgw machine is only spending less than > 15% of its processor time filtering packets, vs over 25% earlier and on > the weekend. Perhaps posting my filter script/program was another fine > example of closing the barn door after the horse has bolted. Well it may come back anytime of course... The strange thing is that I see no peak at all in the traffic graphs made over the past days and weeks, and there have been much higher peaks in the past. But maybe you just were not looking at that time... (a couple of weeks we also experienced a DDoS attack that had several orders of magnitude more traffic) I have done some tracing in the past to identify the most obvious problems and I can understand that you become more and more worried when studying the problem. As you well know, it consists of both attempts to hack the systems and of backscatter from attempts to attack others using spoofed source addresses. > Just now, it took 287 seconds to gather 100 million packets, comprising > 7100 different source addresses. This is rather more than usual. The > blocking table now contains 18,000 entries. I have a static blocking table that has the addresses of shodan.io and other miscreants of this world, and the "research institutes" that consider it research to scan other people's networks to map out vulnerabilities etc. That includes 169.228.66.91 and 169.228.66.138 but there are lots of others so no need to get worried. I do not bother to block the scattered Chinese addresses that do only telnet scanning, for that purpose I have put a rate limiter in the firewall that limits the number of unanswered SYN requests per source address using the "recent" matching module of iptables. Rob

4 3

What records AMPR.ORG dns allow ?
by R P 11 May '17

11 May '17

Hi Someone know what currently the ampr.org DNS allow to enter ? I know of A and MX ... is there other ? (example SPF) ? Any Info Welcome .. Regards Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

6 6

Re: [44net] storm blocking
by Rob Janssen 11 May '17

11 May '17

> The second one > runs a wall display in the department, it shouldn't be probing anything. > It's a reassigned machine, so perhaps a previous user of that machine > was doing some research scanning too. Sorry about that. At the time I put it on the list it had the reverse DNS ipsecscanner.sysnet.ucsd.edu and that is what it was doing. I removed it now. A problem of my method of blocking is that I cannot keep stats of activity of the address, so addresses may remain on the list far too long. But again, there are enough other entries for "research" from several other US and German universities. It appears to be a popular way of annoying people. Of course the interesting thing about the UCSD ones was that the traffic came through the tunnel even though our network is BGP routed. Not sure if it is still like that, I believe you changed something there. Several scanners offer opt-out but I think the research is mainly to see what people do when removal is promised but not done or only very temporarily. For example, I contacted the shodan.io guy twice for removal from his scanner, both times he removed our network only to re-add it within days. He probably expects that you will check after he answered the mail, see it is gone, and then not pay attention to it so he can continue his abuse. Rob

2 1

Re: [44net] storm blocking
by Rob Janssen 10 May '17

10 May '17

> The DDoS attack on net 44 continues. I'm filtering out a goodly amount > of it at amprgw, but the people whose subnets are directly connected (BGP > announced) are getting hit too, and there's nothing I can do to filter it > out here. Our traffic is not particularly high here, of course there is a few Mbit/s of noise but it has been higher at times. Rob

3 3

storm blocking
by Brian Kantor 10 May '17

10 May '17

The DDoS attack on net 44 continues. I'm filtering out a goodly amount of it at amprgw, but the people whose subnets are directly connected (BGP announced) are getting hit too, and there's nothing I can do to filter it out here. Basically, if you're directly connected (ie, not on a tunnel), you have to add a list of bad guys to your own firewall blocking. Here is a little script that will create a list of candidate addresses for blocking. You'll need the 'badguys' program, which I'll post below. What this does is give you a list of addrsses that sent you more than 1000 packets in the sample period. If you're connected via tunnel, you probably don't need this. I run this several times a day to accumulate a list of bad guys. I sample 100 million packets at a time; smaller subnets will probably want to use a smaller sample size. This was developed on FreeBSD but I'm told it works fine on Linux Hope this helps. - Brian ----------------------------------------------------------- block.sh: #!/bin/sh # # generate a list of possible bad guys # # sample incoming traffic, 100,000,000 incoming packets # during DDoS storm on a /8, this takes about 3 minutes time tcpdump -w /tmp/t.pcap -s 40 -c 100000000 # turn into a list of source IP addresses with counts, # sorted by decreasing count # throw away all those counted less than 1000, # delete the count from the line # elide our own addresses (put your own in the egrep) # store in a file ./badguys /tmp/t.pcap \ | sort \ | uniq -c \ | sort -rn \ | sed -e '/^ /d' \ | sed -e 's/.* //' \ | egrep -v '^44\.|^169\.228\.' \ > /tmp/badguys # all done with this file rm -f /tmp/t.pcap exit 0 ----------------------------------------------------------- badguys.c: /* * reads pcap capture file (use tcpdump -w to create) named * * spins through it, listing the IP source address on stdout * prints summary statistics on stderr * * the documentation on the pcap library leaves a lot to be * desired, use the source. a lot of what you need is in tcpdump.c * * compile me with * cc -g -Wall badguys.c -lpcap -o badguys * * (You'll need to have libpcap installed) * * Brian Kantor, UCSD, 2017 */ /* probably most of these includes are superfluous */ #include <sys/errno.h> #include <sys/types.h> #include <ctype.h> #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <net/ethernet.h> #include <netinet/in.h> #include <netinet/in_systm.h> #include <netinet/ip.h> #include <arpa/inet.h> #include <pcap/pcap.h> #include <pcap/bpf.h> void getpkt(u_char *, const struct pcap_pkthdr *, const u_char *); char * iptoa(u_long); int capcount = 0; int skipcount = 0; int main(int argc, char**argv) { char inpcapname[FILENAME_MAX+1]; char errbuf[BUFSIZ]; pcap_t *pcap; int rslt; if (argc != 2) { fprintf(stderr, "Usage: %s pcapfilename\n", argv[0]); exit(1); } strncpy(inpcapname, argv[1], FILENAME_MAX); fprintf(stderr, "opening PCAP file %s\n", inpcapname); pcap = pcap_open_offline(inpcapname, errbuf); if (!pcap) { fprintf(stderr, "Error: %s\n", errbuf); exit(1); } /* * read through the capture savefile */ rslt = pcap_loop(pcap, 0, getpkt, 0); if (rslt) { fprintf(stderr, "pcap_loop returned %d\n", rslt); pcap_perror(pcap, "pcap_loop returned"); exit(1); } pcap_close(pcap); fprintf(stderr, "%d packets read from savefile\n", capcount); fprintf(stderr, "%d non-IP packets discarded\n", skipcount); exit(0); } /* * called by pcap_loop once per packet read from savefile */ void getpkt(u_char *user, const struct pcap_pkthdr *h, const u_char *p) { struct ip * ip; u_short * ethertype; capcount++; /* get the Ethernet packet type */ ethertype = (u_short *)&p[(2*ETHER_ADDR_LEN)]; /* we only want IP packets */ if (ntohs(*ethertype) != ETHERTYPE_IP) { skipcount++; return; } /* IP packet starts after Ethernet header */ ip = (struct ip *)&p[ETHER_HDR_LEN]; puts(iptoa(ntohl(ip->ip_src.s_addr))); return; } /* * nicely format host-byte-order u_int into dotted quad * returns pointer to a small static buffer; you can't * call this more than once in a single syslog or printf statement */ char * iptoa(u_long ipaddr) { static char buf[32]; snprintf(buf, sizeof buf, "%lu.%lu.%lu.%lu", (ipaddr >> 24) & 0xff, (ipaddr >> 16) & 0xff, (ipaddr >> 8) & 0xff, (ipaddr) & 0xff); return buf; }

4 14

Re: [44net] iptables logging of IPIP
by Rob Janssen 10 May '17

10 May '17

> Perhaps then I didn't glean that data...but HOW does one 'decode' that > MAC then? > Meaning, how do I see SRC, DST protocol number, etc.? > (this might be helpful looking through kernel-mod ipt) That MAC is just a hexdump of the IP header so you extract the bytes you want and convert them to decimal. It should have been only 20 bytes but it is much longer, probably someone misunderstood the length field somewhere. Rob

1 0

Re: [44net] iptables logging of IPIP
by Rob Janssen 10 May '17

10 May '17

> What [additional] information does this MAC field provide to you on the > tunnel? > Does this field change per packet? > Is there some documentation on how to decode it? > Is it a hashing of some sort, or just a hex copy of the data (IP header)? All these questions are answered in my initial post. It was useful, as it allowed to see what tunnel endpoint had sent a packet when it was dropped by the firewall on the tunl0 device itself. Of course the tunnel source can be seen on the eth0 device but there you cannot (or it is very difficult to) examine the encapsulated packet. Rob

2 1

iptables logging of IPIP
by Rob Janssen 10 May '17

10 May '17

Today I noticed that the log on our gateway lost some detail for IPIP traffic. (now that everyone is discussing trouble with tunneled packets...) In the past with Linux kernel 3.2 and 3.16, when some packet incoming over tunl0 was hitting a LOG target in the iptables firewall, it would log a MAC address of the entire IP header as hex bytes (colon separated), like this: Apr 16 07:39:13 gw-44-137 kernel: [1266597.275238] Packet DROP: IN=tunl0 OUT=eth 1 MAC=45:00:00:44:10:f9:00:00:f9:04:e9:f9:54:6a:7e:b8:d5:de:1d:c2:45:00:00:30:64 :21:40:00:7e:06:29:1a:c0:a8:58:0a:2c:89:2a:51:e9:c0:14:66:1f:fa:64:c8:00:00:00:0 0:70:02:20:00:70:a9:00:00:02:04:05:b4:01:01:04:02:c8:78:03:6b:1a:74:bd:29:37:8d: da:27:61:d7:2f:22:b0:b5:2b:b8:b4:61:3a:60:08:23:48:1b:26:15:57:80:00:00:85:ec:03 :32:df:df:85:46:bb:b3:40:e4:0f:df:4b:3d:93:e0:ed:f3:46:d4:e0:17:68:b6:dd:5d:f1:3 f:1b:1e:6f:a0:f0:69:5c:28:4a:3c:24:17:20:ff:e5:97 SRC=192.168.88.10 DST=44.137.4 2.81 LEN=48 TOS=0x00 PREC=0x00 TTL=126 ID=25633 DF PROTO=TCP SPT=59840 DPT=5222 WINDOW=8192 RES=0x00 SYN URGP=0 (wrapped) Ok, that was much too long, there was probably a bug somewhere and the intention was to show only the outer IP header. Recently I switched to kernel 4.9 but now the packets are logged with no info at all: May 9 18:05:57 gw-44-137 kernel: [359091.001991] Packet DROP: IN=tunl0 OUT= MAC= SRC=192.168.15.2 DST=44.137.75.242 LEN=243 TOS=0x00 PREC=0x00 TTL=123 ID=39243 PROTO=UDP SPT=5198 DPT=5198 LEN=223 The MAC field is now simply empty. With the first format I had a small perl script that processed the log entries and showed the tunnel endpoint that was sending the packet: Apr 16 07:39:13 gw-44-137 kernel: [1266597.275238] Packet DROP: IN=tunl0 OUT=eth1 TUNL=84.106.126.184 SRC=192.168.88.10 DST=44.137.42.81 LEN=48 TOS=0x00 PREC=0x00 TTL=126 ID=25633 DF PROTO=TCP SPT=59840 DPT=5222 WINDOW=8192 RES=0x00 SYN URGP=0 However, now this is no longer possible. I have tried finding info about it but no success yet. Does anyone know if there is some parameter to tune this behaviour? Rob

2 1

Re: [44net] iptables logging of IPIP
by Rob Janssen 10 May '17

10 May '17

> In the past with Linux kernel 3.2 and 3.16 > Recently I switched to kernel 4.9 That was incorrect. The first behaviour was with kernel 3.2 and the 3.16 kernel does not log that long MAC address anymore. The 4.9 kernel is on another system, it is not related to this. Rob

1 0

gateway errors detail available
by Brian Kantor 09 May '17

09 May '17

If your gateway appears in the pkterrors.txt file, the packets which caused that error to be logged and the packet to be dropped are now available in a file you can retrieve with your web browser. They are binary log files, so you'll need a program to interpret them. The URL for a typical file is https://gw.ampr.org/private/errors/67.164.64.8.bin where of course the IP address part changes to whatever your gateway address is. The files are removed and start fresh at midnight Pacific time (GMT-7 or -8). For some error-prone sites, they get large-ish. The format of each file is /* * 2 bytes error number (unsigned short) * 2 bytes packet length (unsigned short) * 4 bytes time (seconds since epoch) * 4 bytes fractional seconds (microseconds) * n bytes (packetlen) encapped IP packet in network byte order */ I have a 'C' program that will interpret the file, which you may have if you're interested. It calls some library routines that you probably don't have, so you'll have to modify it to get it to run on your system. In particular, the error number and packet content interpreters are up to you. I don't think the compiled code will run on Linux but you're welcome to it if you have a FreeBSD system to run it on. Or if you like, I'll run it on your gateway error log file and mail you the output. That looks like this: timestamp (GMT) len err error -------------------- ---- ---- ---------- 2017-05-08T19:04:32Z 40 [19] dropped: non-44 inner source address ver=4 hl*4=20 tos=00 ip_len=40 id=d431 off=0000 ttl=244 proto=6 cksum=7d51 [TCP] 184.105.139.107:44864 -> 44.118.5.2:16992 2017-05-08T19:05:51Z 40 [19] dropped: non-44 inner source address ver=4 hl*4=20 tos=00 ip_len=40 id=18f4 off=0000 ttl=43 proto=6 cksum=5b02 [TCP] 181.23.53.75:58147 -> 44.118.5.2:2222 etc. So far, keeping these log files doesn't seem to burden the system very much. If that changes, I'll have to discontinue them. - Brian

5 13

gateway and host bad packets report
by Brian Kantor 09 May '17

09 May '17

The amprgw router is now periodically preparing a report of the bad packets that it discards. You can retrieve a copy of this report right next to the statistics report: <https://gw.ampr.org/private/pkterrors.txt>. You'll need the same userid and password as for the stats.txt file (same as the one you use to fetch the encap file from the portal.) It's in gateway and source address order to make finding your own gateway and host in the listing somewhat easier. Current plan is to update the report every 15 minutes, and restart the tally at midnight Pacific time. Here are the first few lines (there are currently about 2,300). Let me know if you have any problems or questions with this. - Brian Last update at Wed May 3 15:45:00 2017 gateway inner src #errs indx error type ---------------- ---------------- ----- ---- ------------------------------- 2.84.96.101 44.154.0.1 9 [ 8] dropped: encap to encap 2.84.96.101 44.154.2.1 3 [ 8] dropped: encap to encap 2.84.96.101 44.154.3.1 3 [ 8] dropped: encap to encap 2.84.96.101 44.154.4.1 4 [ 8] dropped: encap to encap 2.84.96.101 44.165.2.3 106 [ 8] dropped: encap to encap 18.96.0.110 44.44.7.225 6 [ 8] dropped: encap to encap 18.96.0.110 44.44.7.232 8 [ 8] dropped: encap to encap 23.30.150.141 23.30.150.141 1326 [19] dropped: non-44 inner source address

6 12

Intrusion Detection and Prevention - LEDE and pfSense
by lleachii＠aol.com 09 May '17

09 May '17

All, I was wondering if anyone is using pfSense as their gateway's router OS. If so, have you been successful at compiling a running version of ampr-ripd for it? I'm very interested in pfSense's intrusion detection and prevention using Snort. I may be willing to test a Gateway if someone has used a compatible version of ampr-ripd (FreeBSD 10.3 64-bit). Also, I've asked the LEDE developers to consider adding a blocking feature to the Snort package available on the device (https://bugs.lede-project.org/index.php?do=details&task_id=772). 73, - Lynwood KB3VWG

1 0

Image for Gateway with Raspberry Pi
by R P 09 May '17

09 May '17

Is there any place that i can grab image for raspberry pi that will allow the following 1) ipip 2) option for TNC software with Net/ROM support and TCP/IP If there is Jnos its better for me as i know it from the past (to allow users from radio to gain access) 3) MMDVM support (to allow connect a DMR repeater based on MMDVM and Arduino) I currently have a working set consist of PI and MMDVM software connected to the arduino running on the AMPRNET but the Pi dont support IPIP Is it more easy just to add the IPIP support for my Image ? (please dont tel me "get this and this and compile" as I dont know to compile But if it is only to install something with simple command i can do it ) any help / recommendation is welcome Regards Ronen/4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

2 1

Re: [44net] gateway errors detail available
by Tim Osburn 09 May '17

09 May '17

Brian, Since you are using Apache perhaps you can enable more client details in your log verbosity by changing your LogFormat from the default settings to the combinedio settings which will include more information about the client software that is connecting to your web server. Such details as these can be shown if you increase your LogFormat: LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio CustomLog "logs/access_log" combinedio Client Agent (small sample) "Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0" "Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16 (internal dummy connection)" "Googlebot/2.1 (+http://www.google.com/bot.html)" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)" "Mozilla/5.0 (compatible; MojeekBot/0.6; +https://www.mojeek.com/bot.html)" Tim Osburn W7RSZ / JG1MBR https://www.osburn.com On Mon, 8 May 2017, Brian Kantor wrote: > Date: Mon, 8 May 2017 23:27:14 -0700 > From: Brian Kantor <Brian(a)UCSD.Edu> > Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] gateway errors detail available > > (Please trim inclusions from previous messages) > _______________________________________________ > Yes, the host 'hamradio.ucsd.edu' where the mailing list is hosted > also archives all messages and makes them available via the web. > > It's amusing: despite not being real, from the following Apache > log entries, no-such-file has been a popular target this evening: > > gw.ampr.org-ssl 70.39.157.194 - - [08/May/2017:17:56:38 -0700] "GET > /private/no-such-file.txt HTTP/1.1" 401 381 > gw.ampr.org-ssl 66.85.73.59 - - [08/May/2017:17:58:59 -0700] "GET > /private/no-such-file.txt HTTP/1.1" 401 381 > gw.ampr.org-ssl 220.233.167.221 - - [08/May/2017:17:59:43 -0700] "GET > /private/no-such-file.txt HTTP/1.1" 401 381 > gw.ampr.org-ssl 4.79.123.0 - - [08/May/2017:18:09:35 -0700] "GET > /private/no-such-file.txt HTTP/1.1" 401 381 > gw.ampr.org-ssl 68.40.58.30 - - [08/May/2017:18:56:26 -0700] "GET > /private/no-such-file.txt HTTP/1.1" 401 381 > gw.ampr.org-ssl 4.79.123.0 - - [08/May/2017:21:42:57 -0700] "GET > /private/no-such-file.txt HTTP/1.1" 401 381 > gw.ampr.org-ssl 165.225.80.161 - - [08/May/2017:21:48:27 -0700] "GET > /private/no-such-file.txt HTTP/1.1" 401 381 > > The first one above was logged just 19 seconds after I posted the message > to the list. The others came later; they could be humans. Note that > none of them logged in; they just tried to fetch the file and went > away. Oh, I'm not concerned, I just was a bit surprised. And curious. > - Brian > > On Tue, May 09, 2017 at 04:42:26AM +0000, Ruben ON3RVH wrote: > > Is the content of the list posted on a website? Like for archiving > > purposes? > > Otherwise someone might have a mailbox from the list configured with a > > scraper.. > > Can you see which is the source IP for the requests? Maybe this can lead > > you to the correct person.. > > 73, > > Ruben - ON3RVH > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net >

2 1

Re: [44net] gateway errors detail available
by Brian Kantor 09 May '17

09 May '17

I'm not sure I made this clear: with the change from my homegrown format to PCAP, the file names changed from <address>.bin to <address>.pcap. So you'd fetch https://gw.ampr.org/private/errors/62.147.189.164.pcap for example. - Brian

1 0

Test Server
by M6XCV (Mike) 08 May '17

08 May '17

Hi, I added a gateway to one of my servers and set up a packet capture system on it. It is running a webserver inside a container with the relevant gateway configuration. The prefix is using the "BGP routed subnets" configuration whereby the gateway is inside the prefix, but using a /31. https://u4477715.ct.sendgrid.net/wf/click?upn=Ki4chJONuNfM0VomxEE-2BoZH6yGO… It should auto-detect the client IP and captures all packets to/from that address. If the client IP is within 44/8 then it will check the routing table for a gateway and if so include that IP as well. I am not sure if there would be concerns with allowing the user to type an IP address to capture to/from, given that it's a non-production gateway. I have the subnet 44.131.14.252/31 registered on the portal with a gateway address of 44.131.14.253. 252 should send encapsulated packets and 253 should send directly. Both addresses are on the same host. I have removed my previous route for 44.131.14.0/24 because nested gateways don't work properly. I have tested to several destinations and it seems to work, but if anyone finds something I've missed let me know! If it works properly and is useful then a hostname under ampr.org might be more appropriate, but for now I’m just using a hostname under my domain. Thanks, Mike, M6XCV

6 14

simple way to know when new encap file created ?
by R P 08 May '17

08 May '17

Hi there Is there a simple way to know when new encap file created ? beside downloading the file itself and looking on the file header ? My ISP replace my IP an hour ago and i still dont have connection .. in the portal there is no time stamp when looking on the gateways list when the new update made .... Im using DYNDNS method and the portal still show my old IP of course that the DYNDNS new ip is already updated Of course i can edit it by hand in the portal but that is not the intention Regards Ronen - 4Z4ZQ

3 3

probe responses
by Brian Kantor 08 May '17

08 May '17

With all the probes going on to various AMPRNet hosts, it might be wise for you to configure your hosts to NOT reply when an attempt is made to access a port on which nothing is listening. Ordinarily, a host system will reply with a TCP reset or a UDP port unreachable, and this contributes to the outbound traffic from your host. There are probably 'blackhole' options you can set. On FreeBSD, they are sysctl net.inet.tcp.blackhole=2 sysctl net.inet.udp.blackhole=1 I don't know if Linux has similar options. I rather assume it does. Note that the latter option may break traceroutes to your system. It's probably also wise to limit the number of replies to pings so that rabid pingers won't pollute your outbound connection. sysctl net.inet.icmp.icmplim=5 Which limits replies to 5 per second, down from 1000 default. In the Linux kernel, there is what seems to be a similar option: sysctl net.ipv4.icmp_ratelimit=5 Perhaps someone can confirm that this is correct. - Brian

2 1

Greetings All I'm Online, Finally!
by Tom Cardinal 08 May '17

08 May '17

After fighting with my system off and on for months I'm finally on AMPRNET but I'm not sure If I'm on the mesh yet. I can get to google and it looks like anywhere on the Internet and can get to my cox email using the thunderbird email client from my workstation. I think I had problems in the past because I had a pre-existing strong iptables firewall and I tried to adapt the Linux configuration on the wiki to the existing strong firewall. Yesterday I decided to start from scratch and build using the Linux gateway instructions on the wiki. I had it working but it seems it failed after I restarted the gateway, I had no connectivity from my gateway to any of my local systems after the reboot. Today I rebuilt from scratch again and it seems to be working except it seems I can't get to anything in the 44/8 network except my own IP block. I've installed the latest ampr_ripd available as of today but need to know how to tell if it's adding routes into the routing table. My current setup is a Linux router, three Raspberry Pi and a Linux Desktop that serves as my workstation (Yesterday it was a headless Raspberry Pi). Tests I've done: 1. A query on Google for "What's my IP address". I got back 44.98.63.3 (my workstation) proving I'm going through the AMPR gateway. When I attempt to connect to some of the services linked from the wiki such as http://n1uro.ampr.org/do.shtml and http://whatismyip.ampr.org I don't get responses back. So my first question is how do I test to see if I have mesh routing up to the rest of the 44Net? 2. I need to learn how to set up iptables to only accept ipencap packets from AMPR gateways. I suspect it requires using ipset which I've used in the past for dropping traffic from systems trying to crack into my router which leads me to my second question. Is there anyone out there willing to show sample code how to allow ipencap traffic only from AMPR gateways? 3. Last night before I restarted and lost ability to use my workstation (remotely, I have not figured out why it failed yet) I was able to log on to my VPS at Linode from my ISP provided space and then SSH into my workstation on my 44/8 address through the tunnel... At the time the workstation was the headless Raspberry Pi, this worked perfectly. I also notice my google traffic uses HTTPS and my email client is using port 465 and 993... all of these are encrypted. My third question: I know they aren't allowed over the air, so how do we account for/deal with software that insists on using encrypted protocols? Is SSH allowed for remotely maintaining our nodes? 4. A couple of weeks ago, I ordered and received the parts to build a Stratum 1 Time server that I intend to make publicly available to the 44Net as a service to the 44Net community. Once I get it online and the security in place to prevent nefarious activity, How do I announce it? I intend to have a web server, a time server, a DNS server and an NNTP server online as well as a local packet node and a tunnel to the AREDN and possibly a link to the HAMWAN out of Tampa if they'll allow me to link to them. I'm open to suggestions on proper operating procedure. -- Tom Cardinal/MSgt USAF (Ret)/BSCS/CASP, Security+ ce

3 2

Correct behaviour towards BGP subnet.
by M6XCV (Mike) 08 May '17

08 May '17

Hi, This might be an academic question in practice, but what is the correct configuration for sending towards a BGP routed subnet, or for 2 subnets communicating with each other? 44.131.14.252 is behind 44.131.14.253 44.130.121.1 is behind 44.130.121.2 This is the current behaviour. For the purposes of testing, packets sourced from 252 were encapsulated and 253 were unencapsulated. https://u4477715.ct.sendgrid.net/wf/click?upn=MJaTQVDJZogYIZySndf7y-2BCWLgZ… .1 sends directly to .252 and .253. .2 sends encapsulated to .252 and directly to .253. I would say packets to 1 or 252 should be encapsulated. I don't know if there is any point adding an extra header to something addressed to the gateway. Thanks, Mike, M6XCV

1 0

storm
by Brian Kantor 06 May '17

06 May '17

I'm been seeing rather a storm of incoming packets to the amprgw gateway; there are six times as many inbound packets to routable AMPRNet addresses as outbound. The firewall is doing its duty: in the last about 24 hours it's discarded 9,905,154,331 incoming packets as being from bad guys, and of the packets that did get past the badguy list, 24,974,234,978 were discarded. It's running around 30 MB/s, at about 20 million packets a minute. Looking at the incoming traffic, it appears to be mostly TCP connection requests with large window sizes to varying 44.x.x.x addresses, with lots of different destination port numbers but many are to port 23 (TELNET) and port 80 (HTTP). There's a goodly number of UDP requests to port 53 (DNS) too. The system seems to be about 85% idle. - Brian

3 3

amprgw router bug fixed
by Brian Kantor 06 May '17

06 May '17

I just found and fixed a bug in the router where it would occasionally reject a valid destination as being an encap-to-encap route and discard the packet. Detail: Rob's address-mask-and-index scheme with the huge global addresses array only works if you FIRST check that the address is on network 44. Oops. Anyway, I restarted the packet errors tallys so they won't show the erroneous results of this bug. - Brian

1 0

Re: [44net] Gateway with 44 IP for testing
by Brian Kantor 06 May '17

06 May '17

I have also noticed that traceroutes through the amprgw router don't seem to work, although the destination host is reachable. I have yet to spend much time on figuring out why this is. - Brian On Fri, May 05, 2017 at 11:35:40PM +0100, M6XCV (Mike) wrote: > I think this is because you are trying to send via the gateway. > > I am not sure why, but I have tried using the gateway to access the > internet and my packets go missing. I assumed it should work, however the > fact that it did not was not something I thought it was worth investigating > as I am BGP routed. If are trying to reach me through the main gateway then > perhaps it is worth asking Brian to look in to it? > > For the record, I attempted to ping you and my outbound seems fine. > https://u4477715.ct.sendgrid.net/wf/click?upn=MJaTQVDJZogYIZySndf7y-2BCWLgZ… > 668edee920.pcap > > I can ping 44.0.0.1. Traceroutes also show my packets reach the gateway but > go no further. I added a static route for 8.8.8.8 encapped via the gateway > and it gave me this. > > traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets > 1 onsite.notmike.uk (44.131.14.129) 0.412 ms 0.392 ms 0.382 ms > 2 Gateway.AS206671 (44.131.14.254) 9.972 ms 9.989 ms 9.988 ms > 3 amprgw.sysnet.ucsd.edu (169.228.66.251) 158.942 ms 158.981 ms > 159.397 ms > 4 * * * > 5 * * * > > I suspect a firewall rule, however there are A records under ampr.org for > all of my IP addresses. > > Thanks, > Mike, M6XCV

3 5

Gateway with 44 IP for testing
by Christopher S. Munz-Michielin 05 May '17

05 May '17

Hello All, I've just implemented the newest version of Marius' Mikrotik script which enables accessing 44net IPs using a gateway in 44 address space, and was wondering if there is an IP which uses this configuration I can test my setup against. The network which Marius was originally tested with (44.130.120.0/24) seems to no longer be present in my routing table. Cheers! Chris VE7ALB

5 10

misconfigured gateways
by Brian Kantor 05 May '17

05 May '17

The top 5 misconfigured gateways: These account for more dropped packets than all the rest of them. These are stats from midnight local to about 20 hours later. The fifth entry is kind of interesting; it has an inner source address of amprgw itself, which is clearly wrong. I don't quite see how that could be happening. These AREN'T causing any noticeable problems for amprgw or anyone else, but a lot of things must not be working properly for those gateway operators. I mention them here because the gateway operators may be scratching their heads over why some connections don't seem to be working. - Brian Last update at Thu May 4 20:15:01 2017 gateway inner src #errs indx error type ---------------- ---------------- ----- ---- ------------------------------- 77.138.34.39 192.168.1.180 26168 [19] dropped: non-44 inner source address 174.97.179.219 44.92.21.35 24627 [ 8] dropped: encap to encap 23.30.150.141 23.30.150.141 17839 [19] dropped: non-44 inner source address 59.167.198.158 44.225.125.2 8137 [ 8] dropped: encap to encap 85.234.252.133 169.228.66.251 6361 [19] dropped: non-44 inner source address [etc]

1 0

Re: [44net] gateway and host bad packets report
by Rob Janssen 04 May '17

04 May '17

> Oops; 23.30.150.141 is me. I think I've mitigated it via firewall rules now. It is often caused by traffic from the gateway system itself where the system has decided to use the internet source address rather than the desired 44-net address. On your system this is more likely to happen because your internet address is lower than 44. (when there is a complete tie on what address to use one of the last decisions sometimes is to use the lowest address) You can often this by setting a preferred source address on some route(s), in this case probably a default route in the AMPRnet-specific route table pointing to amprgw. Rob

2 1

Re: [44net] Peculiar packet
by Jeremy Cooper 04 May '17

04 May '17

On Wed, 26 Apr 2017, Brian Kantor wrote: > A few times a minute, a host claiming to be ke6jjj-8 (44.4.39.8) > is sending an encapped packet that is peculiar: it is either 40 or 44 > bytes long, but the length field in the IP header is set to a varying but > very large packetsize (for example, 61,683 bytes) and the Don'tFragment > bit is set so the amprgw IP kernel sending routine can't break it up > into MTU-sized fragments - thus it gets a transmit failure and isn't > sent anywhere. I think I'm closer to finding out why this happens. I use a firewall rule (using FreeBSD ipf(8)) to make sure that traffic leaving my network with a source of 44.0/8 is redirected to the tunneling interface: # Make certain AMPR/44 hosts reaching outwards will tunnel through AMPR # gate pass out quick on vlan0 to gif0:44.0.0.1 from 44/8 to any I believe, however, that in picking up and relocating the packet this way, I am perhaps taking a packet that was destined for some interface acceleration (such as offlined checksumming and the like) and placing it on an interface queue that has no such optimizations. Still more research required, but I see the problem now. -J

2 1

IP protocol 94
by R P 03 May '17

03 May '17

Hi there Long ago the AMPRNET was defined that both IP PID 94 and 4 was working ? What is situation today ? will it work with PID94 ? if possible may someone explain why we moved to PID4 ? as at this period I wasnt active with the AMPRNet Thanks for any info Ronen - 4Z4ZQ http://www.ronen.org 2) Why there is no option to add attachment (or graphics ) to the list ? is it because of Disk space ? etc ? from time to time it is usefull to have a screen capture of log of network related issues Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

3 2

router stats
by Brian Kantor 03 May '17

03 May '17

The ipip router at UCSD is not very busy (99% idle), but I am surprised at the number of dropped packets. It's higher than I would have hoped, suggesting there are a significant number of misconfigured routers on the network. - Brian ------------------------------------------------------------------ started at Tue May 2 20:49:25 2017 snapshot at Tue May 2 22:00:00 2017 uptime: 0+01:10:35 (4235 seconds) idle: 4194.615196 secs (99%) packets/bytes ---------/--------- 181908/50252930 ipip encapped input 170575/45757610 forwarded out unencapsulated 1/56 dropped: no source gateway 1666210/125325363 unencapsulated input 1666196/125324029 encapped out 0/0 dropped: no destination gateway 5994/447291 dropped: encap to encap 0/0 ttl exceeded 0/0 icmp sent 0/0 dropped: packet too large 0/0 dropped: zero outer source address 0/0 dropped: broadcast outer destination address 0/0 dropped: packet too short 0/0 dropped: zero inner source address 481/66757 dropped: broadcast inner destination address 13/676 dropped: multicast inner destination address 4781/337160 dropped: non-44 inner source address 0/0 dropped: embedded encap protocol 35/1400 dropped: ip_len > MTU and DF 0/0 dropped: ip_len != packet size 0/0 dropped: output packet too short 0/0 dropped: output packet too long 4181/347878 dropped: output blocked by firewall 1/40 dropped: kernel send error 0/0 dropped: multicast inner source address 1171/1756463 outgoing encapped IPIP packet will be fragmented by kernel 2019413 route lookups took 1782499 microseconds (0.88 usec/lookup) 2 route table updates took 0.008852 seconds (4 msec each avg)

3 4

Re: [44net] amprgw routing
by Rob Janssen 02 May '17

02 May '17

> - Are you saying that some AMPRNet OPs simply forward packets to their > WAN interface...WITH INVALID SRC IPs from their 44.0.0.0/8 RANGE?!?! Some do that, yes. The SRC IPs are not invalid but they are not their allocated IP from their ISP. Some poor ISPs allow that (lack of BCP38 source address filtering) However, the reason we are on the IPIP network is to allow others that are there to communicate with us without doing that. They can send their traffic in a proper IPIP tunnel. That would not be possible when we were only on BGP. Rob

2 1

Re: [44net] amprgw routing
by Rob Janssen 02 May '17

02 May '17

> There are actually > several instances where there is an encap route for a /16 and > then there are some /28s or /29s nested inside it. > BGP-only subnets aren't in the encap file. Our BGP-routed /16 is in the encap file as well, for compatibility with gateway stations that cannot send their net-44 traffic over internet due to source address filtering, or that are otherwise configured in such a way that net-44 traffic is never sent to internet directly. So we are one of those /16 networks with several small networks and single addresses inside it routed to different gateways. I don't know if the other instances are a result of the same setup. Good to hear that those are properly handled. Rob

2 1

Re: [44net] amprgw routing
by Rob Janssen 02 May '17

02 May '17

> The delay is entirely caused by clearing the array. I'm using 'bzero()' > to do that, as that's the fastest way I know of to zero an existing > array, but it still takes 25ms to zero a vector of 16 million shorts. > (Stepping through it with a for loop takes roughly 5 times as long.) Well this is where you could gain some time using the mmap, depending on various factors. When you do a fresh mmap of /dev/zero (or ANON) every time you need a new clear array, that will execute much quicker than clearing all that space, because in fact it is only setting up some page table entries that all point to the same already zeroed memory block. Then, when you start populating it of course you lose some of that advantage as each write into a page causes a page fault and a new memory block being allocated and zeroed and inserted into the page table. Only experimentation can show what the total time of the mmap + page COW operations is when compared to the bzero. It will depend on the density of the routed AMPRnet space. So, you would change the array[2][2**24] into a *array[2] (2 pointers to 16M entries) and mmap/munmap them every time you need them cleared. Rob

3 2

Re: [44net] amprgw routing
by Rob Janssen 02 May '17

02 May '17

> Deletions zero the corresponding entries in the addrs table, so if the > deletion count was non-zero, then when you're through deleting all the > expired entries, you run through the subnets table and load the remaining > routes into the addr table. Ok that sounds good, it should save a lot of time because most of the table is zero and never touched. I presume you do the reloading in order of decreasing subnet size so "nested" subnets are properly handled. (of course nested subnets primarily occur in the case of BGP routed networks and in that case it does not matter too much because the traffic is not supposed to go via amprgw anyway) Rob

2 1

Re: [44net] amprgw routing
by Rob Janssen 02 May '17

02 May '17

> Replacing the earlier sequential search through the routing > table with a binary search has significantly sped up lookups, > which can happen up to twice per packet forwarded (once for > source address, once for destination address). With "only" 16 million addresses in AMPRnet, why don't you use a 16-million entry array holding the next hop for each IP in 44.x.x.x or zero for those addresses that have no tunnel? Then you only need a single index operation to get the next hop for a packet. That requires 64MB of memory to store, hardly a significant amount today. And it can double-up as the filter to forward traffic only to/from registered addresses. Of course the update operation becomes more expensive, but it could probably be done in-place without disrupting packet forwarding. Or you could build a second table and then switch to it after the build is complete (requiring 128MB). Rob

6 8

Re: [44net] amprgw routing
by Rob Janssen 02 May '17

02 May '17

> Using a simple global array to be the list of addresses and pointers, > full load time went from about 3ms to 15ms. But it works just fine and > the lookups are so fast the microsecond timer registers zero. Great! I would think that the gain in efficiency of the routing more than offsets the extra processing for setup. You could consider making it multithreaded but I don't think anyone would notice an occasional 15ms delay and/or some drops. On our radio network such behaviour is quite normal. Another possibility would be to first scan for the "common case" of all subnets and gateways remaining the same but only the endpoint address of one or two gateways changing, and in that case omit the entire table setup and only patch the nexthop addresses of those gateways. Rob

3 4

"Sub-routing" from BGP Subnet
by Phil Pacier 02 May '17

02 May '17

Hello all, and thank you for your assistance. I have 44.10.10.0/24 allocated and announced via BGP. The subnet terminates to an Ubuntu server in a data center. I want to allocate addresses from this subnet via tunnels to other locations. For example, I would like to assign an address or a block of addresses to my home location (Cisco 1900 router) from this subnet. Is this possible, or do I need to look at a different option? Thank you! -- 73 de Phil Pacier, AD6NH APRS Tier2 Network Coordinator http://www.aprs2.net

4 3

amprgw routing
by Brian Kantor 01 May '17

01 May '17

I've made some changes to the amprgw routing mechanism. Replacing the earlier sequential search through the routing table with a binary search has significantly sped up lookups, which can happen up to twice per packet forwarded (once for source address, once for destination address). Three times an hour, a background process fetches the encap routing table from the portal, and if it has changed, signals the router process to update its routing table. The routing table update seems to take about 3 msec during which packets can't be looked up and so are not forwarded. This fetch also updates the data source for the rip sender, so you'll receive updates more quickly now. - Brian

3 5

Re: [44net] amprgw routing
by Rob Janssen 01 May '17

01 May '17

> I think the most efficient technique is to make the per-address lookup > table an mmap'd array of pointers to entries in the existing route table. > That makes it effectively addrtable[2][2**24], right? Yes. Of course a single pointer would be 8 bytes when it is compiled for 64 bits, but it would not need to be. When your existing route table is an array rather than a collection of malloc'ed objects linked by pointers, the "pointer" from the address lookup table into the route table could be the smaller index into the route table (that would easily fit in an unsigned short integer, allowing for 65535 gateways). Or, in 32 bit mode a simple pointer can be used (4 bytes per entry). Rob

2 2

Re: [44net] amprgw routing
by Rob Janssen 01 May '17

01 May '17

> You're absolutely right. I dropped some decimal places. Thanks! However, > gateway addresses don't fit in a byte, they're stored in an unsigned long, > which is 4 bytes each. 4 * 16 million, right? And I think you need > counters and flags. So it's an array of structs of some modest size each. My estimate of 128MB was based on having 4 bytes per entry and 2 tables for convenient updating (update one table then toggle a single indicator or pointer to make the updated table active). Of course when you require more bytes per entry the table will expand, but 8-16 bytes per entry should still fit comfortably in a modern machine. > But I see a complication: You will have to have n entries per route, > which will make loading the table a little less straightforward. Well, searching a datastructure for the correct route isn't straightforward either... remember when there is a tunnel to e.g. 44.137.0.0/16 and another one to 44.137.1.80/28 (an example from the current table) then any traffic to 44.137.1.81 should go to the tunnel for 44.137.1.80/28, not something that you can easily do with a binary search. However, a lookup in the table populated with entries for 44.137.0.0/16 and then overwritten with entries for 44.137.1.80/28 is easy. It will find the correct gateway with a single array index operation. So you only need to build the table starting from the subnets sorted by number of subnet bits to get it right. Indeed it is best to make the program multithreaded, or you could put the lookup table in shared memory and have a process doing the routing and another process doing the updating. I would still opt for having a "current" and a "next" table where the routing code always has a working table and the switch to the next version is instaneous. Of course you can also do a quick check before starting the laborious update process, to see if the new encap table is different from the previous one. Rob

2 2

Re: [44net] amprgw routing
by Rob Janssen 01 May '17

01 May '17

> My estimate of 128MB was based on having 4 bytes per entry and 2 tables for > convenient updating (update one table then toggle a single indicator or pointer > to make the updated table active). > Of course when you require more bytes per entry the table will expand, but > 8-16 bytes per entry should still fit comfortably in a modern machine. Another possibility would be to have a 16-million entry array of short integers holding a "gateway number" (starting at 1) for each IP address, and a separate table of gateways holding all the other info you want to keep per gateway. (e.g. counters) Then the processing of a packet would first index the destination IP in the first array, retrieving the gateway number (0 means drop the packet), then use that number as an index in the gateway table to access the per-gateway data including the endpoint address and the counters. This would require only slightly more than 32MB of memory for the tables, which should be no problem without any tricks. Rob

1 0

Re: [44net] amprgw routing
by Rob Janssen 01 May '17

01 May '17

> 128MB is only 3% of 4GB. What would be the problem reserving that for a lookup table? BTW, a nice trick for such tables is to do a mmap of /dev/zero with the proper size as a starting point, then write only the entries that are nonzero. That way the vast spaces that are only zeroes will not occupy physical memory, and when they are read by the forwarding code they read back as zeroes. Linux also has a "|MAP_ANONYMOUS" flag to obtain the same result, I don't know if BSD has that. |Rob

2 1

Re: [44net] amprgw routing
by Rob Janssen 01 May '17

01 May '17

> Interesting concept. Someday if we have enough memory I may try it, but > right now amprgw (an old machine) has only 4 GB of memory. It'd die swapping. 128MB is only 3% of 4GB. What would be the problem reserving that for a lookup table? Rob

2 1

Re: [44net] Shared block lists (was: portal down)
by Tom Hayward 01 May '17

01 May '17

On Sun, Apr 30, 2017 at 5:31 AM, Marc <monsieurmarc(a)btinternet.com> wrote: > Maybe we should start sharing block lists. Marc, HamWAN has a public blacklist system. Feel free to subscribe to it. It does not publish a full list, but rather sends addresses one by one, instantly*, as they are blocked. *It takes about 1.5 seconds for report of a hack attempt to propagate to our logging system, pass analysis, and be published to our edge routers' firewall. Here is the code behind the system (including a Mikrotik script you can use to subscribe): https://github.com/kd7lxl/blacklist-service Anything blocked by the HamWAN network will be published here: http://monitoring.hamwan.net/blacklist If it seems like it's not responding, that's normal. It is an HTTP longpoll service, so it will hang until there is data to be published, then that data is sent immediately. This mechanism allows pushing data (in this case, a blacklisted address) to a Mikrotik router without having to store admin credentials of that router on the blacklist system. Since it uses a standard protocol, it can be adapted for other platforms. Tom KD7LXL

1 0

amprgw router statistics
by Brian Kantor 30 Apr '17

30 Apr '17

As I've mentioned, I'm now logging statistics for the amprgw router. I could make these available on a web site, but I'm hesitant to do so without consensus from the community because the per-gateway stats have the side effect of revealing what subnet goes to what gateway, thus giving the bad guys more insight into how the AMPRNet-Internet gateway works and what hosts to impersonate to inject bad packets into the network. A sample of the statistics file is below. What do you folks think about making this available? - Brian started at Sat Apr 29 10:15:37 2017 snapshot at Sat Apr 29 10:45:00 2017 uptime: 0+00:29:23 (1763 seconds) packets/bytes ---------/--------- 121781/76089093 ipip encapped input 117631/73371842 forwarded out 0/0 no source gateway 467445/48802372 raw input 467434/48801678 encapped out 0/0 no destination gateway 2646/175516 encap to encap dropped 7692 discarded 0 TTL exceeded 0 ICMP sent 615 routes loaded (gateway counters cleared) 1486 seconds ago at Sat Apr 29 10:20:14 2017 entry subnet encap gateway outpkts outbytes inpkts inbytes ----- ------------------- ----- ---------------- --------- --------- --------- --------- 0 44.0.0.1/32 ipip 169.228.66.251 2 175 0 0 [etc]

7 19

portal down
by Brian Kantor 30 Apr '17

30 Apr '17

The portal has apparently crashed. I have no way to remotely restart it, so it'll probably be down all night until Chris wakes up and can take a look at it. - Brian

10 12

amprgw and IGMP and ICMP
by Brian Kantor 28 Apr '17

28 Apr '17

Recently I noticed people sending IGMP protocol packets to amprgw, which discards them (as it does for all multicast destinations sent to it). I don't think I'm going to write the necessary code to handle group membership, so dropping the packet is probably the best thing to do. Amprgw currently does NOT send 'destination unreachable' ICMP packets, including 'protocol unreachable', because those should be rate limited which makes coding the necessary response mechanism somewhat complicated. (True, I could steal the necessary code from the FreeBSD kernel and adapt it, but that's a lot of work. Maybe someday.) And I also don't want to use up encap bandwidth sending ICMP back to the AMPR hosts. The only ICMP that amprgw currently will originate is TIMXCEED when an encapped packet's TTL reaches zero, so that 'traceroute' will work. - Brian

2 1

Re: [44net] Gateway 77.138.34.39 (MikroTik discovery protocol)
by Rob Janssen 28 Apr '17

28 Apr '17

> That is the Mirkotik discovery protocol indeed. I struggled with this too at first until I found that you can enable/disable it on select interfaces. By default it sends and listens on all interfaces. I'll post a small tutorial on where to find and disable it per interface when I arrive at work (unless someone beats me to it) > I also firewalled in&outbound that on all but my internal interfaces just to be extra certain. I would recomend everyone doing so too unless you need it for some reason on an external interface. > Like with Cisco's CDP or Juniper's LLDP, you normally don't need it on external interfaces. Well, actually it would not be so bad to run this, and implement a receiver program on amprgw and other gateways. It provides useful info about what is at the other end of the tunnel, including the IP address of the router, software version, identity, etc. When everyone would be running this, you would have an immediate overview about which tunnels are alive, etc. A bit problematic could be that the router likely sends all packets at the same time and thus some 400 packets are queued for output at once, clogging up the internet interface. Rob

1 0

amprgw stats
by Brian Kantor 28 Apr '17

28 Apr '17

I've spent the last few hours adding some instrumentation (various counters) to the ipip daemon. Here's a sample of some of the data I now have available. This is a work in progress. The counters are packets/bytes. - Brian started at Thu Apr 27 22:51:19 2017 uptime: 0+00:08:41 15940/8895013 encapped input 13516/8414203 forwarded out 0/0 no source gateway 158252/9266766 raw input 159062/9316591 encapped out 0/0 no destination gateway 1613 discarded 0 ttlexceeded 614 routes (614 ipip, 0 udpip) loaded 521 seconds ago at Thu Apr 27 22:51:19 2017

2 4

Gateway 77.138.34.39
by Brian Kantor 28 Apr '17

28 Apr '17

Once a minute, at 8 seconds past the minute, gateway 77.138.34.39 sends an encapped UDP packet to the amprgw router that has a zero inner source address and an all-ones inner destination address. The payload length is 94 bytes and the source and destination ports are both 5678. The periodicity suggests that it's some process that runs every minute (out of crontab?) and takes about 8 seconds to complete. There is a list of things port 5678 may be used for at http://www.speedguide.net/port.php?port=5678 This may be Mikrotik Neighbor Discovery protocol. Here's a log record of one such packet: Apr 27 17:02:08 <local0.info> amprgw ipipd[22702]: ISRC0: len 122, os 77.138.34.39, od 169.228.66.251, is 0.0.0.0, id 255.255.255.255, ttl 64, proto 17 And here's a tcpdump of one: 17:06:08.419945 IP (tos 0x0, ttl 242, id 36314, offset 0, flags [none], proto IPIP (4), length 142) 77.138.34.39 > 169.228.66.251: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 122) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 94 The portal record shows that this gateway belongs to Ronen Pinchuk [4Z4ZQ]. Ronen, when you have a few spare minutes, could you look at your gateway and see if you can stop this from happening? - Brian

6 10

Re: [44net] Peculiar packet
by Jeremy Cooper 28 Apr '17

28 Apr '17

This is my gateway. I'll shut it down until I can figure out what is happening. I run FreeBSD and 44ripd, so that's why I am unusual. Someone did indeed try a very aggressive portscan from a very diverse set of hosts against me recently: Apr 26 21:28:33 bbs kernel: Limiting closed port RST response from 402 to 200 packets/sec Apr 26 21:31:45 bbs kernel: Limiting closed port RST response from 208 to 200 packets/sec Apr 26 21:31:48 bbs kernel: Limiting closed port RST response from 395 to 200 packets/sec -J > On Apr 26, 2017, at 20:30, Brian Kantor <Brian(a)UCSD.Edu> wrote: > > A few times a minute, a host claiming to be ke6jjj-8 (44.4.39.8) > is sending an encapped packet that is peculiar: it is either 40 or 44 > ...

3 5

minor RIP change
by Brian Kantor 28 Apr '17

28 Apr '17

I've implemented a new faster gateway search algorithm for the ipip daemon (it looks up what gateway a given packet is to be sent to). This required that the routes be stored in the global routing table in ascending order, which is opposite from before, so the order of routes in the RIP packets has also reversed. I don't think this matters to anything but I thought I'd better let you folks know just in case something started behaving oddly a few minutes ago. - Brian

2 2

Peculiar packet
by Brian Kantor 27 Apr '17

27 Apr '17

A few times a minute, a host claiming to be ke6jjj-8 (44.4.39.8) is sending an encapped packet that is peculiar: it is either 40 or 44 bytes long, but the length field in the IP header is set to a varying but very large packetsize (for example, 61,683 bytes) and the Don'tFragment bit is set so the amprgw IP kernel sending routine can't break it up into MTU-sized fragments - thus it gets a transmit failure and isn't sent anywhere. The inner source is always 44.4.39.8, but the destination varies a lot. I'm completely puzzled by this: I don't know how any common operating system would be generating such a packet. I can see how a naive IP implementation might have a problem when receiving a packet that is relatively small but claims to be large. Does anyone know: is this a deliberate attempt to sabotage the destination host? - Brian

2 3

rip sender
by Bill Vodall 26 Apr '17

26 Apr '17

> the rip sender; Is there any tool for doing local Rip packet generation similar to the main AMPRNet one? Perhaps Github or ? I'd like to use it for testing and, prior to opening up with the official system, building both local and community 44-net subnets. 73 and thanks.. Bill, WA7NWP

2 2

Subnets
by Tom Hayward 26 Apr '17

26 Apr '17

How do you add a subnet to a gateway? I have a /24 assigned to me and I want to use a /32 of it with an IPIP gateway. I added the gateway in the portal. Then when I went to add the network, the /24 is listed in the dropdown but I can't figure out how to add the network with a larger prefix. I don't want the whole /24 to route through this one gateway. Tom KD7LXL

3 4

Re: [44net] Subnets
by Rob Janssen 26 Apr '17

26 Apr '17

> How do you add a subnet to a gateway? I have a /24 assigned to me and > I want to use a /32 of it with an IPIP gateway. I added the gateway in > the portal. Then when I went to add the network, the /24 is listed in > the dropdown but I can't figure out how to add the network with a > larger prefix. I don't want the whole /24 to route through this one > gateway. That cannot be done. You can only gateway registered subnets. You would have to get the /32 assigned to you as well, and I think that will be rejected when the /24 already is of the type "End user". Maybe it can be done manually by one of the portal admins.... Rob

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net