Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    “Default deny” rules в журнале

    Scheduled Pinned Locked Moved Russian
    22 Posts 4 Posters 2.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      Konstanti @lucas1
      last edited by Konstanti

      @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

      L 1 Reply Last reply Reply Quote 0
      • L
        lucas1 @Konstanti
        last edited by

        @Konstanti
        Правило: IP4* source этот хост .16.80, остальное все ALL, т.е. полный доступ в интернет.
        И только по этому правилу пакеты проходят в интернет.
        Флаги Set PSH и Out of PSH ACK - не помогло.
        Кстати Out of - это маска флагов?

        L 1 Reply Last reply Reply Quote 0
        • L
          lucas1 @lucas1
          last edited by

          @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 появляются разные. Бывает эти правила вообще не появляются в журнале. Иногда даже проходит несколько процентов закачки.

          K 1 Reply Last reply Reply Quote 0
          • K
            Konstanti @lucas1
            last edited by

            @lucas1 Гадать , что происходит , можно очень долго
            Для первичного анализа желателен pcap файл tcpdump
            и вывод правил командой pfctl -sr
            еще желателен вывод команды ifconfig -m , чтобы видеть настройки сетевых интерфейсов .

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

            L 1 Reply Last reply Reply Quote 0
            • L
              lucas1 @Konstanti
              last edited by

              @Konstanti

              Дело в том, что 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)

              Вероятно причина в этом, но как ее устранить.

              K P 3 Replies Last reply Reply Quote 0
              • K
                Konstanti @lucas1
                last edited by

                @lucas1 Покажите вывод команды
                ifconfig -m

                или в настройках включите
                7416bf1e-e419-4d96-9383-42d59288a86d-image.png

                L 1 Reply Last reply Reply Quote 0
                • K
                  Konstanti @lucas1
                  last edited by Konstanti

                  @lucas1
                  Если не поможет , то нужен pcap файл
                  Явно , что Z.T.167.25 шлет команду на сброс соединения (флаг R или F в пакете) , поэтому и удаляется соединение из таблицы состояний . А хост X.Y.16.80 не знает об этом

                  1 Reply Last reply Reply Quote 0
                  • werterW
                    werter
                    last edited by

                    @lucas1
                    https://docs.netgate.com/pfsense/en/latest/hardware/tuning-and-troubleshooting-network-cards.html

                    1 Reply Last reply Reply Quote 0
                    • P
                      pigbrother @lucas1
                      last edited by

                      @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

                      1 Reply Last reply Reply Quote 0
                      • L
                        lucas1 @Konstanti
                        last edited by

                        @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 такое не показывает.

                        Виртуализирован проблемный сервер. Ну как проблемный - с этой частной проблемой.

                        K P 2 Replies Last reply Reply Quote 0
                        • K
                          Konstanti @lucas1
                          last edited by Konstanti

                          @lucas1 said in “Default deny” rules в журнале:

                          216.58.220.100 IP.IP.IP.10

                          Показали бы все , проще было бы анализ проводить

                          Надо на pf захватить трафик и выгрузить его в виде pcap файла (не хотите его публично выложить , пришлите на почту)
                          и ifconfig -m желателен ( в очередной раз повторяю, сразу было бы видно , что и как у Вас на сетевых интерфейсах настроено )
                          а почему mss такой маленький ? через туннель какой-то устанавливается соединение ?
                          Какие доп пакеты установлены ?
                          PfblockerNG установлен ?
                          Недавно в англоязычной части форума рассматривали похожий случай , отключили этот пакет ,и все заработало

                          L 1 Reply Last reply Reply Quote 0
                          • P
                            pigbrother @lucas1
                            last edited by

                            @lucas1 said in “Default deny” rules в журнале:

                            Включение опции Hardware Checksum Offloading частично помогло.

                            Hardware Checksum Offloading надо выключить. Или вы описАлись?

                            1 Reply Last reply Reply Quote 0
                            • L
                              lucas1 @Konstanti
                              last edited by

                              @Konstanti
                              Pfblocker и Snort установлены. Snort и DNSBL выкл. - одинаково. IP - еще нет.
                              Без Hardware Checksum Offloading checked все выглядит еще хуже.
                              Не понял на форуме где найти адрес вашей почты.

                              P K 2 Replies Last reply Reply Quote 0
                              • werterW
                                werter
                                last edited by

                                @lucas1
                                Что за железо? Что за гипер исп-ся? У меня на KVM при всех Disabled HW offloading на сетевых проблем НЕТ на 10 PVE.

                                Если сервер умеет vt-d\ iommu - на время пробростьте полностью сетевую в ВМ. Если и при этом будет косяк - разбирайтесь с железом.
                                ЗЫ. А может ваше железо умеет и SR-IOV - тогда еще проще.

                                1 Reply Last reply Reply Quote 0
                                • P
                                  pigbrother @lucas1
                                  last edited by pigbrother

                                  @lucas1 said in “Default deny” rules в журнале:

                                  Без Hardware Checksum Offloading checked все выглядит еще хуже.

                                  Отключение Hardware Checksum Offloading вообще-то "золотой стандарт" при виртуализации pfSense с практически любым гипервизором.
                                  Тут регулярно всплывают проблемы связанные с его неотключением, вплоть до не работающего банального port forward.
                                  Странно, что у вас это не так.

                                  @lucas1 said in “Default deny” rules в журнале:

                                  Не понял на форуме где найти адрес вашей почты.

                                  Ее там нет. Виртуализацию использую, Но для pfSense - реальное железо.
                                  Главный виртуализатор тут @werter

                                  1 Reply Last reply Reply Quote 0
                                  • K
                                    Konstanti @lucas1
                                    last edited by

                                    @lucas1 Отключите пакеты и посмотрите , что будет
                                    Адрес напишу в личку

                                    L 1 Reply Last reply Reply Quote 0
                                    • L
                                      lucas1 @Konstanti
                                      last edited by

                                      @Konstanti
                                      Выключал Pfblocker. останавливал Snort - результат тот же.
                                      Кстати выглядит сейчас так на сервере через Wireshark:

                                      7008","22.126605","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 6989#9] 52287 > 80 [ACK] Seq=316 Ack=4894561 Win=365568 Len=0"
                                      "7009","22.126646","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 6989#10] 52287 > 80 [ACK] Seq=316 Ack=4894561 Win=365568 Len=0"
                                      "7010","22.126795","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5245921 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7011","22.126844","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 6989#11] 52287 > 80 [ACK] Seq=316 Ack=4894561 Win=365568 Len=0"
                                      "7012","22.126879","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5247361 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7013","22.126923","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 6989#12] 52287 > 80 [ACK] Seq=316 Ack=4894561 Win=365568 Len=0"
                                      "7014","22.152374","dd.ddd.167.25","X.Y.16.80","TCP","1494","[TCP Out-Of-Order] 80 > 52287 [ACK] Seq=4894561 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7015","22.152499","X.Y.16.80","dd.ddd.167.25","TCP","54","52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
                                      "7016","22.152549","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5248801 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7017","22.152561","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5250241 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7018","22.152595","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#1] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
                                      "7019","22.152631","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#2] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
                                      "7020","22.152659","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5251681 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7021","22.152688","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#3] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
                                      "7022","22.152724","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5253121 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7023","22.152755","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#4] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
                                      "7024","22.152847","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5254561 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7025","22.152877","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#5] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
                                      "7026","22.152924","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5256001 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7027","22.152964","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#6] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
                                      "7028","22.153021","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5257441 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7029","22.153043","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7015#7] 52287 > 80 [ACK] Seq=316 Ack=4911841 Win=358400 Len=0"
                                      "7030","22.179272","dd.ddd.167.25","X.Y.16.80","TCP","1494","[TCP Out-Of-Order] 80 > 52287 [ACK] Seq=4911841 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7031","22.179384","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5258881 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7032","22.179417","X.Y.16.80","dd.ddd.167.25","TCP","54","52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
                                      "7033","22.179456","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5260321 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7034","22.179489","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#1] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
                                      "7035","22.179531","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5261761 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7036","22.179553","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#2] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
                                      "7037","22.179645","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5263201 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7038","22.179694","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#3] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
                                      "7039","22.179779","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5264641 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7040","22.179810","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#4] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
                                      "7041","22.179883","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5266081 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7042","22.179920","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#5] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
                                      "7043","22.180017","dd.ddd.167.25","X.Y.16.80","TCP","1494","80 > 52287 [ACK] Seq=5267521 Ack=316 Win=30336 Len=1440 [TCP segment of a reassembled PDU]"
                                      "7044","22.180041","X.Y.16.80","dd.ddd.167.25","TCP","54","[TCP Dup ACK 7032#6] 52287 > 80 [ACK] Seq=316 Ack=4927681 Win=348416 Len=0"
                                      "7045","22.439852","dd.ddd.167.25","X.Y.16.80","TCP","1494","[TCP Retransmission] 80 > 52287 [ACK] Seq=4927681 Ack=316 Win=30336 Len=1440"
                                      "7046","22.499467","X.Y.16.80","dd.ddd.167.25","TCP","54","52287 > 80 [ACK] Seq=316 Ack=4944961 Win=345600 Len=0"
                                      "7047","22.999778","dd.ddd.167.25","X.Y.16.80","TCP","1494","[TCP Retransmission] 80 > 52287 [ACK] Seq=4944961 Ack=316 Win=30336 Len=1440"
                                      "7048","23.062031","X.Y.16.80","dd.ddd.167.25","TCP","54","52287 > 80 [ACK] Seq=316 Ack=4960801 Win=345600 Len=0"
                                      "7049","24.019738","dd.ddd.167.25","X.Y.16.80","TCP","1494","[TCP Retransmission] 80 > 52287 [ACK] Seq=4960801 Ack=316 Win=30336 Len=1440"

                                      На PfSense все вроде correct:

                                      23:56:42.003041 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 11840, offset 0, flags [DF], proto TCP (6), length 1480)
                                      DD.DDD.167.25.80 > X.Y.16.80.52287: Flags [.], cksum 0x9954 (correct), seq 1123201:1124641, ack 316, win 237, length 1440: HTTP
                                      23:56:42.003152 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 11841, offset 0, flags [DF], proto TCP (6), length 1480)
                                      DD.DDD.167.25.80 > X.Y.16.80.52287: Flags [.], cksum 0x0578 (correct), seq 1124641:1126081, ack 316, win 237, length 1440: HTTP
                                      23:56:42.003162 76:49:50:73:85:f7 > 00:03:47:98:1b:80, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 1183, offset 0, flags [DF], proto TCP (6), length 40)
                                      X.Y.16.80.52287 > DD.DDD.167.25.80: Flags [.], cksum 0x9d2d (correct), seq 316, ack 1120321, win 1507, length 0
                                      23:56:42.003272 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 11842, offset 0, flags [DF], proto TCP (6), length 1480)
                                      DD.DDD.167.25.80 > X.Y.16.80.52287: Flags [.], cksum 0x3a35 (correct), seq 1126081:1127521, ack 316, win 237, length 1440: HTTP
                                      23:56:42.003390 00:03:47:98:1b:80 > 76:49:50:73:85:f7, ethertype IPv4 (0x0800), length 1494: (tos 0x28, ttl 56, id 11843, offset 0, flags [DF], proto TCP (6), length 1480)
                                      DD.DDD.167.25.80 > X.Y.16.80.52287: Flags [.], cksum 0x5491 (correct), seq 1127521:1128961, ack 316, win 237, length 1440: HTTP

                                      L 1 Reply Last reply Reply Quote 0
                                      • L
                                        lucas1 @lucas1
                                        last edited by

                                        @lucas1
                                        После изменения в guest OS на сервере виртуализации в свойствах сетевого интерфейса режима VirtLO на Intel E1000 все заработало нормально.

                                        Записи Default Deny в журнале PfSense никак с этим не связаны.

                                        Checked Disable hardware checksum offloading повлияло на журналирование Alerts Pfblocker DNSBL. Теперь там появляются записи, правда IF и Sourse - Unknown.
                                        Но и это хорошо.

                                        1 Reply Last reply Reply Quote 0
                                        • First post
                                          Last post
                                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.