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

      Interesting idea.  I don't think you need to edit the config.xml to set cron jobs though, since a package is available, no?

      1 Reply Last reply Reply Quote 0
      • M
        maxthetor
        last edited by

        i have the same issue, but, with not translate.

        my voip server = 10.0.0.9
        my voip-trunk-server = 201.86.87.5 (vono)

        everything works fine for a while, then , then it's going sip registry timeout, forever.

        voip01*CLI> sip show registry
        Host                            Username      Refresh State                Reg.Time               
        VONO:5060                    XXXXX        105 Request Sent        Sat, 09 Jan 2010 11:55:07

        in my pfsense box, tcpdump in wan interface

        11:55:05.105388 IP 10.0.0.9.5060 > 201.86.87.5.5060: SIP, length: 584
        11:55:07.106127 IP 10.0.0.9.5060 > 201.86.87.5.5060: SIP, length: 584

        my nat rule.

        Outbound NAT rules

        nat on $wan  from 10.0.0.9/32 to any -> 189.XX.XX.XX/32 static-port

        ps: my ip 189.XX.XX.XX is Virtual IP (routed)

        my state table.

        all udp 201.86.87.5:5060 <- 10.0.0.9:5060      NO_TRAFFIC:SINGLE
        all udp 10.0.0.9:5060 -> 201.86.87.5:5060      SINGLE:NO_TRAFFIC

        anyone have any ideas?

        1 Reply Last reply Reply Quote 0
        • G
          gnail
          last edited by

          @Perry:

          Might help

          Thank you Perry, that worked perfectly.

          PS: This has been in development for a while now hasn't it.  :)

          1 Reply Last reply Reply Quote 0
          • P
            PeeZee
            last edited by

            @Perry:

            Might help
            …

            Only noticed your post now, still had the problem this morning, tried the script now, works perfectly

            Thanks!

            Would you happen to know if this problem is addressed in 2.0 ? If not, your script may be a good starting point for a built-in solution.

            1 Reply Last reply Reply Quote 0
            • P
              Perry
              last edited by

              http://redmine.pfsense.org/issues/show/8 should cover all dead states problems.

              I've add the script to the fit123 package (cass).

              /Perry
              doc.pfsense.org

              1 Reply Last reply Reply Quote 0
              • G
                g4m3c4ck
                last edited by

                I had a similar problem to this but a little different. Wasted a half a day figuring out what the problem was but hey thats life…...

                My setup is as follows: Pfsense 1.2.3-Release, Single WAN Static IP, I have pfsense running everything through a single interface using VLANs.

                I have my asterisk box and the VOIP phones in their own VLAN/subnet with all the proper inbound and outbound NAT setup and with everything working properly.

                Well on my LAN I foolishly opened my old asterisk test VM to see how I had some extensions configured and it attempts to register with my VOIP Provider. I realize what is happening and shutdown the VM. At this point I receive calls but no sound. I run a packet capture on both interfaces and see incoming RTP packets from the WAN and outgoing RTP packets from the Asterisk box on the VOIP VLAN.
                All outgoing calls work fine. I check the asterisk box and it seems to still be registered with my VOIP Provider. Reboot the Asterisk box. Same problem. Clear all states in Pfsense. Same problem. Grr...I had been doing some work on the Asterisk box so I thought I found a bug or made a mistake. I simplify everything and make sure everything is working properly with Asterisk. Still didn't work.

                Reboot Pfsense. Everything works again......

                So I guess the dead state problem is with any pfsense setup with more that two interfaces?

                Will Perry's little hack help me too?

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

                  Hmmm, I just had this happen yesterday.  My WAN IP changed, but for some reason the SIP registration entry didn't get punted.  I deleted it manually and all was good.  I looked at Perry's script, and while it looks fine, I sure think it would be nice if we could put scripts somewhere that they would be executed automatically when the filter is reloaded.  I was looking at /etc/inc/filter.inc and saw that packages can put custom scripts in /usr/local/pkg/pf to do stuff like this - is there any reason we can't have a generic version of this?  e.g. something like /usr/local/pf or some-such?

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

                    Ironically, the dyndns component does exactly what I need.  e.g. it detects the WAN IP has changed, and sends an update request to my dyndns account to update the name of my gateway.  I was looking where this gets called, and it is very specific to the dyndns code.  When I was using clarkconnect as my gateway, there was a script (/etc/rc.local, if memory serves), that they would call when they detected that the WAN IP had changed. and you could hook whatever you wanted there.  Maybe I am misreading the code now, but it looks like it doesn't make any attempt to detect this event, but just calls the interface configuration code.  I would dearly love the same functionality in pfsense (and would be happy to take a shot at coding it up, if needed.)

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

                      There is a custom option to pfctl that we have, -b IIRC, that kills all states on a specified interface. This is new in 2.0, and supposed to be run whenever an IP changes, as well as after failover for a multi-WAN setup. There's a todo item open to test it. http://redmine.pfsense.org/issues/show/8  I suspect it has some outstanding issues.

                      States don't get deleted in 1.2.x when an IP changes or in any other scenario, so anything that stays active will retain the former NAT association.

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

                        Hmmm, that is interesting, since I am running 2.0 (a snapshot from 4/24, IIRC.)  I will take a look at this and see if it is not working right all the time.  Thanks!

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

                          So I guess the dead state problem is with any pfsense setup with more that two interfaces?

                          (From a couple of posts back by someone else).  I ignored this initially, because I don't have multiwan, but I suddenly realized I do have more than two interfaces!  I have LAN and WAN as always, but my workaround for the havp issues was to install havp on my freebsd server and use re2 (wan is re0 and lan re1) to talk to that server on a dedicated subnet.  So, in fact I have 3 interfaces live.  I'm wondering if that is a big clue.  I am at work now, but I will take a look at this later and post my findings…

                          1 Reply Last reply Reply Quote 0
                          • 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
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.