Enabling SIP on Fortinet devices

Yesterday (08/08/2013) I came across an issue whereby a set of users had migrated from a standard DSL connection to a VLAN within our corporate network, which resulted in a strange issue with their VoIP phones.

After the migration was complete the users were able to place calls successfully BUT when receiving calls the users were able to hear to the caller but the caller was unable to hear the receiver.  the caller would hear the call ringing then being collected, at this point the line would then seem as if it was dead.  After a bit of investigation it appeared that inbound voice traffic was being blocked for some reason.

The CauseThe cause of this issue appears to be a session-helper which is enabled by default on Fortinet devices.  We tested on two Fortinet devices and the issue was replicated over both Fortinet models.   The devices tested where:
  • Fortigate 20c ADSL router
  • Fortigate 300c Firewall
The Permanent Fix

To resolve the issue we had to complete the following:
    • SSH onto Fortinet device
    • Run the following command:
      • show session-helper
    • Use the spacebar to navigate through the list of session-helpers, locate sip and take note of the ID.  ID 13 in my case:
      • edit 13
      • set name sip
      • set port 5060
      • set protocol 17
      • next
    • Run the following commands to remove this session-helper
      • config session-helper
      • (session-helper) delete 13
      • (session-helper) end
    • Reboot Fortinet device in order for the above changes to take effect
The above sequence were the only steps I had to complete to get the inbound voice calls to fully work.  If you continue to have issues after completing the above steps then please take a look at the official Fortinet Knowledge Base entry:

Fortinet Devices - Enabling the SIP Application Layer Gateway (ALG)

Comments

Post a Comment

Popular posts from this blog

Add Multiple Alias Email Addresses to Exchange Online/Office 365 Mailbox

I will keep the BS short for this one BUT there are a few points to mention.  Please read as it will save you time in the long run! When running through this process you MUST specify ALL email addresses that are to be associated with the mailbox you are updating It will overwrite anything that currently exists within the Email Addresses section When specifying the email addresses be sure to pay attention to SMTP and smtp Being an absolute 1337 n00b myself, I originally ran through the process to add additional email aliases to the mailbox.  Unbeknownst to me at the time, running through this process completely overwrites what is associated with the mailbox.  So, my advice?  Create the entire Set-Mailbox  string for all email addresses before starting the process. Anyway, onto the process! If you want to add multiple alias email addresses to an Exchange Online/Office 365 account run through the following: Open Powershell Type the following comman...
Read more

WHM/cPanel/Exim Mail Server // Relaying email for specific domain(s) or email address to SMTP Smart Host or remote SMTP server

As with most of my posts, scroll to the Solution  section if you are only here for a quick fix.  BUT be sure to check out the Examples at the end of the post!    WARNING:  You will bypass my attempts at humour to make this read interesting if you skip! I recently came up against a scenario whereby a client who uses a WHM/cPanel server as a dedicated mail server.  Fine.  Easy Peasy, no issues there. These guys wanted to relay their mail through an online service for reporting and reputation reasons.  Fine, again, simple. Naive little me thought "Simple, all I gotta do is log into WHM and tell Exim where to push the mail in their sweet little web interface".  Turned out to be not so straight forward. The Scenario (long-story-short) Client uses WHM/cPanel system as dedicated mail server (Exim) Wanted to send email for specific domain to specific IP address Wanted to relay all other outbound mail via 3rd party relay serv...
Read more

Re-instating "Send As" privilege Windows 2003 Server // GOOD ForEnterprise

You may recall that I had a wonderful time troubleshooting issues with the GOOD for Enterprise service, whereby user's GOOD profiles were falling into a paused state as the service was unable to successfully send emails from the user's Android & iOS apps. GOOD For Enterprise have now outlined a permanent fix for this issue. Using the following fix will re-instate the Send As permissions for the required user accounts that the GOOD app uses to remotely send emails from their handheld apps, therefore eliminating the need to go through the workaround which I had outlined in my previous post . The Permanent Fix In order to achieve a permanent fix for this issue we need to re-instate the Send As ability that the required user accounts had before a certain Windows update removed this right, this is done using the DSACLS utility. The syntax for the correct command is as follows: dsacls "cn=adminsdholder,cn=system,dc=domainname,dc=com" /G "\GoodAdmin:CA;S...
Read more