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

    SIP registration timeout due to stale entry in pfsense state table

    Scheduled Pinned Locked Moved NAT
    27 Posts 12 Posters 34.2k 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.
    • D
      danswartz
      last edited by

      Hmmm, I've tried unplugging the wan cable and plugging it back in 10 seconds or so later - I see warnings about the gateway being down, but it apparently didn't get a new IP - not sure how to force that to happen (I have a PPPoE WAN).  I guess I can just wait a few days for it to change…

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

        @danswartz:

        Hmmm, I've tried unplugging the wan cable and plugging it back in 10 seconds or so later - I see warnings about the gateway being down, but it apparently didn't get a new IP - not sure how to force that to happen (I have a PPPoE WAN).  I guess I can just wait a few days for it to change…

        Depends on your ISP, but usually if you disconnect and reconnect PPPoE (reboot, or do so under Status>Interfaces) you'll usually get a new IP.

        1 Reply Last reply Reply Quote 0
        • D
          danswartz
          last edited by

          Okay, maybe I'll give the reboot a try. My concern with rebooting the gateway was that I thought it might do too much stuff, so it might not prove anything if it did get a new IP (and also, there would not be any states to kill).  I think when I get home today, I will try to kill PPPoE and reconnect it as you suggested.  Thx!

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

            Oh, yeah what you're looking at is states, rebooting will wipe those. Disconnect/reconnect under Status > Interfaces

            1 Reply Last reply Reply Quote 0
            • D
              danswartz
              last edited by

              Cool, will do.  Thanks again!

              1 Reply Last reply Reply Quote 0
              • D
                danswartz
                last edited by

                I ran out of time this morning, but I did get some useful information.  Basically, the routine that gets called to flush states for downed gateways has a number of issues.  I will try to complete my analysis today and follow up on redmine.

                1 Reply Last reply Reply Quote 0
                • D
                  danswartz
                  last edited by

                  I was not able to get totally to the bottom of this (e.g. figure out the fix), due to not knowing the code, but I think I did figure out two reasons why the code is not doing what is intended.  I updated issue 8 on redmine.  Let me know if there is anything more I can do on this front…

                  1 Reply Last reply Reply Quote 0
                  • B
                    bradford_haynes
                    last edited by

                    I've recently come to think that I'm seeing the same problem.  I recently switched from DSL to Cable.  When using DSL, the modem was configured as a bridge and either I got an address or I didn't.  With the cable modem, if I don't get an address from the cable "head end" for any reason, the modem itself will give me a private address (192.168.100.x).  In talking to the ISP, it seems they have been doing maintenance on their systems at night.  During that time, my modem thinks the network is down and ends up giving me a private address.  The lease time is only 30 seconds and usually I get a public address again within 2-10 minutes.

                    However, during that time, my trixbox/asterisk system trys to re-registers with my VOIP provider.  Now, pfsense keeps an outbound state from my trixbox to the provider using the PRIVATE address.  I see the packets being sent out the WAN but the source address is the private address even though I've already obtained a new public address.  This results in all my inbound phone calls being rejected.

                    I need a way of clearing the state table when the address changes.  In the short term, I would like to prevent pfsense from obtaining that private dhcp address from the cable modem.

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

                      Can anybody post a working script suitable for 2.0 ?

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

                        I have a static WAN IP over a PPPoE connection that periodically drops. Upon moving to v2.0RC3 I experienced the problem described in this thread. Solution was to run pfctl -b on the WAN interface IP (or to manually reset all states in the web GUI, or restart the PFSense box which does the same, as already discussed).

                        Basically I want the states between the SIP server and the Asterisk box cleared when the PPP interface comes back up. pfctl -b will clear ALL existing states but it is the only method I have found that reliably works.

                        cat > /usr/local/sbin/voip-wan-wipe
                        #!/bin/sh
                        sleep 30 # Give the WAN routes time to take effect
                        pfctl -b 202.116.181.110 # Clear all existing connection states for my WAN IP

                        Chmod that to 755. Add the following line to the /usr/local/sbin/ppp-linkup file just before the exit line:

                        /usr/local/sbin/voip-wan-wipe & # Run as a separate script to execute in a separate process

                        I can verify this works for my setup. I don't understand why the problem did not present in v1.2.3 for me though.

                        I did also try pfctl -k <asterisk box="">-k <sip peer="">but it didn't work: it said that it cleared some states but it did not result in the SIP registration coming back.</sip></asterisk>

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