- 44net - mailman.ardc.net

amprgw inbound traffic protocol analysis

by Brian Kantor

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

8 years, 1 month

2
1
0 0

Re: [44net] AMPRNet outage?

by Rob Janssen

> 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

8 years, 1 month

4
5
0 0

Re: [44net] AMPRNet outage?

by Rob Janssen

> 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

8 years, 1 month

6
13
0 0

Re: [44net] AMPR stats ...

by Rob Janssen

> 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

8 years, 1 month

1
0
0 0

Re: [44net] AMPRNet outage?

by Rob Janssen

> 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

8 years, 1 month

2
1
0 0

AMPR stats ...

by R P

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 ?

8 years, 1 month

3
9
0 0

Re: [44net] AMPRNet outage?

by Rob Janssen

> 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

8 years, 1 month

2
1
0 0

DNS Additions

by Craig Brauckmiller

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

8 years, 1 month

2
3
0 0

amprgw statistics

by Brian Kantor

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

8 years, 1 month

4
6
0 0

Re: [44net] the current worldwide Windows ransomware situation

by Rob Janssen

> 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

8 years, 1 month

4
4
0 0

some amprgw filtering statistics

by Brian Kantor

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

8 years, 1 month

7
13
0 0

how to route Mikrotik Gateway Commercial IP to the ISP and not to UCSD ?

by R P

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

8 years, 1 month

3
3
0 0

Re: [44net] some amprgw filtering statistics

by Charles

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

8 years, 1 month

1
0
0 0

Newbie Question

by Craig Brauckmiller

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

8 years, 1 month

2
1
0 0

VA co-ordinator

by Mark Phillips

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

8 years, 1 month

1
0
0 0

Re: [44net] the current worldwide Windows ransomware situation

by Rob Janssen

> 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

8 years, 1 month

1
0
0 0

Re: [44net] the current worldwide Windows ransomware situation

by Gabriel Medinas

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

8 years, 1 month

1
0
0 0

Re: [44net] the current worldwide Windows ransomware situation

by Gabriel Medinas

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 ?

8 years, 1 month

3
2
0 0

Re: [44net] the current worldwide Windows ransomware situation

by Rob Janssen

> 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

8 years, 1 month

2
1
0 0

the current worldwide Windows ransomware situation

by Brian Kantor

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 years, 1 month

8
12
0 0

Where is the statistics page ?

by R P

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

8 years, 1 month

1
0
0 0

router stats

by Brian Kantor

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

8 years, 1 month

4
13
0 0

Re: [44net] the current worldwide Windows ransomware situation

by Rob Janssen

> 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

8 years, 1 month

1
0
0 0

Re: [44net] Critical vulnerability in Intel Active Management Technology (CVE2017-5689)]

by Rob Janssen

> 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

8 years, 2 months

2
2
0 0

RIP44 send speed

by Brian Kantor

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

8 years, 2 months

1
0
0 0

Critical vulnerability in Intel Active Management Technology (CVE2017-5689)]

by Brian Kantor

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

8 years, 2 months

1
0
0 0

Re: [44net] unreachable gateways

by Rob Janssen

> 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

8 years, 2 months

3
3
0 0

AMPR + VyOS

by Miguel Rodriguez

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.

8 years, 2 months

4
12
0 0

Odd Features/Bug? ampr-ripd

by lleachii＠aol.com

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

8 years, 2 months

2
7
0 0

unreachable gateways

by Brian Kantor

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 ~

8 years, 2 months

1
0
0 0

Re: [44net] storm blocking

by Rob Janssen

> 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

8 years, 2 months

4
3
0 0

What records AMPR.ORG dns allow ?

by R P

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

8 years, 2 months

6
6
0 0

Re: [44net] storm blocking

by Rob Janssen

> 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

8 years, 2 months

2
1
0 0

Re: [44net] storm blocking

by Rob Janssen

> 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

8 years, 2 months

3
3
0 0

storm blocking

by Brian Kantor

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

8 years, 2 months

4
14
0 0

Re: [44net] iptables logging of IPIP

by Rob Janssen

> 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

8 years, 2 months

1
0
0 0

Re: [44net] iptables logging of IPIP

by Rob Janssen

> 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

8 years, 2 months

2
1
0 0

iptables logging of IPIP

by Rob Janssen

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

8 years, 2 months

2
1
0 0

Re: [44net] iptables logging of IPIP

by Rob Janssen

> 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

8 years, 2 months

1
0
0 0

gateway errors detail available

by Brian Kantor

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

8 years, 2 months

5
13
0 0

gateway and host bad packets report

by Brian Kantor

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

8 years, 2 months

6
12
0 0

Intrusion Detection and Prevention - LEDE and pfSense

by lleachii＠aol.com

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

8 years, 2 months

1
0
0 0

Image for Gateway with Raspberry Pi

by R P

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

8 years, 2 months

2
1
0 0

Re: [44net] gateway errors detail available

by Tim Osburn

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 >

8 years, 2 months

2
1
0 0

Re: [44net] gateway errors detail available

by Brian Kantor

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

8 years, 2 months

1
0
0 0

Test Server

by M6XCV (Mike)

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

8 years, 2 months

6
14
0 0

simple way to know when new encap file created ?

by R P

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

8 years, 2 months

3
3
0 0

probe responses

by Brian Kantor

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

8 years, 2 months

2
1
0 0

Greetings All I'm Online, Finally!

by Tom Cardinal

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

8 years, 2 months

3
2
0 0

Correct behaviour towards BGP subnet.

by M6XCV (Mike)

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

8 years, 2 months

1
0
0 0

storm

by Brian Kantor

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

8 years, 2 months

3
3
0 0

amprgw router bug fixed

by Brian Kantor

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

8 years, 2 months

1
0
0 0

Re: [44net] Gateway with 44 IP for testing

by Brian Kantor

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

8 years, 2 months

3
5
0 0

Gateway with 44 IP for testing

by Christopher S. Munz-Michielin

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

8 years, 2 months

5
10
0 0

misconfigured gateways

by Brian Kantor

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]

8 years, 2 months

1
0
0 0

Re: [44net] gateway and host bad packets report

by Rob Janssen

> 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

8 years, 2 months

2
1
0 0

Re: [44net] Peculiar packet

by Jeremy Cooper

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

8 years, 2 months

2
1
0 0

IP protocol 94

by R P

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

8 years, 2 months

3
2
0 0

router stats

by Brian Kantor

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)

8 years, 2 months

3
4
0 0

Re: [44net] amprgw routing

by Rob Janssen

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

8 years, 2 months

2
1
0 0

Re: [44net] amprgw routing

by Rob Janssen

> 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

8 years, 2 months

2
1
0 0

Re: [44net] amprgw routing

by Rob Janssen

> 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

8 years, 2 months

3
2
0 0

Re: [44net] amprgw routing

by Rob Janssen

> 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

8 years, 2 months

2
1
0 0

Re: [44net] amprgw routing

by Rob Janssen

> 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

8 years, 2 months

6
8
0 0

Re: [44net] amprgw routing

by Rob Janssen

> 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

8 years, 2 months

3
4
0 0

"Sub-routing" from BGP Subnet

by Phil Pacier

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

8 years, 2 months

4
3
0 0

amprgw routing

by Brian Kantor

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

8 years, 2 months

3
5
0 0

Re: [44net] amprgw routing

by Rob Janssen

> 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

8 years, 2 months

2
2
0 0

Re: [44net] amprgw routing

by Rob Janssen

> 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

8 years, 2 months

2
2
0 0

Re: [44net] amprgw routing

by Rob Janssen

> 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

8 years, 2 months

1
0
0 0

Re: [44net] amprgw routing

by Rob Janssen

> 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

8 years, 2 months

2
1
0 0

Re: [44net] amprgw routing

by Rob Janssen

> 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

8 years, 2 months

2
1
0 0

Re: [44net] Shared block lists (was: portal down)

by Tom Hayward

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

8 years, 2 months

1
0
0 0

amprgw router statistics

by Brian Kantor

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]

8 years, 2 months

7
19
0 0

portal down

by Brian Kantor

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

8 years, 2 months

10
12
0 0

amprgw and IGMP and ICMP

by Brian Kantor

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

8 years, 2 months

2
1
0 0

Re: [44net] Gateway 77.138.34.39 (MikroTik discovery protocol)

by Rob Janssen

> 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

8 years, 2 months

1
0
0 0

amprgw stats

by Brian Kantor

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

8 years, 2 months

2
4
0 0

Gateway 77.138.34.39

by Brian Kantor

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

8 years, 2 months

6
10
0 0

Re: [44net] Peculiar packet

by Jeremy Cooper

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

8 years, 2 months

3
5
0 0

minor RIP change

by Brian Kantor

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

8 years, 2 months

2
2
0 0

Peculiar packet

by Brian Kantor

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

8 years, 2 months

2
3
0 0

rip sender

by Bill Vodall

> 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

8 years, 2 months

2
2
0 0

Subnets

by Tom Hayward

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

8 years, 2 months

3
4
0 0

Re: [44net] Subnets

by Rob Janssen

> 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

8 years, 2 months

2
1
0 0

rip sender bug

by Brian Kantor

I just found and fixed another off-by-one error in the rip sender; this one had the effect of omitting the last route in each sent packet. Packets should hold up to 25 routes; they were being sent one route short at 24. Effectively, 25 subnets were missing from the rip transmissions. Oops. Sorry folks. - Brian

8 years, 2 months

1
0
0 0

Revised amprgw firewall rules

by Brian Kantor

These are the rules that route AMPRNet traffic to and from the ipip daemon (FreeBSD ipfw syntax): # # AMPR routing # # table(1) contains all registered/routable 44net addrs. # table(2) contains all registered gateways. # outbound encapsulated packets # should go only to registered gateways 00100 allow ipencap from me to 'table(2)' # inbound encapsulated packets # should only come from registered gateways 00200 allow ipencap from 'table(2)' to me # filter the 44net input side of things # valid destination addresses go to the router socket: ipipd 00300 divert 4444 ip from any to 'table(1)' in not dst-port 111,135-139,445,1025-1028,1900,2323,5353,7547 # filter the 44net output side of things 00400 allow ip from 'table(1)' to any Explanation: Preliminary filtering of incoming packets is done by the BSD ipfw firewall because it's easy to set up and very fast. Quite a bit more filtering is done by the ipip router daemon. Ipfw table 1 contains a list of the 44-net host addresses from the AMPR.ORG DNS zone file that are routable according to the encap file. Table 2 contains a list of the gateways from the encap file. Once an hour, the AMPR.ORG DNS zone file is fetched, normally at 10 minutes past the hour. Also hourly, the encap file is fetched from the portal, normally at 20 minutes past the hour. Whenever these files differ from their previous version, the ipfw tables are flushed and reloaded. When the encap file changes, the ipipd routing and the rip sender tables are also reloaded. Rule 100 allows the encapped packets out to registered gateways. Rule 200 allows encapped packets in only from registered gateway source addresses. Rule 300 diverts incoming IP to the ipipd encapsulating router if the destination address is for a registered/routed address and not for certain destination ports. Rule 400 allows outgoing IP with source addresses from registered/routed hosts. That's about all the filtering that can be done without looking inside the encapped packets, which the BSD firewall can't do. The ipipd daemon handles that, and is much stricter. - Brian

8 years, 2 months

3
6
0 0

Mikrotik router corrections

by Marius Petrescu

Hello, Since the appearance of the 44.0.0.1 route in RIP, some of you using the Mikrotik script may have noticed the disappearance of the RIP broadcasts and missing updates. This happens because of the creation of a alternative tunnel from your router to ampr-gw (ampr-169.228.66.251), which highjacks the normal ampr-gw tunnel. To correct this, follow the following steps: 1. under routing->prefix list create the following rules in the given order: chain ampr, prefix 44.0.0.1, prefix length 32 discard chain ampr, prefix 44.0.0.0/8, prefix length 8-32 accept chain ampr, prefix 0.0.0.0/0, prefix length 0-32 discard 2. under routing->rip->interfaces on your ucsd-gw set the 'ampr' prefix list as 'In Prefix List' 3. under interfaces find and delete interface ampr-169.228.66.251 4. under ip->routes find and delete the route to 44.0.0.1 via unknown 5. Optional: if you like to have 44.0.0.1 routed via tunnel, add a static route for 44.0.0.1 via interface ampr-gw. Marius, YO2LOJ

8 years, 2 months

3
5
0 0

Re: [44net] more gateway router follies

by Rob Janssen

> Belows IP's belong to SR3BBS gateway > which _IS OFF LINE_ for a long time! Then why is it in the table? Maybe it should again be considered to add a mandatory field to a gateway registration with a net-44 IP that should be pingable via the tunnel (e.g. the IP of the gateway itself) and run some very infrequent ping to that address from a monitoring system that is also on the tunnel network (not amprgw as some people apparently choose not to tunnel to that system). When e.g. one ping per hour is made and nothing is heard for 7 days or even more, the gateway can be marked down and removed from the encap.txt and RIP broadcast. The operator can then re-enable it via the portal. Rob

8 years, 2 months

3
2
0 0

Clarifications on the working of ampr-ripd and amprd for BGP announced gateways

by Marius Petrescu

Hi everybody, Just to clarify the issues related to "strange routes" appearing during the use of the rip daemons. Together with Jann, DG8NGN, we devised a solution for interoperating BGP announced 44 subnets with the current full mesh tunnel system. Initially I implemented the system for testing and proof of concept in the Mikrotik script v.3.0, and later in the ampr-ripd starting with version 1.16 and amprd version 1.5. Current versions are 1.16.3 for ampr-ripd (bug fixes and small enhancements) and 1.6 (bug fixes), please use these. Now to the idea behind it... Directly BGP announced gateways need to be reached, well, directly, as any other gateway. If we have a default route by which we could reach the BGP announced hosts (via your public IP, please don't use default routes via amprgw!), on installing a subnet route via the RIP daemon, e.g. 44.130.121.0/24 (it is a working test host) then the endpint 44.130.121.2 will also be routed via the tunnel, creating a loop, which is of course wrong. So ampr-ripd will detect your default gateway on the system, and set host routes for those direct gateways via the default gateway, if the RIP announced gateway has a 44 address. The detection of the default gateway is done by getting the route to 8.8.8.8 from your kernel tables. So you will end up with 2 routes for that entry, like: 44.130.121.0/24 via 44.130.121.2 dev tunl0 proto 44 onlink 44.130.121.2 via 192.168.1.1 dev eth0 proto 44 onlink. In this case, traffic for those subnets (in this case to 44.130.121.0/24) will be encapsulated and sent directly to 44.130.121.2, which is reachable via internet. It is expected that your system will nat those destinations to your public IP (which probably happens). If the detection of your default gateway is not correct, there is a parameter '-g' by which you can set your gateway IP by hand. Your internal addresses are not published, nor are the known to the gateway. It is a local lookup performed by the daemons. At the moment there are 4 functional gateways using this setup: 44.130.121.2, 44.130.122.2, 44.130.124.2 (as test systems) and 44.131.14.255 as a live setup. Reachable tests hosts are: 44.130.121.3, 44.130.121.130, 44.130.122.3, 44.130.122.130, 44.130.124.3, 44.130.124.130, and of course the end points. (44.130.121.2 runs amprd, 44.130.122.2 runs ampr-ripd and 44.130.124.2 runs the Mikrotik script). I hope this clarifies some of the questions that may arise. Have fun with the hobby, Marius, YO2LOJ

8 years, 2 months

2
1
0 0

more gateway router follies

by Brian Kantor

amprgw has recently logged several discarded packets like the following: Apr 24 18:44:03 <local0.info> amprgw ipipd[1518]: IBCAST: len 149, os 208.110.114.235, od 169.228.66.251, is 44.135.193.18, id 255.255.255.255, ttl 64, proto 17 encapped packets aren't supposed to send to the broadcast address (255.255.255.255). Apr 24 18:44:05 <local0.info> amprgw ipipd[1518]: 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 encapped packets aren't supposed to come from address 0.0.0.0 and encapped packets aren't supposed to send to the broadcast address (255.255.255.255). Apr 24 18:44:06 <local0.info> amprgw ipipd[1518]: TIMXCEED: len 52, os 85.234.252.133, od 169.228.66.251, is 44.165.53.254, id 224.0.0.9, ttl 1, proto 17 Looks like a routing loop on RIP packets. Ah well, variety is the spice of life... - Brian

8 years, 2 months

2
2
0 0

Re: [44net] rip sender change

by Rob Janssen

> Yes, it was intentionally dropped by the daemons. If it will be > reachable, I will update the code accordingly. I see it in the code now, just a couple of lines that can be deleted around line 1346: /* drop 44.0.0.1 */ if (rip->address == inet_addr("44.0.0.1")) { #ifdef HAVE_DEBUG if (debug && verbose) fprintf(stderr, " - rejected\n"); #endif return; } A temporary workaround until everyone has again updated ampr-ripd could be to announce 44.0.0.0/30 instead of 44.0.0.1/32 in the RIP sender. Rob

8 years, 2 months

1
0
0 0

Re: [44net] rip sender change

by Rob Janssen

> ampr-ripd does not set a route for 44.0.0.1, because that IP is not > reachable via the tunnel, only via the internet. Ah, it is treated as a special case? Brian has been working on that problem and now this route is announced again. (it had been deleted from the RIP broadcast before) I think it is added in the RIP sender, maybe it would be better to just register a portal entry so it is in encap.txt as well. Rob

8 years, 2 months

2
1
0 0

Re: [44net] more gateway router follies

by Rob Janssen

What you logged there are probably DHCP packets and private use of RIP, not the AMPR-RIP. Well, I do see a lot of those things here either... Recently I again worked on the filters and found e.g.: - router-sourced traffic with inner source address equal to the external IP (bad source address selection) - router sending some of the traffic outside of the tunnel (net-44 to net-44 traffic unencapsulated) the funny thing is that e.g. when pinging them it returns via the tunnel but when doing BGP the SYN ACKs from port 179 come outside the tunnel. when the sender had proper source address filtering at their ISP I would not see those packets at all. - of course still a lot of traffic with inner source address in RFC1918 range The first two above are blamed on "MikroTik VRF". I never use it, I always use a manual implementation using multiple routing tables, ip routing rules and maybe some mangle rules just as I am used to do on bare Linux, and I don't have those problems. Another group swears by VRF and they always have issues. As I believe MikroTik VRF is just an an automatic configuration of the mentioned features and it apparently does not work completely OK (and may need some help e.g. some extra mangle rule). I tried to get information on what really happens when you define a VRF, but I was unable to get answers. Rob

8 years, 2 months

1
0
0 0

Re: [44net] rip sender change

by Rob Janssen

> Yes, there was an off-by-one error in the count of entries in > the last packet. This error was not present when we were sending > in gateway major order, but was there in packet-major-order which > change I made early today. It has been corrected. Please check > the next RIP update and see if that fixes things. Ok, now I get the correct RIP packet :-) But the entry still does not appear in the route table... :-( IP Address: 44.2.2.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.2.2.0 (44.2.2.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 24.52.189.1 (24.52.189.1) Metric: 1 IP Address: 44.0.0.1, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.0.0.1 (44.0.0.1) Netmask: 255.255.255.255 (255.255.255.255) Next Hop: 169.228.66.251 (169.228.66.251) Metric: 1 44.0.0.0/8 via 213.222.29.193 dev eth0 src 44.137.0.1 44.2.2.0/24 via 24.52.189.1 dev tunl0 proto ampr-ripd metric 4 onlink So now I can continue local debugging to see what is going wrong... It fails both on the gateway (running latest ampr-ripd) and the Raspberry Pi (running earlier version). It does not appear in /var/lib/ampr-ripd/encap.txt either. Never assume there is only one bug... Rob

8 years, 2 months

2
1
0 0

Re: [44net] rip sender change

by Rob Janssen

> Yes, that's very much a mystery, because my tcpdump shows the route > being sent right after the one for 44.2.2.0/24. > [...] > AFI IPv4, 44.2.2.0/24, tag 0x0004, metric: 1, next-hop: 24.52.189.1 > AFI IPv4, 44.0.0.1/32, tag 0x0004, metric: 1, next-hop: 169.228.66.251 Could there be some length or count field that is off by one? I am tracing with wireshark (tshark). But ampr-ripd does not pick it up either. Rob

8 years, 2 months

3
4
0 0

Re: [44net] rip sender change

by Rob Janssen

> Because of concern that the rip sender might be sending > the pseudo-RIP packets to gateways faster than they can > receive them, I have changed the sending order. > ... > This has the effect of inserting a few milliseconds delay > between consecutive packets being sent to any one gateway, > which should give the receiving process more time to handle > the transmission. My main concern was not the receiving process, but the routers in front of the gateway system that (in my case) appeared to drop the tail end of the transmission, probably because of rate limiting or a queue overflow. Now, I get the 26 packets in about 150ms, which should solve that problem for anything but the slowest connections. Thanks! Unfortunately there is still no 44.0.0.1 route. I did a trace and confirm that the last packet received has the lowest addresses, but it ends with: IP Address: 44.2.7.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.2.7.0 (44.2.7.0) Netmask: 255.255.255.252 (255.255.255.252) Next Hop: 73.185.12.233 (73.185.12.233) Metric: 1 IP Address: 44.2.2.0, Metric: 1 Address Family: IP (2) Route Tag: 4 IP Address: 44.2.2.0 (44.2.2.0) Netmask: 255.255.255.0 (255.255.255.0) Next Hop: 24.52.189.1 (24.52.189.1) Metric: 1 Still some mystery somewhere :-) Rob

8 years, 2 months

2
1
0 0

rip sender change

by Brian Kantor

Because of concern that the rip sender might be sending the pseudo-RIP packets to gateways faster than they can receive them, I have changed the sending order. There are currently 26 packets per gateway per transmission. Instead of sending all packets to a gateway, then sending them to the next gateway, and so on, now each packet is sent to each individual gateway before the next packet is generated and sent. This has the effect of inserting a few milliseconds delay between consecutive packets being sent to any one gateway, which should give the receiving process more time to handle the transmission. The same total data is sent, so nobody should miss out on any routes. Thanks to Rob, PE1CHL for suggesting this technique. - Brian

8 years, 2 months

1
0
0 0

Re: [44net] Enabling traffic from inet to 44-net and vice versa

by Rob Janssen

> My understanding is that it's working correctly, because the icmp reply > is sent back to 2.238.198.249 inside the tunnel and towards the > amprnet router (169.228.66.251). > Unfortunately there's something wrong in the middle because no packets > are actually reaching 2.238.198.249 It must be something in your 2.238.198.249 system or the path to it, because I can ping 44.134.160.1 without problem from other internet hosts. Rob

8 years, 2 months

5
8
0 0

Open Source IP Address Management tool

by Bill Vodall

I don't remember seeing PHPIPAM mentioned here before. (And I searched...) https://phpipam.net/ Perhaps it would be useful - if not for the overall process for local or regional LANS. 73 Bill, WA7NWP

8 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net