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.
