44net March 2020

44net@mailman.ampr.org

21 participants
29 discussions

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

16 Mar '20

> * Some of you query the NTP with your Public IP thru AMPRGW instead of directly to me thru the mesh (just a note to make your SRC IP an AMPR address, not your Public IP - I may disable your access thru AMPGW in the future, as it's announced as "AMPR-only") Unfortunately it is quite common for gateway stations to send tunneled traffic towards 44net addresses (via IPIP) with a public IP as the source. I normally block all such traffic, except when the public IP is the gateway public address (as I got tired of trying to reach sysops where this error was present). People *should really use* proper source address selection and policy routing and NOT send tunnel traffic with other than 44net traffic (both source and destination) inside it to any gateway station except by prior agreement. (e.g. AMPRGW can send traffic from a 44net address to public destination addresses, and so can some gateways) To make life easier, DO NOT TRY to setup a gateway on the same system where your applications are also running, unless you have good knowledge of networking configuration and know about such concepts as policy routing (ip route rule, multiple route tables) and setting a preferred source address in a route. When you use a separate router and application machine, such errors are much less likely to occur, and configuring the firewall is also much easier. Get a separate Pi or MikroTik or whatever to run your gateway, and then have a PC or another system to run your BBS or conference or whatever you want to run on AMPRnet! Rob

1 0

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

14 Mar '20

> Those with a dynamic address CAN participate as their public gateway > can now be a FQDN for their dynamic service. I have some within the > New York State subnet (44.68/16). The issue is that IPIP tunnels have to be validate with their external address for at least SOME security, and this means that when the address changes there is nothing else we can do than drop their packets until the change comes through the portal and RIP system. With a system that has those dynamic addresses connect only to one or two VPN routers in a secure manner (e.g. L2TP/IPsec) we would not have that problem. Also, those address changes would not be important to other systems on the network. Out of the 561 registered gateways, we only ever receive traffic only from 73 of them. (the others could be either inactive or not be sending traffic to the Netherlands) Their address changes would not be important to us. Rob

1 0

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

14 Mar '20

> The spoofing is happening on GRE too...GRE was first. But with the GRE/IPsec and L2TP/IPsec tunnels spoofing is impossible. Rob

1 0

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

14 Mar '20

For a long time now, I have been allowing IPIP only from registered gateways and disallowed nested IPIP. Indeed I have seen in the past that IPIP packets were sent with the intention of being forwarded through "allow trusted subnets" rules and then maybe back out to internet hosts that were targeted for DDoS or similar. When looking in the logs of those rules, I usually see dropped packets from hosts that are apparently on dynamic addresses and have changed address, but this change has not yet reached me through the ampr-rip announcements. However, there are indeed also instances of apparently unrelated intrusion attempts. It remains my position that we should change from this IPIP mesh to a more modern VPN system where stations with dynamic addresses can participate through a local VPN server that participates in a network that uses standard protocols to form a dedicated AMPRnet tunnel network with automatic routing, that can be used by standard equipment and can be made more resilient against unwanted use (e.g. by using GRE/IPsec and L2TP/IPsec tunnels instead of the traditional IPIP). However, I no longer want to beat a dead horse. We had the discussion a while ago but unfortunately it was then redirected onto a separate mailing list. Rob

2 1

Venezuela AmprNet
by Gabriel Medinas 14 Mar '20

14 Mar '20

Greetings to all the other colleagues and friends, I am Gabriel Medinas YV5KXE from Caracas, Venezuela. For years (20 years) I have been coordinator of the AmprNet network for Venezuela with assignment 44.152.0.0 / 16 trying to assign and maintain the network of radio amateurs on network 44. For some unknown reason, I do not have access to this coordination and I use this route to try to communicate with people who can help me restart the Amprnet network through my gateway in Caracas yv5kxe.org. and with the knowledge of the pass way of Brian Kantor, the communication has been more complicated for me. I have register in AmprNet Portal and have register my Gateway yv5kxe.org Jnos linux 2.0j, telnet port 2332, Convers, DXcluster, Netrom link USA (laxnet), Caracas City. I appreciate any help in solving this problem in the sense of being able to restore the service over the local networks of Packet Radio, CONV, and NetRom. Thank you. Gabriel YV5KXE 4M5G gmedinas.com

1 0

Hub_NA Changes
by Charles J. Hargrove 08 Mar '20

08 Mar '20

With the shutdown of the WA7V system after a long and dedicated stretch, Hub_NA of the WWconvers needed a new home. With the help of WA7V and testing with KD6OAT, Hub_NA is still functioning but with a new IP address of 44.68.41.2 (gw.n2nov.ampr.org) on port 3600. The software also has the capability to make use of IRC clients that we might get included in a future version of JNOS. All bbs sysops in North America are welcome to connect their chat clients and servers to Hub_NA and join the rest of the WWconvers network. There is plenty of room for specialized convers channels. For the 44Net allocations in NY State (44.68/16) I suggest a common channel of #4468 to chat among ourselves. -- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Nets 441.100/136.5 PL ARnewsline Broadcast Mon. @ 8:00PM NYC-ARECS Weekly Net Mon. @ 8:30PM http://www.nyc-arecs.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32 "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan

6 10

MTU standardization for tunnels?
by Rob Janssen 04 Mar '20

04 Mar '20

In our local network we have several different kinds of tunnels, with different header overhead. As the usual MTU on an internet connection is 1500 (the ethernet MTU), the typical MTU for an IPIP tunnel is 1480, for GRE it is 1476, for GRE6 it is 1454, etc. However, not everyone has a 1500 byte internet MTU. Some people have PPPoE connections to internet with MTU of typically 1492, sometimes 1480. So the effective MTU of the mentioned (and other) tunnel types becomes 8 or 20 bytes less. Some people get a fixed address subnet from their ISP and it is provided as some tunnel with an MTU of 1456 (quite common here). This results in a wide variety of MTU values in our network. Frequently issues arise for new connections where the chosen MTU for some tunnel turns out to be too large, and full-size packets are dropped. And in an environment where those tunneled packets encounter a point where the outer packet is too large for the interface MTU, the usual mechanism of returning "ICMP destination unreachable, fragmentation required" does not work very well, because the ICMP is returned to the router that encapsulated the packet, not the original source of the traffic. And I have never seen an encapsulating router that translated the ICMP to a new ICMP packet referring to the inner addresses and sent it back to the original source. Also, there are sometimes issues when routes are changed by BGP. Of course many routers have TCP MSS clamping configured where the TCP MSS is reduced whenever the TCP SYN passes through a place with lower MTU, but this happens only on the initial connection setup. When the MTU later reduces due to a route change, this still results in failure of the connection. I wonder if other gateway operators have done something to alleviate this problem. Solutions that can be considered: - ignore DF. much of the current TCP traffic has DF (don't fragment) set, but this often causes communications to unnecessarily break. Without DF, packets would be fragmented as originally designed in the IP protocol. sending everything with DF and interpreting the ICMP responses is the mechanism behind "Path MTU discovery", which was designed to avoid fragmentation and the overhead it causes in routers. however, in the AMPRnet we seldomly encounter so much traffic that CPU loading of the routers is an issue. - standardize on a "default MTU" whenever we cannot offer a 1500 byte MTU. this does not solve all problems, but at least it solves some of them. Note that most routers fragment packets in a particularly inefficient way. When a packet a few bytes too large for the next hop has to be forwarded (and DF is not set), they will not split the packet in two approximately equal halves, but rather they send a first fragment as large as the outgoing MTU can accept, then a small fragment with the remainder of the original packet. This can result in multiple fragmentations along the way: first it has to be fragmented to fit into a 1480 byte MTU of an IPIP tunnel, then further on it has to be fragmented again to fit a GRE or L2TP/IPsec tunnel with smaller MTU. Whereas no further fragmentation would be required when it had been split in equal halves the first time. So, I wonder what others do (if anything) to avoid the problems caused by oversized packets and maybe to avoid fragmentation. For some time, I have experimented with "ignore DF" and of course it keeps traffic flowing, but it is unclear if it causes problems for some users. Next I would consider to use a standard MTU value on all tunnels, so there are mostly two MTU values left in the network: 1500 and that smaller, to be determined, value. Of course the MTU should not be so low that it causes terrible overhead. In the past we had a 256 byte MTU on AX.25 packet radio (or even 216 when it was over NET/ROM), but that causes a 15% header overhead and made us very unpopular amongst plain AX.25 users. Fortunately the WiFi links we use today allow 1500 byte packets :-) The minimal required MTU for IPv6 is 1280. The maximal MTU we can accomodate with the worst case tunnel headers is about 1400. So the preferable default MTU would be somewhere between 1280 and 1400. Are people even using 256-byte MTU links today? Would it be worth it to select an MTU value that can be more efficiently fragmented into 256-byte packets? Or is there another small MTU size that would be a candidate for such considerations? So again, I wonder what others have done w.r.t. this matter. Are admins of gateways that offer many kinds of different tunnels using a standard MTU in their systems, or just the max MTU that each tunnel technology allows? Do you copy DF from the inner to the outer packet in a tunnel? Do you ignore DF? What would be your position on establishing a standard MTU for tunnels, and what size would you propose? Rob PE1CHL

2 1

Auto Reply
by William Bressette 01 Mar '20

01 Mar '20

Auto Reply to Test EMail Titled [44net] Consider some tests

1 0

Consider some tests
by lleachii＠aol.com 01 Mar '20

01 Mar '20

All, I have a question to ponder again. In preparation for emergencies, I wanted to consider some of the following. - Passing traffic thru another GW, we can use the test/example subnet - If AMPRGW at USCD is unreachable, could we have other capable devices that elect between themselves and announce the routes from Chris' server? - Can we test the redundancy of Chris' route server from whom they elect and receive - I'm not sure if anyone is doing AX.25 to IP or vice versa; but I would like to try - I'm curious if anyone has compiled kissattach and all utilities compiled; etc. in OpenWrt to connect a TNC and radio - I want to do an end-to-end test (I recall someone offered me a makefile for some libraries) - I want to migrate my base APRS radio to the router. I recall I have libax25 compiled... 73, - Lynwood KB3VWG

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net March 2020