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