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

Dual WAN SIP VoIP not failing over

Routing and Multi WAN
3
5
2.0k
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 Jan 28, 2017, 12:46 AM

    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
    • C
      chpalmer
      last edited by Jan 28, 2017, 2:00 AM

      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 Jan 28, 2017, 2:42 AM

        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 Feb 3, 2017, 2:16 PM Feb 3, 2017, 2:12 PM

          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 Mar 12, 2017, 8:11 PM

            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.