27 Apr
2017
27 Apr
'17
2:42 a.m.
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
...
27 Apr
27 Apr
7:07 a.m.
New subject: Peculiar packet
No need to shut it down; no harm is being caused, but you should solve
the problem when you can as your TCP is behaving oddly.
I'm curious, what version of FreeBSD are you running? Amprgw is a FreeBSD
10.3 host and it doesn't do this as far as I can tell. It does not use
the in-kernel IPIP encapsulation though.
I wonder if we've uncovered a kernel encap bug? The normal FreeBSD
network stack is very well proven, but I don't think very many people
use the in-kernel IPIP encap.
You might want to consider some of the suggestions for tuning high-volume
hosts, such as limiting ICMP replies, adjusting tcp.msl, and so on.
Google for 'freebsd network tuning' for some helpful suggestions.
Rate limiting ICMP is probably a good place to start. Try sysctl
net.inet.icmp.icmplim=5
- Brian
On Wed, Apr 26, 2017 at 11:42:03PM -0700, Jeremy Cooper wrote:
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
>...
1:42 p.m.
New subject: Peculiar packet
I'm running FreeBSD 10.3 as well, but I am using the kernel IPIP
encapsulation courtesy of gif(4) interfaces. Here's my tunnel to amprgw:
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
options=80000<LINKSTATE>
tunnel inet 75.101.96.109 --> 169.228.66.251
inet 44.4.39.8 --> 44.0.0.1 netmask 0x0
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Ignore the inner netmask (0x0); the routing table on my host is set up so
that these interfaces basically run unnumbered. Here's a small snippet of
the 958 lines of my netstat -rn -f inet:
Destination Gateway Flags Netif Expire
default 75.101.96.1 UGS vlan0
44.0.0.1 link#8 UH gif0
44.2.2.0 link#430 UH gif421
44.2.2.0/24 gif421 U gif421
44.2.7.0 link#429 UH gif420
44.2.7.0/30 gif420 U gif420
44.2.10.0 link#428 UH gif419
44.2.10.0/29 gif419 U gif419
44.2.50.0 link#427 UH gif418
44.2.50.0/29 gif418 U gif418
44.4.2.152 link#426 UH gif417
44.4.2.152/29 gif417 U gif417
44.4.4.64 link#425 UH gif416
On Thu, 27 Apr 2017, Brian Kantor wrote:
I'm curious, what version of FreeBSD are you
running? Amprgw is a FreeBSD
10.3 host and it doesn't do this as far as I can tell. It does not use
the in-kernel IPIP encapsulation though.
9:56 p.m.
New subject: Peculiar packet
"No need to shut it down; no harm is being caused, but you should solve
the problem when you can as your TCP is behaving oddly."
Brian,
You do agree that:
- a packet stating it's x large in size
- traverses multiple routers over the Internet - with a DO NOT FRAGMENT BIT
- and is received and responded upon
- even thought the packet is bona facie: bogus, invalid and Martian
- and is proven to be magnitudes smaller than x size
- and how the packet was successful in receiving a reply is unknown
...I think he should block it.
- KB3VWG
10:16 p.m.
New subject: Peculiar packet
No, I disagree.
Only his encapped packet has the wrong size and DF bit set in it; the
outer IP header is correct. So only AMPR decapsulating routers will
see it. No Internet routers will look inside the inbound outer packet
and be in any way affected. Amprgw drops the decapsulated packet and
doesn't forward it back to the Internet. And there are only a few
such packets per hour. It's not a Martian: the inner source address
is correct for his subnet. These packets are replies to incoming TCP
connection requests that are being rejected.
Yes, he should fix it when he can but I don't think it's a big enough problem
to warrant shutting down the gateway.
Interestingly enough, as I was writing this reply, his gateway sent
an encapped packet that had a size mismatch and the TOS set to 0xb8
but no DF bit. First one of those I've seen. It was dropped.
Apr 27 19:00:21 <local0.info> amprgw ipipd[23186]: kernsend: len=440, ver=4 hl*4=20
tos=b8 len=8186 id=e790 off=0000 ttl=63 proto=17 cksum=dcc4 [UDP] 44.4.39.8:123 ->
184.105.139.112:48048
There's definitely something weird going on.
- Brian
On Thu, Apr 27, 2017 at 09:56:01PM -0400, lleachii--- via 44Net wrote:
You do agree that:
- a packet stating it's x large in size
- traverses multiple routers over the Internet - with a DO NOT FRAGMENT BIT
- and is received and responded upon
- even thought the packet is bona facie: bogus, invalid and Martian
- and is proven to be magnitudes smaller than x size
- and how the packet was successful in receiving a reply is unknown
...I think he should block it.
- KB3VWG
10:24 p.m.
New subject: Peculiar packet
"Yes, he should fix it when he can but I don't think it's a big enough
problem
to warrant shutting down the gateway...
There's definitely something weird going on."
Brian,
I wrote you off thread at the same time.
I agree. I meant only the type of packet (if possible).
- KB3VWG
2764
days inactive
2765
days old
5 comments
3 participants
participants (3)
-
Brian Kantor -
Jeremy Cooper -
lleachii＠aol.com