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

    Is pfctl able to kill Sip state on a WAN DHCP

    Scheduled Pinned Locked Moved General pfSense Questions
    4 Posts 3 Posters 1.8k 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.
    • T
      tomdc
      last edited by

      Goodnight,Morning..  8)

      For Ermal, and other programmers ..hope you read this :)

      I am following the issue of an asterisk sip stale state after wan ip change..I also see there is activity on the issue.. thank you for that!

      Last night i looked in filter.inc , dhclient-script, ppp …and tried all of the pfctl commands manually in a shell. Unfortunatly didnt kill my current sip state..

      I have WAN DHCP, and the only command that killed the sip state was /sbin/pfctl -k 192.168.x.x -k SipProviderPublicIP

      Is it possible that pfctl is just not able to kill UDP multiple:multiple states on Wan Dhcp?

      thanks for reading,
      Tom

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        On 2.1, if you enable the option to kill states when a gateway goes down, then all states are removed when a gateway goes down, not just the WAN-side states.

        It should do exactly what you're asking there.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • T
          tomdc
          last edited by

          Jim,
          excuse for the late answer.. i was not able of debugging stuff.. I have enabled the option 'kill states when a gateway goes down' using pfsense 2.1.

          There was an issue with our WAN 10 minutes ago.. When the WAN came back online..my asterisk was not able of reaching the sip provider. When i looked in shell, I got these states in pfsense

          
          #pfctl -ss | grep 85.119.188.3
          vr0_vlan10 udp 85.119.188.3:5060 <- 192.168.150.80:5060       NO_TRAFFIC:SINGLE
          lo0 udp 192.168.150.80:5060 -> 85.119.188.3:5060       SINGLE:NO_TRAFFIC
          
          

          when i killed the state on interface lo0

          
          #pfctl -ss | grep 85.119.188.3
          vr0_vlan10 udp 85.119.188.3:5060 <- 192.168.150.80:5060       MULTIPLE:MULTIPLE
          vr1 udp 192.168.150.80:5060 -> 88.21.2.130:30426 -> 85.119.188.3:5060       MULTIPLE:MULTIPLE
          
          

          My asterisk registered immediatly after that.

          In my previous pfsense, 2.0.3 the state that needed to be killed was a MULTIPLE:MULTIPLE
          LOCALASTERISKIP:5060 -> WANIPOLD:17205 -> SIPPROVIDER:5060 MULTIPLE:MULTIPLE

          i'm sure the WAN states were killed in pfsense 2.1 after the issue on the WAN IP.. But now there's another new state on the lo0 interface
          The state that bugged my asterisk today was now a state on the lo0 interface?

          thank for sharing thoughts
          Tom

          many thanks,
          Tom

          1 Reply Last reply Reply Quote 0
          • A
            AndrewZ
            last edited by

            @jimp:

            On 2.1, if you enable the option to kill states when a gateway goes down, then all states are removed when a gateway goes down, not just the WAN-side states.

            Enable means checkbox is not selected, right?
            It seems I'm observing the same issue - I have this ckeckbox unticked and my server was not able to register to the external voip provider until I manually cleared the states through web gui.

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