Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
supportombm
New Contributor III

VoIP Problem over SD-WAN

Hi Everyone! 

This is my first post, sorry if i'm in the wrong category.

I have a problem with VoIP over SD-WAN. Let me explain

FG50E With 6.2.3 , A telephone exchange who manage all the SIP traffic and register to a cloud server (from now on SBC).

I have 1 ISP Provider who provide FIber (WAN1) and ADSL (WAN2) (Backup line)

It was doing great for 2 months (was 6.2.1), data and VPN over WAN1 and VoIP over WAN2, but one day all the telephones stopped working, no inboud call and no outgoing call. After hours of troubleshooting we noticed that if we move all VoIP traffic to WAN1 the SBC start registering again and everything started working so we did this to let our client work.

Now even if I created a SD-WAN rule to force SBC (and all VOIP traffic) over WAN2. The weird thing is despite this rule and despite it shows that the SBC is using WAN2 (in fortiview),  from a packet capture i see that only some UDP packet use WAN2 and everthing else (SIP,RTP) is using WAN1!

The problem is, if WAN1 stopped working the VoIP won't work with WAN2 (i've managed even try to disable WAN1 and let everything on WAN2 but nothing happened and VoIP still don't work).

https://kb.fortinet.com/kb/viewContent.do?externalId=FD36405&sliceId=1 this was done since beginning

Now as i said I upgraded to 6.2.3 (which is more stable than 6.2.1) 

https://www.reddit.com/r/fortinet/comments/ccbo0l/voip_phones_and_sd_wan_mystery/ i found this that is similar i think.

 

Sorry for being a bit confusional, i have fever too so thanks everyon who can help!

12 REPLIES 12
supportombm

toshiesumi wrote:

Since you already disabled SIP session-helper&ALG, likely the SD-WAN is causing the symptom. Your description was not clear about the timings when VoIP stopped working and when you upgraded it to 6.2.3. Did you upgraded after it stopped working?

For virtually all SD-WAN issues, without seeing actual config for rules and routing-table, and debugging output at the time, then eventually sniffing the traffic on the interface, it's very difficult to even guess what's going on. Besides, when I tried upgrading my home 50E from 6.0.7 to 6.2.3 it was somewhat unstable, so I immediately went back (actually upgraded to 6.0.8 after that).

So, your best chance is to let TAC look at it by opening a ticket. Another SD-WAN case in the forum, they changed OP's set-up to mitigate a bug.

VoIP stopped working random day to day (like a month ago) yesterday i upgraded to 6.2.3 from 6.2.1 (i know it was a mistake using 6.2)

i can make print screen of something if it helps

SIP and RTP packets just use WAN1 (fiber if it's online) and when (adsl, like now while i was troubleshooting) WAN1 is disabled by me SIP packets pass cause i see the SIP registering session and there are some registering packets via packet capture and diag sniff, but no answer from SIP Server.

SD_WAN rule is easy Everything from SBC go to WAN2  

img 1 :https://ibb.co/1vWQqbz (packet when WAN1 is down and SBC try use WAN2)

img 2: https://ibb.co/2Y3kvqH (session with SBC using WAN1, same happen if use WAN2)

but as i said WAN1 is okay WAN2 nope...

In the reddit link a user DarkVaderIT if i recall it suggests that could be a provider issue.

EDIT:

I noticed that in the IMG 1 which is a packet capture from WAN2 (10.0.1.2) the source ip is the ip of WAN1. and in the header of the packet SIP i can read that the IP for the login to SIP server is the WAN1 public IP

supportombm

I noticed another weird thing, in the packet from WAN2

this https://ibb.co/wQ3G10G

in "Ethernet II" the Src mac address the the correct interface, but the ip in "Internet Protocol Version 4" the IP is wrong, should be 10.0.1.2

 

FarinaAhmed
New Contributor III

To resolve the issue with VoIP traffic not properly using WAN2 despite the SD-WAN rule, follow these steps:

  1. Verify SD-WAN configuration.
  2. Review firewall policies.
  3. Test with specific IP address.
  4. Check NAT and port forwarding.
  5. Monitor traffic and logs.
  6. Consider firmware upgrades.
  7. Engage Fortinet support if needed.
Farina Ahmed
Farina Ahmed
Labels
Top Kudoed Authors