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@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 ...
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@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'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.
"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
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
"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
-
Brian Kantor -
Jeremy Cooper -
lleachii＠aol.com