Skip to main content
Wuschy
Wuschy
New Member
October 13, 2016
Solved

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

  • October 13, 2016
  • 2 replies
  • 39121 views

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

Best answer by Toshi_Esumi

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?

2 replies

Toshi_Esumi
SuperUser
Toshi_EsumiAnswer
SuperUser
October 13, 2016

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
WuschyAuthor
New Member
October 14, 2016

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

cfyeung
cfyeung
New Member
October 18, 2016

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.

Wuschy
WuschyAuthor
New Member
October 18, 2016

Hi Ken,

 

Again many thanks for your help! I really appreciate it!

So far I face these problems with your hints:

1. I have no Cisco Switches, only HP which aren't capable of the IP SLA-feature, so I can't do these measures. But just to remind you: we have no poor voice calls! The calls itself are perfect (except when dropped ;)) But the phones on site B just disconnect sometimes!

2. The "diag sys session filter | greps bps=" gives no output so far (my VoIP Policy is #9 so I set this "diag sys session filter policy 9"

3. The ESP-Replay window is enabled but no dropped ESP packets found so far

4. Sometimes we have a bad connection surfing the web but voice calls works without any issues, so I assume the traffic shaper is working as expected... so far the fortigate doesn't show high load, but when temporary disabling Web-Filter surfing is working normaly again so I think its dependent to the fortigate load!

 

PCAP capturing on both ends is exactly what I did but only shows that packets are sent on one side but not received on the other so i'm really stuck here :(

 

Many thanks and best regards

emnoc
emnoc
New Member
October 18, 2016

 

 

 

PCAP capturing on both ends is exactly what I did but only shows that packets are sent on one side but not received on the other so i'm really stuck here :(  

 

To mimic  CSI Miami "Follow the evidence  !".

 

 

Since you have a one-way no packets issue,  start from that side and work outwards. The question are why no packets ? Is this  SIP ( signaling ) or  Voice Path related ( RTP stream ).

 

Have you monitor any   SIP related  status.response from either end? Do you have any CAC limits ( Call Admission Controls ) or any  Session Expiration issues? Do you have the VoIP in the middle or does the  call peers terminate end-2-end ( 2 leg no voipPBX or legs terminates to a voicePBX ). Was this site before hand and correctly? is it a new site ?

 

Are all fortigate running the same OS ?

 

Are all phones running the same firmware?

 

Are calls being terminate  correcting within SIP protocols  ( e.g a BYE and CANCEL are really not the same thing )

 

if you subscribe to a free  SIP provider, and test from the same side that has the re-ocurring issues, do you see same or similar issues.?

 

And finally, most modern  SIP termination devices have  diagnostic or call details statistics that's available on the phone.  

 

Since the problem as you describe it sound sporadic and hit-or-miss.  I don't think it's the firewall.

 

It sounds like it could be CAC, SIP.KeepAlives  or something else. Could be even  SIP authentication once again  sip.status response will give you clues. If you have a software client with  diagnostic/logging , I would enabled it at the problem site and test using that client.

 

Since the phones are   going on and offline, have you looked at the SIP.KA values and the  fwpolicy session-ttls? Set them for a weird and long value and re-monitor.

 

take a look at this;

 

http://socpuppet.blogspot.com/2015/05/sip-registering-issues-cisco-asa.html

 

It's cisco ASA specific but the same concepts applies regardless of the  firewall device.

 

 

And if you have any mangles SIP  headers;

 

http://socpuppet.blogspot.com/2014/09/a-sip-request-header-gotchas.html

 

 

And lastly, I had a problem that I recall with lucent devices and we found out a few device upgraded  the phone itself was the culprit but as usual we ( Firewall team was initially blamed ) ;)

 

So don't rule out anything is all that I can add.

 

 

;)

 

 

ken

 

 

 

 

 

Terms & ConditionsAccessibility statement