Has anyone worked through a similar problem on SD-WAN where the self-originated traffic isn't smart enough to pick the correct interface to get out ( internet ).
I know this because running
diagnose sniffer packet any "port 8888" 4 0 l
we can see the device is trying to use the wrong port / sdwan member to talk to forticloud on port 8888. That's whats tricky with the self originated traffic when it doesn't work.
In this case we have wan1, port1 and port2 as member interfaces for sd-wan. port1 and port2 are private circuits and wan1 is the internet gateway. Looking at its very obvious which interface has the internet gateway but the device wants to use every port except the correct one for the self traffic. :( All the user / client traffic is operating as it should.
a year ago I solved the same problem with TAC.
Since self-originating traffic in version 6.2.2 and higher does not pass SD WAN - https://kb.fortinet.com/k....do?externalID=FD47380 - it is necessary to change DR.
But..in all KB and CB from Fortinet, it is stated that when using SD WAN, only one DR per SD WAN is required - which is obviously not always true...
So if there are some IPsec tunnels in SD WAN that connect local ranges (eg HQ and BR), it is necessary to place these IP local address ranges into Static Routes and set DR to the net (WAN1 and WAN2) directly to the gateway of the upstream router.
I had no other explanation from them. But the ticket says: Bug fix already available. From this I understand that it is probably a bug and will be fixed. But who knows ..
Anyway, now everything seems to work correctly (I will try it in detail tomorrow).
This is how my routing table looks like now (FTN support used all RFC1918 address)
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.