Issue with VoIP Phones not getting Reconnected over Site To Site VPN

[NateCog]

Hello, we are experiencing an issue with a multi site VPN setup. The central office has a Digium PBX and Digium VoIP Phones are deployed throughout the company. We are quite frequently experiencing issues where our traffic drops and the VoIP Phones at the remote locations are unable to reconnect. The cause of the drops appears to be our Comcast Cable internet connection. It cuts out for a short period of time, maybe 30 seconds or less.

Once the VPN tunnel is restored, all traffic can resume as normal (we have RDP Traffic back to the central office as well), but some of the phones will not reconnect. Not all phones. Even rebooting the phones has no effect. The only thing that helps these phones is either waiting maybe 20-30 minutes or more, or to reboot the Firewall at that particular remote location. 

Does this sound like anything anyone has come across before? I have a ticket open with FortiNet support, I'm waiting to coordinate getting a packet capture at the time of an occurrence, but I thought I would post here to see if anyone had ideas. 

Thanks in advance. 

[Toshi_Esumi · Accepted solution]

This might not be the same but might be similar depending on the routing setup.

Long story short, our sip trunk server keeps checking the client sides periodically and this customer happened to be connected over VPNs, and their locations internet access come over the tunnel and go though the same FG(vdom) and it has a default route pointing to the internet interface. When the tunnel went down the keepalive packets followed the default route outside the tunnel and the session, although it never reachs the destination, never dies even after the tunnel comes backup.

What we did was to put a deny policy specifically for the destinations not to go outside the tunnel.

Again, your case might be completely different. But if you sniff the traffic you can determine if this is the case or not.

[NateCog]

This looks to be resolved now. 

FortiGate support suggested adding a black hole route on each remote firewall for the central office subnet with a longer distance than the Site to Site VPN Route. In the event the VPN is down, the black hole route is loaded into the routing table instead and the SIP traffic terminates. This seems to have resolved the problem for us. Looks to be similar to your answer Toshi, but using Routes instead of Policies.