“Default deny” rules в журнале
-
Добрый день.
Столкнулся с такой проблемой.
При попытке загрузок с распределенного набора серверов через определенное ПО в Интернете по открытым портам, в данном случае 80 и 443, в Status\System Logs\Firewall появляются записи:LAN Default deny rule IPv4 (1000000103) X..Y.16.80:55929 X.Y.251.132:443 TCP:PA
После этого соединение естественно закрывается.
Через IPtables все нормально.Что посоветуете?
-
@lucas1 said in “Default deny” rules в журнале:
1000000103
Здр
Странно , флаг push уже используется , когда соединение установленотакое ощущение, что сначала Вы устанавливаете соединение с одним хостом
а потом меняется хост назначения и все рушится
По умолчанию PFSense разрешает прохождение пакетов с установленным флагом SYN (для установления соединения) ,
а у Вас прилетает пакет с установленным флагом P ( и этого соединения нет в таблице состояний , и пакет блокируется)
попробуйте в правилах поиграться флагами в правилах (например , параметр any flags)
https://www.openbsd.org/faq/pf/filter.html
Раздел TCP Flags -
@Konstanti
Ставил в правиле All flags и sloppy state - не помогло. -
@lucas1 Здр
Вы можете показать pcap файл (захват на lan интерфейсе) , что происходит , когда устанавливается соединение с нужным хостом ?
И покажите пож правило , которое Вы используете для соединения с нужными хостами (с флагами по умолчанию и Any flags)
желательно , командой
pfctl -sr -
@lucas1
Попробуйте создать правило и поместить его на верх
Interface : Lan
Address family : IPv4
Protocol : TCP
Source : X..Y.16.80
Destination : X.Y.251.132
Destination port : 443 (или 80)
Flags : Set PSH
Out of PSH ACK -
@Konstanti
Правило: IP4* source этот хост .16.80, остальное все ALL, т.е. полный доступ в интернет.
И только по этому правилу пакеты проходят в интернет.
Флаги Set PSH и Out of PSH ACK - не помогло.
Кстати Out of - это маска флагов? -
@lucas1
Подозреваю это:
Sometimes log entries will be present that, while labeled with the “Default deny” rule, look like they belong to legitimate traffic. The most common example is seeing a connection blocked involving a web server.
This is likely due to a TCP FIN packet arriving after the connection’s state has been removed.
Но заставить пройти закачку не удается.Менял например System\Advanced\Firewall & NAT\Firewall Optimization Options
с Normal на все опции - вообще еще хуже, даже просто интернету.
И флаги в default deny rules появляются разные. Бывает эти правила вообще не появляются в журнале. Иногда даже проходит несколько процентов закачки. -
@lucas1 Гадать , что происходит , можно очень долго
Для первичного анализа желателен pcap файл tcpdump
и вывод правил командой pfctl -sr
еще желателен вывод команды ifconfig -m , чтобы видеть настройки сетевых интерфейсов .Повторю еще раз , просто так блокировать пакет с флагом P PF не станет . Пакеты через правила файрвола (в настройках по умолчанию) пробегают только один раз , когда проходит первый пакет. В случае TCP это пакет с флагом SYN . Потом уже соединение считается установленным и через правила файрвола пакеты этого соединения не прогоняются.
-
Дело в том, что dest хостов много может 10 или больше.
И блокируются пакеты с разными флагами. Мало того блокировок В ЖУРНАЛЕ может и не быть.Через Capture на LAN заметил :
Z.T.167.25.80 > X.Y.16.80.61628: Flags [.], cksum 0x1c65 (incorrect -> 0x32e5), seq 2890081:2891521, ack 321, win 237, length 1440: HTTP
15:58:44.146582 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 40181, offset 0, flags [DF], proto TCP (6), length 1480)
Z.T.167.25.80 > X.Y.16.80.61628: Flags [.], cksum 0x4659 (incorrect -> 0x5cd9), seq 2897281:2898721, ack 321, win 237, length 1440: HTTP
15:58:44.147002 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 40186, offset 0, flags [DF], proto TCP (6), length 1480)
Вероятно причина в этом, но как ее устранить.
-
@lucas1 Покажите вывод команды
ifconfig -mили в настройках включите
-
@lucas1
Если не поможет , то нужен pcap файл
Явно , что Z.T.167.25 шлет команду на сброс соединения (флаг R или F в пакете) , поэтому и удаляется соединение из таблицы состояний . А хост X.Y.16.80 не знает об этом -
@lucas1
https://docs.netgate.com/pfsense/en/latest/hardware/tuning-and-troubleshooting-network-cards.html -
@lucas1 said in “Default deny” rules в журнале:
cksum 0x1c65 (incorrect -> 0x32e5)
pfSense виртуализирована? Если да - hardware checksum offload отключали?
https://docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-proxmox.html -
@Konstanti
Включение опции Hardware Checksum Offloading частично помогло. Сейчас Default Deny в журнале вообще нет.
Запустил Wireshark на проблемном сервере.13 6.547774 IP.IP.IP.10 216.58.220.100 TCP 66 [TCP Dup ACK 9#2] 55643?80 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=19536649 TSecr=1347876636
14 8.532081 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP segment of a reassembled PDU]
15 8.781690 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP Retransmission] 55643?80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=16 TSval=19537208 TSecr=1347876636
16 9.033636 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP Retransmission] 55643?80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=16 TSval=19537271 TSecr=1347876636
17 9.453382 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP Retransmission] [TCP segment of a reassembled PDU]
18 9.537284 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP Retransmission] 55643?80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=16 TSval=19537397 TSecr=1347876636
19 10.544897 IP.IP.IP.10 216.58.220.100 TCP 82 [TCP Retransmission] 55643?80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=16 TSval=19537649 TSecr=1347876636
20 10.545286 216.58.220.100 IP.IP.IP.10 TCP 74 [TCP Spurious Retransmission] 80?55643 [SYN, ACK] Seq=0 Ack=1 Win=42540 Len=0 MSS=1402 SACK_PERM=1 TSval=1347883098 TSecr=19536021 WS=128Постоянные ошибки Dup, reassembled PDU, Retransmission.
Не понял почему Capture на самом PfSense такое не показывает.Виртуализирован проблемный сервер. Ну как проблемный - с этой частной проблемой.
-
@lucas1 said in “Default deny” rules в журнале:
216.58.220.100 IP.IP.IP.10
Показали бы все , проще было бы анализ проводить
Надо на pf захватить трафик и выгрузить его в виде pcap файла (не хотите его публично выложить , пришлите на почту)
и ifconfig -m желателен ( в очередной раз повторяю, сразу было бы видно , что и как у Вас на сетевых интерфейсах настроено )
а почему mss такой маленький ? через туннель какой-то устанавливается соединение ?
Какие доп пакеты установлены ?
PfblockerNG установлен ?
Недавно в англоязычной части форума рассматривали похожий случай , отключили этот пакет ,и все заработало -
@lucas1 said in “Default deny” rules в журнале:
Включение опции Hardware Checksum Offloading частично помогло.
Hardware Checksum Offloading надо выключить. Или вы описАлись?
-
@Konstanti
Pfblocker и Snort установлены. Snort и DNSBL выкл. - одинаково. IP - еще нет.
Без Hardware Checksum Offloading checked все выглядит еще хуже.
Не понял на форуме где найти адрес вашей почты. -
@lucas1
Что за железо? Что за гипер исп-ся? У меня на KVM при всех Disabled HW offloading на сетевых проблем НЕТ на 10 PVE.Если сервер умеет vt-d\ iommu - на время пробростьте полностью сетевую в ВМ. Если и при этом будет косяк - разбирайтесь с железом.
ЗЫ. А может ваше железо умеет и SR-IOV - тогда еще проще. -
@lucas1 said in “Default deny” rules в журнале:
Без Hardware Checksum Offloading checked все выглядит еще хуже.
Отключение Hardware Checksum Offloading вообще-то "золотой стандарт" при виртуализации pfSense с практически любым гипервизором.
Тут регулярно всплывают проблемы связанные с его неотключением, вплоть до не работающего банального port forward.
Странно, что у вас это не так.@lucas1 said in “Default deny” rules в журнале:
Не понял на форуме где найти адрес вашей почты.
Ее там нет. Виртуализацию использую, Но для pfSense - реальное железо.
Главный виртуализатор тут @werter -
@lucas1 Отключите пакеты и посмотрите , что будет
Адрес напишу в личку
