Thanks guys
Not sure why this would be happening on this system as I have much busier ones
that are fine but I will have a look next time it happens.
Regards
Michael Knill
On 7/10/20, 12:23 pm, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote:
Thanks Darrick,
If you have a very busy (network) system, you can set in your user.conf
--
CONNTRACK=65536
--
or some higher power of 2 ... that will survive a reboot. Though higher
values will use more RAM.
BTW, CONNTRACK is a firewall variable.
Lonnie
> On Oct 6, 2020, at 7:19 PM, darricklegacy <dhart...@djhsolutions.com>
wrote:
>
> Hi Michael,
>
> I have seen this error on our system from time to time. If you are on a
relatively busy network, you could exceed the 16384 value potentially. You can
echo a larger value to that setting in /proc/sys/net but it will not survive a
reboot.
>
> If you have a relatively small network, Lonnie is on the right track (pun
intented). You can check what's in the table by parsing /proc/net and looking
at ip_conntrack.
>
> Darrick
>
> On 10/6/20, 5:38 PM, "Lonnie Abelbeck" <li...@lonnie.abelbeck.com> wrote:
>
> Hi Michael,
>
> I have never personally witnessed this error, but I am aware it can
happen if the conntrack state table is full.
>
> By default CONNTRACK=16384 which sets the conntrack state table size.
>
> View the number states:
> System tab -> Firewall States
> --
>
> NNN Total Firewall States
> --
>
> Look to see what public TCP or UDP ports are exposed and see if
someone might be probing them.
>
> Possibly you have a BitTorrent running internally ? That can create a
lot of states.
>
> If you really have a super busy system there is some tuning you can
do, but I would look to see if you have some publicly exposed ports that can be
firewalled better.
>
> Lonnie
>
>
>
>
>
>> On Oct 6, 2020, at 4:50 PM, Michael Knill
<michael.kn...@ipcsolutions.com.au> wrote:
>>
>> Hi Group
>>
>> For the second morning in a row, my office system has been pretty much
unusable with the following in the logs:
>>
>> user.warn kernel: nf_conntrack: table full, dropping packet
>>
>> Is this a DoS attack?
>> Things are fine once rebooted. Surely this wouldn't be the case with a
DoS attack?
>>
>> Where should I test next?
>>
>> Thanks all.
>>
>> Regards
>
>
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
