Fortinet router in front, dropping pepvpn tunnel

We have a br1 hw3, with some odd behavior.
We have two tunnels, to our two datacenters to route traffic for sip phones.
One tunnel normally has little traffic depending on what site the phones are pointed to as primary.
The tunnel with the heavy traffic will only stay up on WAN for a period of time , then it will show the message “Not Available - Link Failure, no data received”
During this time, the WAN is up on the dashboard, and I can successfully ping and traceroute to the Balance 710 in our datacenter.
The tunnel without a lot of traffic, just health checks stay up on WAN no issue.
If I create a custom outbound policy to force the traffic to the other datacenter, it stays connected for a period of time then it shows “Not Available - Link Failure, no data received” and the orgional tunnel clears up and show wan is fine, now that there is little traffic going through it.
The amount of traffic is very small, maybe 1gb a day, and only 3-4 call paths at any time.
This BR1 is used only for phones, has no other devices using it for internet, and only routes the phone traffic via the pepvpn’s.
Cable modem (suddenlink) to Fortinet , lan side of fortinet to peplink WAN, peplink LAN to switch, vlan tags to phones.
If I have the cellular up , it never has any issue, on either vpn, and routes phones without issue.
I’m thinking it’s either an issue with the ISP suddenlink, or a configuration with the Fortinet.
Anyone have any ideas.
We have deployed a lot of peplinks behind, in front of and to the side of many routers, and never had this issue.We also tried changing the ports to 4600 and it didn’t change this behaviour.

“Not Available - Link Failure, no data received” means data traffic (UDP 4500 by default) is dropped between 2 SpeedFusion peers. Sound like the devices in front of Peplink or ISP have an intelligent to drop/delay tunnel type traffic when the usage spikes. Please check with the devices in front of Peplink or ISP. Alternatively, please test with another WAN link (e.g. USB WAN) to bypass the Fortinet and the ISP to confirm whether the problem persists.

I tried a bunch of different ports and all dropped after a while.
So far changing the data port to 443 has kept the tunnels up.
Either the isp or something in the fortinet were blocking other ports after a while.