SIP registration over a IPSEC VPN tunnel when tunnel is down and get up again.

[ejvl]

Hi,

We’re using multiply Fortigate 60E, v6.2.5, firewalls on multiply locations, they are connected through a IPSEC tunnel to one location, also a Fortigate, that works fine.

The main location use a SIP PBX server and other locations use Sip Phones (Gigaset N300A).

The Gigaset-phone will registering fine over the IPSEC tunnel, that works great. If the tunnel is down, of course the Gigaset don’t work anymore.

But if the tunnel is recovering and automatically gets up when available, the Gigaset won’t register anymore. We’ve to power down the Gigaset phone for about 10 minutes, reconnect and all works fine.

In the former Cisco configuration, this problem is not there, in the new Fortigate configuration, the problem occur. In Cisco configuration it works fine, so it’s not a problem on the Gigaset phones.

Is there a setting I can check for this problem? For example, if there is a power down on the main location, we’ve to reset all the Gigaset phones on other locations and that is a problem.

SIP als is disabled, we've followed this instruction: https://kb.fortinet.com/k....do?externalID=FD36405

In advance thanks.

[emnoc]

Sounds like you have a SIP device issue and lack of SIP-KAs ( keepAlives )  on the device. You might have gotten by with on cisco device but your problem is the end-sip-devices and SIP KAs.I would look at that along with sip re-registerations.

The reason why the issues, When the tunnel goes down, the sip-control-sessions from a statefull tracking are destroyed. So your end device do not know the tunnel went down and most likely KAs are not being used.

Ken Felix

[brycemd · Accepted solution]

It sounds to me like you may be missing black hole routes. SIP traffic tends to keep sessions open for a long time, so when the tunnel goes down it starts sending over the WAN and the session just sticks there.

There needs to be a black hole route to prevent the session from creating when the tunnel is down.

[Toshi_Esumi]

Or, deny the destination IP (ePBX) with a plicy toward the wan interface(s) the default route is pointing to. That's how we avoided the same problem in the past.