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