Background: I have a site using VOIP with 2 internet links. We have been having issues with the VOIP trunk 'failing' randomly - the symptoms are that the traffic leaves the router but there is no return traffic. Clearing the connection (GUI - IP/Firewall/connection) fixes the issue.

The VOIP system (freeswitch) makes an outbound connection using UDP to Port 5060 on the providers server every 60 sec, because this is less than the UDP timeout (180 sec) this effectively keeps a 'hole' though the firewall to allow an inbound call from the Providers server to the freeswitch system.

What I found today:
The issue occurs when there is a failover using recursive routing - when the prime link goes down the traffic fails over to the backup link and the connection/NAT(*) changes to use the Public address on the backup link. When the prime link comes back up the traffic fails back to the prime link BUT the connection/NAT does not reset and so traffic is being sent via the Prime link but using the public address of the backup link.

(*) - what I mean is the reply-dst-address as shown in the connection properties.

I don't think it is relevant but this traffic is using routing marks and a specific routing table.
ROS version is 6.48.6 MipsBE.

Initial state - routing via main link interface with address A.A.A.A - connection shows reply-dst-address/port of A.A.A.A:5080
With prime route down - routing via backup link interface with address B.B.B.B - connection shows reply-dst-address/port of B.B.B.B:5080
Prime route comes back up - routing via main link interface with address A.A.A.A - connection shows reply-dst-address/port of B.B.B.B:5080

Is this 'expected behaviour' - or should the NAT tables be cleared on a routing change to ensure that the connections are using the 'correct' external IP address for the connection in use?

I am not sure if the physical port (ethernet) always goes down on the prime link when it fails - it did today when testing remotely as I could only force a failover by rebooting the primary ISP router - so I am not sure if the NAT behaviour on failover to backup is different if the ethernet port on the prime link stays up.

What is causing failure on your ISP, the only time mine burps its because its a change of wanip address?
Have you considered putting the voip on teh secondary WAN..........

@anav - sorry that isn't relevant question. FWIW - The voip traffic is actually on the site backup WAN but I have set the primary data WAN as failover for the VOIP traffic...

The glitches (xDSL Service) could be anything - telco DSLAM upgrades, ISP work at their DSL breakout point, router upgrades.

The point is that a setup that should give seamless failover to/from the backup link isn't doing so...

I can also now confirm that if I force the routing change by disabling the primary route (so the interface doesn't go down) then the NAT translation isn't cleared in that case either - in example above with traffic using NAT of A.A.A.A then if I fail the route via A.A.A.A then the traffic routes via B.B.B.B but STILL with NAT address of A.A.A.A so the connection fails.

It seems that there is a 'sense check' missing with the NAT processing where it should clear a NAT translation that is using an IP address incompatible with the outgoing interface.

There is no way it can be seamless...........
Unless you have a virtual IP setup, thus whatever feeds the virTual IP ( ISP1,2,3 etc ) doesnt matter.