Thought maybe this is the place to let people know (as a courtesy I
suppose). I recently lost my static IP address (my bridge radio died
after 12+ years or so), looking at other solutions.
So in the meantime my existing IP address as noted in the encap.txt
and rip broadcasts will simply not respond to anything. No worries
about it being used by other entities, it's an IP on 'our system'
that no one else will ever use for a long time down the road.
I don't want to delete my entry in the portal, so I will try to get
some form of Dynamic DNS hostname in place as soon as possible, since
I am now using a DSL service as a temporary internet connection.
It might be a while, just saying.
Thanks for your understanding.
Maiko / VE4KLM
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.
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]
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
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
> 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
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
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
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
> ...
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
