Ответы Ping не возвращаются на почтовый сервер за брандмауэром Watchguard

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

1. В недавнем прошлом моя компания использовала другой внешний IP-адрес. Я сменил провайдера и, таким образом, изменил внешние IP-адреса. До изменения я мог пинговать с почтового сервера и в обязательном порядке получать ответы.

2. Когда я сменил брандмауэр, единственные изменения, которые я внес, - это правила, в которых конкретно упоминается внешний адрес. Физические соединения для внутренней сети не изменились. Структура правил брандмауэра не изменилась (по крайней мере, мне так казалось).

3. После смены брандмауэра и подключения к новым T1 я не получаю ping-ответы от 192.168.0.4, который является внутренним адресом почтового сервера. Я заметил, что исходящая почта стоит в очереди. В конце концов я установил второй сетевой интерфейс на 192.168.0.25, и как только я включил этот интерфейс, вся исходящая почта покидала очереди, а ответы ping возвращались на почтовый сервер.

4. Новые внешние IP-адреса были внесены в один из списков SORBS. Я получил исключение из черного списка через автоматическую форму для индивидуального внешнего адреса почтового сервера. Я обнаружил, что получение исключения работало для некоторых конфигураций, но некоторые серверы-получатели все равно отслеживали пакет обратно на адрес брандмауэра, который все еще находится в черном списке.

5. Теперь я обнаружил, что если я изменю правило брандмауэра, чтобы разрешить SMTP-выход из 192.168.0.4 вместо использования правила «отфильтрованного SMTP», которое работало ранее, моя исходящая почта будет видна на исключенном внешнем адресе, а серверы получателей, использующие SORBS, не Не блокирую почту.

6. Учитывая, что почта от 192.168.x.4 - это то, что я разрешаю на внешний IP-адрес, который не занесен в черный список, я отключил интерфейс, связанный с 192.168.0.25.

7. Почта теперь работает, но ответы на пинг теряются. Просмотр журналов брандмауэра показывает, что исходящий эхо-запрос разрешен, и любой IP-адрес в диапазоне 192.168.0. *, Кроме 192.168.0.4, получает ответы на эхо-запрос.

8. Включение интерфейса 192.168.0.25 приводит к тому, что эхо-запросы работают, но почта помещается в черный список пользователями SORBS. Я могу просто временно включить его для проверки связи, а затем снова отключить, но я бы предпочел решить проблему, чем просто постоянно ее решать.

Изменить: чтобы прояснить, единственная проблема, с которой мне нужна помощь, - это почему ответы Ping не возвращаются на 192.168.0.4 или почему сервер отбрасывает эти ответы. Мне не нужна помощь с SORBS или общими проблемами почтового сервера. Все проблемы, связанные с почтой, были решены в прошлом. Я просто ищу решение, позволяющее при необходимости пинговать с этого сервера на внешний адрес.

Пример поведения:

C:\>ping www.google.com

Pinging www.l.google.com [74.125.65.147] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ожидаемое поведение:

C:\>ping www.google.com

Pinging www.l.google.com [74.125.65.99] with 32 bytes of data:

Reply from 74.125.65.99: bytes=32 time=22ms TTL=52
Reply from 74.125.65.99: bytes=32 time=22ms TTL=52
Reply from 74.125.65.99: bytes=32 time=22ms TTL=52
Reply from 74.125.65.99: bytes=32 time=22ms TTL=52

Ping statistics for 74.125.65.99:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 22ms, Maximum = 22ms, Average = 22ms

У меня не было возможности обнюхать пакеты, но я заметил это

Routes:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.199   -               255.255.255.255 !H    0      -        0 -
192.168.0.200   -               255.255.255.255 !H    0      -      668 -

ПК с IP 0.200 не мог просматривать веб-страницы, получать обновления Windows или пинговать. Я изменил его IP, и теперь это возможно. Я не уверен, как очистить эти записи или почему они были добавлены в первую очередь. Я не вижу аналогичного оператора маршрута, блокирующего трафик в / из 0.4

Хорошо, я использовал NTOP для отслеживания входящих и исходящих запросов, и я получил это

296 байтов отправлено 0 байтов получено 4 отправленных эхо-запроса / 0 полученных эхо-ответов.

Думаю, это означает, что проблема в брандмауэре.