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.
