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

    [RESOLU] "Default deny rule IPv4" après upgrade 2.2.2 -> 2.2.4

    Scheduled Pinned Locked Moved Français
    10 Posts 2 Posters 2.3k 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.
    • S
      Shadow aok
      last edited by

      Bonjour,

      J'utilisais pfSense 2.2.2 sur une boitier APU avec une interface LAN, une interface WLAN (couplé via un bridge LAN_WLAN), et deux interfaces WAN (configuration en dual wan avec fail-over).

      J'ai fait la mise à jour vers le 2.2.4 avec backup complet.

      Depuis la màj, le réseau local ne peut plus pinger la passerelle ni accéder au net.
      On peut toujours accéder à l'interface web de pfsense.

      La passerelle accède bien au net et ping bien le réseau local.
      Je peux également y accéder de l'extérieur.

      J'ai tenté de recharger la dernière configuration, sans succès.
      J'ai restauré le backup réalisé avant l'upgrade, et le problème persiste.

      Toutes mes règles firewall sont bien là, y compris les autorisations globales pour le réseau local :

      IPv4 * LAN_WLAN net * * * * none   Default allow LAN to any rule
        IPv6 * LAN_WLAN net * * * * none   Default allow LAN IPv6 to any rule

      Si je désactive le firewall, je peux à nouveau pinger la passerelle depuis le réseau local, mais pas accéder au net à cause du dual wan qui se retrouve hs (normal).

      J'ai ceci dans les logs du firewall :

      Sep 14 15:31:03 LAN_WLAN 192.168.1.2        192.168.1.1 ICMP

      The rule that triggered this action is:
      @5(1000000103) block drop in log inet all label "Default deny rule IPv4"

      A noter que j'ai plusieurs réseaux locaux : 192.168.1.0/24, 192.168.2.0/24 et 192.168.3.0/24 (sur un bridge0 assigné à l'interface LAN_WLAN)
      Pour chacun d'entre eux, la passerelle possède l'ip 1 sur sa patte LAN (192.168.2.1 et 192.168.3.1 étant des ip virtuelles).

      WAN1 (DHCP/DHCP6) : re1
      WAN2 (DHCP/DHCP6) : re2
      LAN_WLAN (192.168.1.1/none) : BRIDGE0 (OPT1+WLAN)
      WLAN (none/none) : ath0
      LAN (none/none) : re0

      Alors que la passerelle des postes locaux est bien 192.168.1.1, lorsque je fais un traceroute, cela tente de passer par 192.168.2.1.

      Une idée ?

      1 Reply Last reply Reply Quote 0
      • C
        chris4916
        last edited by

        @Shadow:

        Alors que la passerelle des postes locaux est bien 192.168.1.1, lorsque je fais un traceroute, cela tente de passer par 192.168.2.1.

        Une idée ?

        Si la route pour les postes sur 192.168.1.0/24 est bien en 192.168.1.1 (ce qu'il faut effectivement vérifier plutôt 2 fois qu'une  ;) ) alors ce que tu décris tendrait à montrer que pfSense utilise lui même 192.168.2.2 comme passerelle par défaut  ???

        Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

        1 Reply Last reply Reply Quote 0
        • S
          Shadow aok
          last edited by

          Et bien non, si je regarde les routes de la passerelle, elle a bien le lien wan principal comme route par défaut.
          Pour le réseau local, netstat me parle d'un link#10 comme passerelle par défaut.

          Reste à savoir à quelle interface ce link#10 fait référence.

          1 Reply Last reply Reply Quote 0
          • C
            chris4916
            last edited by

            peux-tu poster ici le résultat d'un "netstat -r" ou "route PRINT" d'un poste ?

            Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

            1 Reply Last reply Reply Quote 0
            • S
              Shadow aok
              last edited by

              IPv4 Table de routage
              ===========================================================================
              Itinéraires actifs :
              Destination réseau    Masque réseau  Adr. passerelle   Adr. interface Métrique
                        0.0.0.0          0.0.0.0      192.168.1.1      192.168.1.2    276
                      127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
                      127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
                127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
                    192.168.1.0    255.255.255.0         On-link       192.168.1.2    276
                    192.168.1.2  255.255.255.255         On-link       192.168.1.2    276
                  192.168.1.255  255.255.255.255         On-link       192.168.1.2    276
                      224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
                      224.0.0.0        240.0.0.0         On-link       192.168.1.2    276
                255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
                255.255.255.255  255.255.255.255         On-link       192.168.1.2    276
              ===========================================================================
              Itinéraires persistants :
                Adresse réseau    Masque réseau  Adresse passerelle Métrique
                        0.0.0.0          0.0.0.0      192.168.1.1  Par défaut
              ===========================================================================
              
              

              192.168.1.2 est l'ip du poste.

              1 Reply Last reply Reply Quote 0
              • C
                chris4916
                last edited by

                @Shadow:

                192.168.1.2 est l'ip du poste.

                C'est assez évident  ;)

                Tout m'a l'air bien dans ce que tu montres ici. Je ne vois rien de choquant ni qui t'empêcherait, en terme de route, de joindre la passerelle par défaut.
                Donc le problème, si problème il y a, n'est pas au niveau des routes sur le poste de travail.

                Ceci dit, ne pas arriver à faire un ping, c'est peut-être juste ICMP qui est bloqué au niveau du FW  ;) ou un problème de route coté FW.

                Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

                1 Reply Last reply Reply Quote 0
                • S
                  Shadow aok
                  last edited by

                  Tout marchait bien avant l'upgrade, même en cas de reboot de la passerelle.
                  Ma config survit très bien à un reboot, mais apparemment pas à cette upgrade et je ne vois pas pourquoi.

                  Bon, factory reset et rechargement de la configuration ou du full backup, je verrai bien ce que ça donne.

                  1 Reply Last reply Reply Quote 0
                  • S
                    Shadow aok
                    last edited by

                    Reset + chargement config.xml sans succès (pas de ping ni d'accès au net).
                    Chargement backup (pour retour en 2.2.2) sans succès.

                    Par contre, je vois le souci principal.
                    En console, l'ip principale du bridge est devenue 192.168.2.1 alors que ce n'est qu'une ip virtuelle.
                    Cela devrait être 192.168.1.1.

                    1 Reply Last reply Reply Quote 0
                    • S
                      Shadow aok
                      last edited by

                      Problème résolu et c'est donc un bug de pfsense.
                      Si je vais donc mon interface LAN_WLAN, l'ip est bien 192.168.1.1 (192.168.2.1 et 192.168.3.1 sont 2 ip virtuelles associées à cette interface).

                      En console, c'est 192.168.2.1 qui est la principale ip de LAN_WLAN (BRIDGE0).

                      Il suffit que je sauvegarde le formulaire sans rien changer et 192.168.1.1 redevient l'ip principale du bridge et tout fonctionne.

                      Donc, lors du chargement de la config (upgrade ou restauration), il y a un souci qui fait que l'ip principale du bridge devient 192.168.2.1.

                      Et depuis la 2.2.4, même en cas de reboot, le problème se produit.
                      Alors que ce n'est pas le cas en 2.2.2.

                      1 Reply Last reply Reply Quote 0
                      • S
                        Shadow aok
                        last edited by

                        Rapport de bug effectué :
                        https://redmine.pfsense.org/issues/5136

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