Skip to main content
Phil_M
Phil_M
New Member
March 22, 2019
Question

VoIP Problems

  • March 22, 2019
  • 1 reply
  • 18486 views

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

 

    1 reply

    Looki
    Looki
    New Member
    July 4, 2019

    Got same issue, did You find out solution?

    Grave_Rose
    Grave_Rose
    New Member
    July 4, 2019

    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)

    • brycemd
    brycemd
    New Member
    July 4, 2019

    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.

     

    Terms & ConditionsAccessibility statement