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

VoIP Problems

Hi

 

My first post, so go easy on me...;)

 

We have a client with a Fortigate 50E running firmware 5.6.8 build 1672 (GA). On the LAN side of the network they have just installed an LG Ipecs PBX phone system. This has a fixed IP of 6.0.1.150.

 

The issue is this;

When a LAN side user makes a call to an external destination, the external destination cannot hear the LAN side caller. The LAN side caller can hear the external user. If an external user calls a LAN side user, everything is fine.

 

The setup:

 

I have created multiple Virtual IP's that port forward all the relevant UDP/TCP traffic to the PBX and added them to a Virtual IP Group called LG_Phone_System

 

I have create the following inbound policy;

 

Incoming Interface: WAN1

Outgoing Interface: LAN

Source: all

Destination: LG_Phone_System (VIP Group)

Schedule: Always

Action: Accept

NAT: Enabled

 

There are no security profiles applied to this rule.

 

I have created the following outbound policy;

 

Incoming Interface: LAN

Outgoing Interface: WAN1

Source: LG_PBX (this is defined as an address object using 6.0.1.150/32 )

Destination: All

Schedule: Always

Action: Accept

NAT: Enabled

 

There are no security profiles applied to the rule

 

I have ran the following commands on the CLI to disable the SIP ALG

 

Config system settings

Set sip-helper disable

Set sip-nat-trace disable

 

config system session-helper

show

delete 13 (SIP Entry)

 

config voip profile

edit default

config sip

set rtp disable

 

config system settings

set default-voip-alg-mode kernel-helper-based

 

Have rebooted several times but always have the issue outlined at the top. If I replace the Fortigate with a Draytek 2672 everything works fine.

 

I would welcome any help. I have put in a support ticket with Fortinet but haven't had any response for four days, so hoping for better luck on here.

 

kind regards

 

Phil

 

kind regards Phil

 

4 REPLIES 4
Looki
New Contributor

Got same issue, did You find out solution?

Grave_Rose
New Contributor III

Hey Phil M and Looki,

 

I don't have experience with this specific VoIP solution but here are some things you can try... These will take a while but they will eventually help solve your issue so get some coffee. :)

 

[ol]
  • Check the logs to see if there are any drops. If you're using a FortiManager, make sure that your clean-up rule is being logged as well. Hopefully this will tell you the information but odds are, you've already looked a million times and nothing of value is being seen.
  • Get a list of protocols and ports that the VoIP system uses. I'll use TCP/1234 and UDP/5678 for my examples but I know you'll probably have a lot more. Also, my example server is at 10.20.30.40 off port1 on the internal network.
  • Pick the first protocol/port pair and run some packet captures. If you can, run these at the same time while SSH'd into the FortiGate:[ol]
  • diagnose sniffer packet port1 'host 10.20.30.40 and (tcp and port 1234)' 6 10
  • diagnose sniffer packet wan1 'host 6.0.1.150 and (tcp and port 1234)' 6 10[/ol]
  • You want to make sure that you see the SYN packet arrive on the internal interface and leave correctly out of the external interface. If it does, move to the next protocol/port combination. If not, move to the next step to debug the issue.
  • Assuming TCP/1234 works and UDP/5678 fails, run this series of commands:[ol]
  • diagnose debug disable diagnose debug flow trace stop diagnose debug flow filter clear diagnose debug reset diagnose debug flow show function-name enable diagnose debug flow show iprope enable diagnose debug flow filter addr 10.20.30.40 diagnose debug flow filter proto 17 diagnose debug flow filter port 5678 diagnose debug flow trace start 3 diagnose debug enable[/ol]
  • Attempt your call again and capture the debug logs. Turn off the debugs with "diagnose debug disable".[/ol]

    With the debug logs you've captured, you should be able to learn more about what's happening on the 'Gate itself.

     

    I know troubleshooting VoIP is a PITA and I'm sorry I don't have the immediate answer to fix this out of the box but hopefully this will put you on the right path.

     

    Good luck!

     

    Sean (Gr@ve_Rose)

  • Site: https://tcpdump101.com Twitter: https://twitter.com/Grave_Rose Reddit: https://reddit.com/r/tcpdump101 Discord: https://discordapp.com/invite/2MZCqn6
    brycemd

    I would typically disable NAT on the WAN > LAN rule

     

    Also, you may need to disable the VOIP profile whereas you only disabled rtp:

     

    config voip profile edit default config sip

    set status disable

     

    Or, it's not always full disabling of SIP ALG that's required. There are occasions where you need to disable most of it, but leave the voip profile and rtp enabled.

     

    emnoc
    Esteemed Contributor III

    I'm confused

     

    Why did you disable the SIP ALG ? And how would expect the fortigate to work ?

     

    Did you read the FTNT KB . https://kb.fortinet.com/kb/documentLink.do?externalID=FD36405

     

    FWIW, I'm on FWE50E ( 6.0 ) and have the same setup ( but in reverse ) and with sip-alg enable 

     

    If you look at the SIP invite and media-port the rtp-stream is broken since the firewall has not open the dynamic pinhole that's is  required for SIP.

     

    Also double check if you  SIP signaling is or not using std 5060 port.

     

    Ken

    PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    Announcements

    Select Forum Responses to become Knowledge Articles!

    Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

    Labels
    Top Kudoed Authors