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

    Bug in rules.debug if interface is down

    Scheduled Pinned Locked Moved Firewalling
    4 Posts 2 Posters 1.7k 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.
    • R
      rcarr
      last edited by

      For me, this bug manifests with the $wan interface, but I think it might manifest for other interfaces given the right circumstances…

      If you have a rule which refers to the IP address of an interface, and that interfaces is down and has no IP addr (e.g., $wan interface, configured for DHCP, but not connected to the network -- thus no IP), rules.debug hiccups, creating a commented out rule that starts with:

      at the break!

      followed by the label (if any) that you supplied.

      For instance, this WAN anti-spoofing custom rule:

      BLOCK on WAN if the source is "WAN address" and the destination is any, description "Block packets spoofing WAN IP addr (LAND attacks)"

      If my DHCP-configured WAN interface is disconnected from the network, rules.debug will generate:

      at the break! label "USER_RULE: Block packets spoofing WAN IP addr (LAND attacks)"

      I think your code just assumes every enabled interface has an IP addr when it renders the XML.

      Possible fix: instead of filling in the actual IP addr of interfaces when rules refer to them, use "($interface)" instead.  Let PF figure out the IP addr.

      1 Reply Last reply Reply Quote 0
      • S
        sullrich
        last edited by

        Sometimes on bootup when the interface is not initialized it does this.  However it reloads the filter configuration at the very end of the bootup process which will correct this.

        Let me guess, pppoe?

        1 Reply Last reply Reply Quote 0
        • R
          rcarr
          last edited by

          Nope.  While I'm playing around with pfsense, I just happen to not have the $wan interface (DHCP) plugged in.

          So I boot up with the $wan not connected and leave it like that because I'm not ready to put the pfsense box into production.  You're right that as soon as I connect the $wan interface and it gets its DHCP addr, the rule fixes itself in rules.debug.

          I just think it's more correct to refer to an interface's IP addr by reference "($wan)" than by value.

          1 Reply Last reply Reply Quote 0
          • S
            sullrich
            last edited by

            @rcarr:

            I just think it's more correct to refer to an interface's IP addr by reference "($wan)" than by value.

            You might be right.  Mind submitting a patch to change this behavior?

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