Согласен. Может быть все что угодно НАТ - это один из возможных случаев.

Если "то слышно, то не слышно" значит где-то в правилах фаервола, НАТа иногда попадает в разрешенные правила, а иногда нет.

Отчет:

Every 2.0s: netstat -na | grep 5038 Thu Jan 10 11:10:56 2019

tcp 0 0 0.0.0.0:5038 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:41242 127.0.0.1:5038 TIME_WAIT
tcp 0 0 127.0.0.1:5038 127.0.0.1:40154 ESTABLISHED
tcp 0 0 127.0.0.1:40154 127.0.0.1:5038 ESTABLISHED
tcp 0 0 127.0.0.1:5038 127.0.0.1:40122 ...

Вполне допускаю некорректную работу самописного АМИ-клиента.
Но при этом наблюдал такие же подвисшие сессии с адреса 127.0.0.1 на 127.0.0.1 (Работал ФриПБХ).
Про tcpdump не подумал, нужно будет посмотреть.

Конфигурацию в плане tcp не трогал в системе.

Был тот, который был по умолчанию в фриПБХ. Увидел глюки, поставил более свежий.
Таки действительно, какой-то глюк. Смотрел в винде такого соединения не было, а нетстат в линуксе показал, что есть.

На 15-ом была такая же проблема.
Тестил проблему далее. Таки через некоторый таймаут сбрасывает. Помониторю еще.

Немного провел экспериментов.
Имеем:
1. Подключились с виндового клиента.
2. Рубанул коннект на роутере (правилами блокировки).
3. Отключил виндовый клиент.
4. АМИ не видит обрыва соединения и пуляет в буффер соединения далее.
5. Отключаю блокировку на роутере, разрешаю соединения.
6. Подключаю ...

Похоже, что проблема таки в подвисшем соединении, если есть второе от туда же. Осталось понять, почему оно виснет.

Это потеряное соединение. С той машины уже есть новое. Как его убить?
Кстати размер очереди там не меняется.

iotop в основном по нулям, но в моменты событий пишется в базу и логи.
Total DISK READ : 0.00 B/s | Total DISK WRITE : 536.42 K/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 289.74 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
23496 be/4 mysql 0.00 B/s 234.93 K/s 0.00 % 2.36 ...