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

    VoIP SIP dies until state table reset

    Scheduled Pinned Locked Moved NAT
    11 Posts 6 Posters 8.5k 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.
    • J
      joako
      last edited by

      I have a very odd issue that I can't explain. I have pfSense 1.2.3 running with various interfaces and on the LAN interface I have an Asterisk server, it connects through the OPT1 interface with static firewall rules to a SIP server at my ISP. Everything is a static IP (OPT1 interface, Asterisk server, SIP server) but every approx. 16 hours I will loose connection to the SIP server, Asterisk shows the SIP peer as "unreachable." If I shut off the Asterisk server for a few minutes and start it again it will reconnect to the SIP server, same thing if I clear the states table in pfsense.

      At this point you would think it is a network issue, probably in the ISP, but once the SIP server goes offline it will NEVER go back online unless I do somnething about it. It will stay unreachable for hours to days until I reset the states table or restart either the Asterisk server or pfSense. I read about this similar issue when using WAN failover, but that is not what I am doing in this case.

      Does anyone have any suggestions on how I can establish a SIP connection to my ISP through pfSense without constant intervention? I also had pfSense 2.0 Beta4 on different hardware and the same issue was taking place.

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

        Maybe you can find a hint here.
        http://doc.pfsense.org/index.php?title=Special%3ASearch&search=voip&go=

        /Perry
        doc.pfsense.org

        1 Reply Last reply Reply Quote 0
        • J
          joako
          last edited by

          There's nothing new in those documents.

          But since it's all UDP traffic I am considering changing the relevant rules to "state type" = none. I can keep a VoIP call up and without disruption through a state table reload.

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

            Have you tried changing state table optimization ?

            2. Set Conservative state table optimization - pf's default UDP timeouts are too low for some VoIP services. If your phones mostly work, but randomly disconnect, set "Firewall Optimization Options" to Conservative under System -> Advanced. Note this only works on 1.2.3-RC1 and newer as pf itself never increases UDP timeouts, our code changed to do this.

            /Perry
            doc.pfsense.org

            1 Reply Last reply Reply Quote 0
            • J
              joako
              last edited by

              Yes I've tried all possible choices there.

              For now the solution that is working is cron to reset state table I think 1x at 3:00 am and again 3:30 AM. It's a nasty dirty hack – but since I set it up I have not had any additional problems.

              My next try would have been to disable states entirely for the VoIP traffic -- but if it's working fine now and I have no other issues with 2 daily state table resets I am going to leave it alone.

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

                Hi joako,

                Did you ever find a resolution to this issue. Since switching to pfSense, I've been experiencing exactly the same issue.

                bd.

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

                  If your IP changes that will happen (unless you're running 2.0).

                  1 Reply Last reply Reply Quote 0
                  • J
                    joako
                    last edited by

                    @backd00r:

                    Hi joako,

                    Did you ever find a resolution to this issue. Since switching to pfSense, I've been experiencing exactly the same issue.

                    bd.

                    It's resolved but not how I would like it. Asterisk SIP peer becomes unreachable triggers an alert in nagios which clears pfSense state table. No complaints 620,000 calls later.

                    IP address is static for this route, but I do have a PPPOE dynamic WAN.

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

                      @cmb:

                      If your IP changes that will happen (unless you're running 2.0).

                      Could you please be more specific about 2.0 - are you talking about Gateway Monitoring feature?
                      It seems I have the same issue in 2.0-RC1, http://forum.pfsense.org/index.php/topic,34039.0.html
                      So, for some reasons this Gateway Monitoring feature is useless. Or misconfigured?

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

                        I have seen this problem too with my IP changing and 2.0-RC1 not clearing out the states with the old IP, so of course my voip server cannot connect. I did notice that the gateway the IP changed on showed no downtime. Not sure if that "no downtime" was simply after the IP change or how the downtime is actually determined. I would think it should show sime kind of downtime during the IP change and take appropriate action with the state table. But then again…

                        1 Reply Last reply Reply Quote 0
                        • J
                          joako
                          last edited by

                          If the ip changes gracefully e.g As a result of a routine dhcp renew I don't see why it should consider any downtime to have taken place.

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