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

    Rule Schedule re-activation not working correctly

    Scheduled Pinned Locked Moved Firewalling
    6 Posts 1 Posters 839 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.
    • 4
      4o4rh
      last edited by 4o4rh

      I have a rule that passes voip ports and addresss for my providers from the hours 06:00 - 23:59. This worked fine under 2.45 -> 2.5.2

      Since i upgraded to 2.60 and then to 22.01 If i reboot pfsense, or i don't enable the schedule the 3 providers register succesfully.
      I can reset the voip devices multiple times and the 3 providers will register.

      When the schedule kicks in, the http and the voip services are disconnected.
      at 06:00 when the schedule kicks in again, the http works and one of the providers register, but 2 others fail to register.

      If i reset the device, the 2 still don't register. But if i reboot so the schedule has not blocked the rules, then all services register

      If i packet capture everything on the voip vlan, i don't see any errors.
      if i packet capture the wan interface i don't see the gigaset or voiptalk registration traffic.

      I have disabled suricata and only have pfblockerng enabled (tried to disable but no difference)

      4 1 Reply Last reply Reply Quote 0
      • 4
        4o4rh @4o4rh
        last edited by

        @gwaitsi i tried cloning the rules and deleting the original rules. the reason i did that

        The log was showing the rule as
        s:5d66db51b3fbc (1653986728)

        After i cloned and removed the old rule, the log now shows as
        (1610264323)

        Interestingly, the rules saved/cloned under 22.01 are not showing the rule description in the logs.

        but the original rules are.

        4 1 Reply Last reply Reply Quote 0
        • 4
          4o4rh @4o4rh
          last edited by 4o4rh

          @gwaitsi So there seems to be a defect here.

          When a scheduler is used, it is showing the rules as s:5d66db51b3fbc (1653986728) and is not using the scheduler Description for the rule.

          When the schedule is removed, it is using the description of the rule itself. ** seems this issue is fixed in the 22.05 developments snapshots.

          4 1 Reply Last reply Reply Quote 0
          • 4
            4o4rh @4o4rh
            last edited by

            @gwaitsi I have a rule that passes voip ports and addresss for my providers from the hours 06:00 - 23:59. This worked fine under 2.45 -> 2.5.2

            Since i upgraded to 2.60 and then to 22.01
            If i reboot pfsense, or i don't enable the schedule the 3 providers register succesfully.
            I can reset the voip devices multiple times and the 3 providers will register.

            When the schedule kicks in, the http and the voip services are disconnected.
            at 06:00 when the schedule kicks in again, the http works and one of the providers register, but 2 other fail to register.

            If i reset the device, the 2 still don't register. But if i reboot so the schedule has not blocked the rules, then all services register

            4 1 Reply Last reply Reply Quote 0
            • 4
              4o4rh @4o4rh
              last edited by

              @gwaitsi must have been corrupt xml i guess.
              i turned off the rules, created a new rules from the blocked transaction, edited that rule to have the same conditions as the former rule and it seems to be working.

              4 1 Reply Last reply Reply Quote 0
              • 4
                4o4rh @4o4rh
                last edited by

                @gwaitsi i was wrong. the http rule switches off and on correctly, but the rules for 5060 and the voip providers after 6am, only one of the 3 providers re-registers. i don't understand what can be blocking the other 2, it should to work on 2.5.2

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