FortiGate 60D Site-to-Site VPN loses VoIP packets

[Wuschy]

Hi all,

I'm very new to this forum so I want to say hello to everyone first and I'd be very happy if I can get some help here :)

We have 4 Sites, all connected to each other (mesh) via Site-to-Site IPsec VPN Tunnels. Everything works without problems except one thing:

Let's say site B is using VoIP phone system over site A. In site A all phones are working without interruptions, but site B faces the issue of phones go offline and then reconnecting themselves. I monitored with the sniffing option and found that VoIP packets some-when just aren't transmitted for at least 40s. Usually it's running fine, they can do phone calls etc. but then irregularly packets aren't sent anymore.

I've monitored the connection between the phone system (192.168.8.30) and one desk phone (192.168.12.50). In the attached picture you can see the packets which are transferred (left side is site A, right side is site B).

For any help to find out more about this problem I'd be very happy as this is very annoying :(

If you need more information, just let me know! The tunnels are set up to allow traffic between sites without any logging / filters or anything like this. The only thing is a traffic shaper which gives priority to the VoIP.

Thanks and best regards

Wuschy

[Toshi_Esumi · Accepted solution]

Are there any bandwidth saturation points in-between? In other words, when you keep pinging one subnet to the other, do you lose any responses when VoIP packets stop flowing?

[Wuschy]

No, no ping packets are lost (sorry, I could have written this, as it was the first thing I tested :))

[Wuschy]

In the mean time I made another test:

Pinging while sniffing to see the issue live! (see attachment) The green side is Site A, blue side Site B. Time on Site B is delayed by about 1s, but you can see that we have Ping Packets delivered from Site A to Site B (which are received) and undelivered SIP packets on Site A!

Many thanks for any help :)

[Toshi_Esumi]

Then SIP session helper or ALG might be acting up. Have you put the measure in place to disable it?

http://kb.fortinet.com/kb/documentLink.do?externalID=FD36405

[emnoc]

 I high doubt it's a session helper since you say it  works but you have intermit problems.

If you have PLOS ( packet loss ) that needs to be corrected 1st. Plos is going to  be ready found with  SLA check , ping ( as what you did none  ) and will show up in lost SPI sequnces between von-peers.

Going back to what was asked earlier, do you have any link saturation issues at the time of the interruptions? Do you have any QoS priority queuing set to  allow EF  for real-time  traffic?

[Wuschy]

Hi,

Many thanks for feedback. As far as I know, I already implemented this. How-ever, I'm not 100% sure about the second step. And it looks like I can't "get" the default-voip-alg-mode, so I just did it again. Will reboot the FWs today evening and let you know latest by end of this week if it helped!

Best regards

[Wuschy]

Hi Emnoc,

Many thanks for your feedback too! I feel like a greenhorn as I need a little more help on this!

What exactly do you mean by "SLA check" and how can I find lost SPI sequences?

Last thing I did was according to this instruction:

http://kb.fortinet.com/kb/documentLink.do?externalID=FD33101

But no invalid ESP packets were found!

Can you describe what you mean by link saturation issues?

Where can I check the QoS Queuing? The traffic shaper monitor shows "No data" which surprises me a bit!

Best regards & many thanks for your help

[emnoc]

What exactly do you mean by "SLA check" and how can I find lost SPI sequences? Last thing I did was according to this instruction: http://kb.fortinet.com/kb/documentLink.do?externalID=FD33101 But no invalid ESP packets were found!

 You can build a link-monitor on the fortigate or if you have any modern  cisco or similar switches you can craft a   IP-SLA and with traffic flow matching the VoIP packets  ( i.e TOS packetsize,etc....). Cisco IP-SLA would be the best approach for finding  or alerting on poor voice bearer path

reference my blog post

http://socpuppet.blogspot.com/2014/11/using-cisco-ip-sla-for-udp-jitter-and.html

for traffic  bw usage;

http://socpuppet.blogspot.com/2014/09/howto-find-out-how-many-bps-policy-is.html

For dropped   ESP packets it best to  conduct spot-checks with packet captures, than play them back via wireshark/tshark with the  esp  display filter ( esp.sequence ). You will have to do some work to find out if you have dropped but a  few clues are;

refernce

http://socpuppet.blogspot.com/2015/02/esp-replay-window-enabling-disable.html

1: when the SEQ# is skipped or missed  that's a dropped ( check bi-directional )

2: when the  SEQ#  is out-of-order that's not a dropped just packets out-of-order probably due to multi-path routes or other layer3 issues

Can you describe what you mean by link saturation issues? Where can I check the QoS Queuing? The traffic shaper monitor shows "No data" which surprises me a bit!  

During the time of poor or dropped voice calls, hows your internet uplinks on bandwidth? Do you  apply  any priority for voice traffic flows for the call-path.

You will have todo some investigative work but if you can conduct a pcap capture on both ends, you can easily find out if drops are occurring and in what direction. Drops are going to be a big headache and reduce MoS scores.

Ken

[cfyeung]

Same problem here, two sites connected with 60D IPsec VPN. The VPN tunnel stays up and running. But, the VPN tunnel stops passing traffic, about 3 ping drops, sometimes, which is a headache for real-time voice traffic (no sound or even IP Phone reboots). In the mean time, both sites' WAN and LAN interfaces are good and diag debug app ike -1 shows nothing wrong.