Looks like bug in 6.2.14 and may be other versions

[softmaster]

Looks like I found a bug.

The situation is a next.

My customer have a Forti 100D with 2 connected WAN interface and one PPOE interface configured on port 10 for connectivity with VoIP provider. In static route configured 2 routings to 0.0.0.0/0 for both WAN interfaces and routing to specific 172.30.0.0/16 network to VoIP provider. Dynamic gateway is enabled on PPOE interface.

Immediately after firewall restart all routings working properly, SIP and PING packets to VoIP providers age going to PPOE port10 interface. SIP communication is working. And I see all corresponding packets  in logs.

In about 2 min forti log shows that SIP packets went through WAN policy with ID 1 (instead SIP policy with ID 63) but in log details still show port10 as destination interface. In 2 more min log shows that SIP packets went to WAN policy with ID1 and shows WAN interface as destination interface. And, for sure, SIP communication stop to work.

At the same time Ping/Traceroute traffic still went through correct routing and correct interface. 
SIP ALG and SIP helpers are disabled.
Any ideas?

Thanks 

[ede_pfau]

Inconclusive. What happens to the routes? Watch them in D.ashoard/Network/Routing widget.

The policy is chosen after routing decision is made, as the route determines the outbound interface.

OTOH, if there are multiple equally appropriate routes, FortiOS chooses the one involving the interface on which this traffic arrived.

Could you show "get router info routing all" here, please? that is the routing table (not the definitions) which is in use. Check that it doesn't change over time (i.e., within 2 minutes).

[softmaster]

Hi

get router info routing all

Routing table for VRF=0
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default

S* 0.0.0.0/0 [10/0] via 147.234.23.117, wan2
[10/0] via 5.28.168.156, wan1
C 5.28.168.156/31 is directly connected, wan1
S 10.9.0.0/16 [10/0] via 192.168.2.210, lan
C 10.10.10.0/24 is directly connected, port7
C 10.10.20.0/24 is directly connected, port9
C 10.10.30.0/24 is directly connected, port8
C 10.255.255.255/32 is directly connected, ppp1
C 147.234.23.116/30 is directly connected, wan2
S 172.20.0.0/24 [10/0] is directly connected, Olga-Home
S 172.20.10.0/24 [10/0] is directly connected, Softmaster-VPN
C 172.25.86.0/24 is directly connected, port12
S 172.30.0.0/16 [10/0] via 10.255.255.255, ppp1
C 172.33.1.155/32 is directly connected, ppp1
S 192.168.1.0/24 [10/0] via 10.10.20.2, port9
C 192.168.2.0/24 is directly connected, lan
C 192.168.11.0/24 is directly connected, WiFi-Autodeal
C 192.168.14.0/24 is directly connected, mgmt
S 192.168.50.0/24 [10/0] via 10.10.10.3, port7
S 192.168.51.0/24 [10/0] via 10.10.30.4, port8
S 192.168.53.0/24 [10/0] is directly connected, Park_Rem_IPsec
S 192.168.65.0/24 [10/0] via 10.10.10.3, port7

This is the route that have to work:

S 172.30.0.0/16 [10/0] via 10.255.255.255, ppp1

But problem that it is not working for SIP traffic. When I changed it to other direction, Ping/ICMP is going to this other way but SIP still going to default gateway. 

BTW - I have no policy routing for SIP traffic. 

[softmaster]

I can't find why SIP routing to specific IP is going to default gateway only. I configured other SIP connection - it working properly. But SIP to this specific IP, as I wrote, still going vi one of default gateways...

Thanks for any ideas 

[softmaster]

[softmaster]

 I paid attention that Forti behavior changed after restart. But I can't restart it many times, this is working system. I'll try to perform the few tests tonight.  

[softmaster]

I temporary replaced this 100D with 200E, transferred configuration and upgraded up to 7.2.14. Unfortunately, FortiGate behavior didn't change... It work properly for about 2-2.5 minutes and change routing for SIP traffic only to this specific IP to one of default gateways. ICMP traffic still work properly...