Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 2 subscribers
  • Views 1732 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Mutlipath in Failover and NAT Session Table

skydiver
So I have been working with Astaro on this per our support agreement and have yet to find a resolution.  We have verified what is happening but I have been told that this may not have a resolution because it is how the ASG is designed.

Here is what is happening.  I have ASG 120's at our restaurants where we use VOIP phones provided by a hosted PBX phone provider.  I have two different internet connections from two different providers.  I have the Muitipath configuration setup in failover mode and have two rules in place in the Multipath routing that direct traffic from the VOIP network segment out the primary when it is available and when in the failover mode directs the traffic out the secondary internet connection.

When I disable the primary internet connection via the Astaro Webmin interface, the system fails over perfectly and my VOIP phones re-register with the phone provider from the secondary internet connection.  When the primary internet connection is failed over to the secondary "naturally" by way of disconnecting the coax cable from the cable modem on the primary internet connection, the system takes one minute to detect the primary connection loss then it fails over to the secondary connection.

When the system fails over "naturally" due to packet loss, what is happening is that the VOIP traffic is correctly routed out the secondary internet connection but the NAT session tables are not being reset.  The result is that the VOIP packets are being directed out the secondary internet connection but still NAT'd to the primary internet connection.  This was confirmed by way of a packet capture by the Astaro support team.

I am still waiting to see if this is indeed a bug (it is in my view) but the initial response was that this is the way the system is designed and probably wouldn't be changed.  Can anyone explain to me why this would be in the design specification for the router?  i am not sure if this makes a difference but since the traffic being sent between the phones and the PBX provider is UDP, there isn't a reset when the traffic is essentially being spoofed to reset the NAT session.  This may not make a difference.

Is there anyone else who has experienced similar NAT session table non-reset issues?

I will post here the response form Astaro when they make a final determination of what can be done.


This thread was automatically locked due to age.
  • 0
    So I am getting ready to do some testing with a v.8.0 ASG to try to resolve this issue with the help of senior tech reps at Astaro.  I will report back here what I find out.

    The call goes back out: Has anyone experienced issues when using failover multi-path routing of the NAT session tables not getting reset causing re-connection failures?  If you can give some examples of the type of programs/applications that experienced this issue it may help us craft a resolution.
  • 0
    I observered the following this weekend related to failover.  I didn't spend alot of time debugging it so I can't say what was really happening or if I was just doing something wrong.

    1)  My home system has DSL & Cable connections.  Cable is primary for everything except VOIP traffic. We will call this Astaro_1

    2)  I was trying to config another box for a relatives home.  So I disconnected the ethernet cable (at the LAN card) and plugged it into their newly configured box Astaro_2.  I rebooted the cable modem and the new Astaro_2 got a new IP address and worked OK

    Disconnecting the cable failed over most everything (or so it appeared) on Astaro_1.  I could browse the web, etc w/o any problems from my systems connected to that box.

    However, no matter what I tried, I was unable to access the Astaro_2 WebAdmin interface from my regular home network connected through Astaro_1.  I added packet filter rules (any -> WebAdmin -> any, even any -> any -> any) and tried all sorts of combinations.  I did have the new Astaro_2 WebAdmin enabled from "Any" so that wasn't the problem, but I was also watching the packet filter there for signs of dropped packets but never saw any.

    What finally worked was going into the webadmin of Astaro_1 and disabling the eth1 port in the interfaces tab.  Immediatly after doing this I was able to refresh the browser on my home machine and connect to the new box.

    Not sure if above makes any sense, or if it is anyway related...  Or I was just too tired...
  • 0
    So during the first round of testing, the packets are correctly addressed with the source IP for the server to direct the return traffic to but since the session isn't being reset, My belief is that the connection is trying to continue to use the same UDP source packets.  My thoughts are that the server doesn't see this as valid and will not allow a session to continue to a different IP address.

    Round two testing will continue later this week.