Почтовый сервер Dovecot/Postfix отвечает на [SYN] с помощью [RST, ACK], когда пользователь пытается подключиться (POP3). Скорее всего iptables?

В настоящее время я пытаюсь создать почтовый сервер, который позволит пользователям отправлять электронную почту, но не входить на сервер (POP3) или получать электронную почту с помощью своих клиентов Outlook. Ранее это было выполнимо, но перемещение сервера в его текущее местоположение сломало его. По понятным причинам, я подозреваю, что это брандмауэр вызывает проблемы.

Во-первых, вот как выглядело рукопожатие (или попытка), прежде чем я внес какие-либо изменения в брандмауэр:

почтовый сервер: 192.168.25.26клиент: 192.168.25.50

     Source     |     Destination     |   PROTO  |     INFO
192.168.25.50        192.168.25.26         TCP        50861 > pop3 [SYN] seq=0 win=65535 len=0
192.168.25.26        192.168.25.50         TCP        pop3 > 58601 [RST, ACK] seq=1 win=1 len=0
192.168.25.50        192.168.25.26         TCP        [TCP Retransmission] 58061 > pop3 [Syn] etc....

и танец [rst, ack], [tcp retransmission] происходит еще раз, прежде чем терпит неудачу.

Правила для брандмауэра (Cisco), касающиеся 192.168.25.26 и pop3, следующие:

внутри:

   source     |     destination     |        service     
     any           192.168.25.0/24          tcp/pop3
192.168.25.0/24          any                tcp/smtp
                  208.105.121.196

вне:

   source     |     destination     |        service     
     any           192.168.25.26            tcp/pop3
                        any                 tcp/smtp

Для меня это выглядит хорошо.

Чтобы быть уверенным, на почтовом сервере (Zentyal) я выполнил следующие команды:

(IP-таблицы были настроены ТЯЖЕЛЫМ. Я подозреваю, что проблема заключается здесь. Есть ли способ разрешить весь трафик, только для тестирования?)

sudo iptables -F
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

Тем не менее, до сих пор нет перспективы подключения. На этом этапе на почтовом сервере я выполнил команду:

telnet 127.0.0.1 110

и смог войти на почтовый сервер. С клиента внутри сети я запустил ту же команду, и мне сказали "сбой соединения".

После этих изменений, когда я пытаюсь "проверить настройки" в Outlook, вот как выглядит рукопожатие. Я заметил нечто особенное.

     Source     |     Destination     |   PROTO  |     INFO
192.168.25.50        192.168.25.26         TCP        apollo-status > pop3 [SYN] seq=0 win=65535 len=0
192.168.25.26        192.168.25.50         TCP        pop3 > apollo-status [RST, ACK] seq=1 win=1 len=0
192.168.25.50        192.168.25.26         TCP        [TCP Retransmission] apollo-status > pop3 [Syn] etc....

и он делает это в два раза больше, как в прошлый раз. На панели INFO теперь я вижу apollo-status вместо номера порта. Следующие два раза я запускал его, я видел npep_messaging и synapse соответственно. Я подозреваю, что это случайные порты, выбранные dovecot, потому что в dovecot.config я изменил прослушиватель по умолчанию на звездочку "*" из ранее указанного порта, который казался произвольным портом в 4000-х и не имел правил в брандмауэр.

Просто чтобы подтвердить, кажется, что порт, который он использует каждый раз, меняется в зависимости от (рекомендуемой) конфигурации. На петлевом интерфейсе порт 110 явно подключен к слушателю, но с другого компьютера он, кажется, закрыт.

Любая помощь на всех приветствуется. Я ломал голову над этим, и я надеюсь, что у сообщества serverfault будут некоторые новые идеи.

Спасибо!