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

    Dual WAN SIP VoIP not failing over

    Scheduled Pinned Locked Moved Routing and Multi WAN
    5 Posts 3 Posters 2.0k 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 setup 2 WAN connections and created a gateway group. Then I have assigned any firewall rule that relates to external connectivity (i.e.: anything besides block rules and rules relating to VPNs and VLANs) If I unplug the primary WAN connection then general traffic from the LAN to WANs appears to failover properly to the secondary WAN.

      The issue I have relates to a VoIP PBX server that communications through SIP to a provider to place and receive phone calls.

      At first the issue was that if the inactive secondary WAN goes down even for a moment the SIP connection (that was going through the primary WAN) would also momentarily drop. In my email inbox I would get an alert from pfSense that the secondary WAN was down and emails from the SIP provider that inbound phone calls have failed.

      As best as I can determine this issue was caused by the option System > Advanced > Misc > Flush all states when a gateway goes down. As I understand it this causes pfSense to flush ALL states for ALL gateways when any single gateway goes down. Since disabling it I have not had failed call notifications.

      However, another issue arises. When I disable the Flush all states option I have the opposite problem. If I take down the primary WAN connection by unplugging the network cable then all inbound calls fail. Despite the general LAN traffic like MS Outlook and web browsing being routed through the secondary WAN, the IP PBX does not re-establish its SIP connection through the secondary WAN. A traceroute does show all other traffic from the IP PBX is being routed through the secondary WAN. When I search under Diagnostics > States for the address of the SIP provider's server I see a state there from the IP PBX going through the primary WAN. The moment I manually clear this state the SIP connectivity is re-established and both inbound and outbound calls complete as expected through the secondary WAN connection.

      What workaround can there be? I think an option to "Flush ASSOCIATED states when a gateway goes down" could have everything working smoothly as I expect it to.

      Also during the time I have unplugged the primary WAN I get a constant stream of email from pfSense "Secondary WAN is down, removing from gateway group failover". Is there any way to recieve only one message when the connection goes down instead of constant periodic messages while this gateway is down?

      1 Reply Last reply Reply Quote 0
      • chpalmerC
        chpalmer
        last edited by

        Last question-  http://redmine.pfsense.org/issues/4031

        SIP-

        When your PBX goes out and registers the server it registers with has the original WAN as its contact point.  Im unsure how that could be quickly updated with your new WAN address without making the PBX re-register in order to re-direct that external server.

        Thus all incoming calls would still be directed to your first WAN.  Unless Im missing something.    :)

        Triggering snowflakes one by one..
        Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

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

          I understand there may be a delay for the re-registration, however it never takes place.

          Until I delete the stuck/stale state in pfSense that shows LAN IP of PBX > Down WAN > SIP Provider IP the PBX does not re-register. The PBX log shows for an extended period of time a message such as:

          Registration for user@host timed out, trying again (Attempt #47)

          In my most recent test I waited 15 minutes before I manually cleared the state.

          1 Reply Last reply Reply Quote 0
          • I
            IB
            last edited by

            For auto re-registering you must check "State Killing on Gateway Failure". But there is another problem:

            0. Our SIP-provider use fixed IP (domain name) for registration (control connection to UDP 5060), and "random", unknown on setup time, servers for voice.
            1. We have two channel - primary (good) and secondary (not good).
            2. We setup gateway with tiers for channels (1 and 2) and setup this gateway for traffic from PBX. All work fine.
            3. Good channel go down. With "State killing" all connections switch to 2st link - and control (5060), and voice. All work fine.

            and suddenly

            4. Primary channel go up. Control connection not switch back, it stay on 2st link.
            5. So our PBX receive incoming call from SIP-provider
            6. but when it try to establish new voice connect to "random" server, connections refused, because it come to voice server from another IP, not from control_connection_IP

            Is there method to sticky all connection FROM my PBX to one link?

            Or method for set frequently reset state for control connection? So pfsense must select path for every control frame?

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

              State Killing on Gateway
              Failure Flush all states when a gateway goes down
              The monitoring process will flush all states when a gateway goes down if this box is checked.

              The problem I have with this is when one gateway goes down ALL states on ALL gateways are killed. Like I said I have a primary WAN that is fiber and an unreliable Comcast connection as secondary. When this option is enabled and the Comcast connection goes down the calls going through the primary connection drop.

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