Fortigate SIP ALG / Fortinet SIP ALG

FortiOS has two features that can modify the SIP headers and SDP parameters. The first feature is called the “SIP Session Helper”. If you are experiencing one way audio issues disable this feature first, reboot your IP phone then try making another call. If disabling the session helper does not work, disable the SIP ALG as well.

To disable the sip session helper:

1 Enter the following command to find the sip session helper entry in the session-helper list:

show system session-helper

edit 10
set name sip
set port 5060
set protocol 17

2 Enter the following command to delete session-helper list entry number 10 to disable the sip session helper:

config system session-helper
delete 10

To disable the SIP ALG:

There are typically two VOIP profiles on a factory shipped Fortinet firewall. You may need to disable both profiles to fully stop the ALG.

config voip profile
edit VoIP_Pro_2
config sip
set status disable
end
end

See the Fortigate Technical documentation page for further details.

SIP ALG – General Overview

 

SIP ALGs have been added to most small office / home office ( SOHO) routers over the past few years. SIP is notorious for having issues with Network Address Translation (NAT) and the ALGs are the solution offered by most vendors.

One of the reasons that  NAT and SIP do not play well is that ports need to stay open for a long period of time. Take the below registration message as an example.  Notice the “Contact” in the headers. The expiration timer is set at 3600 seconds. This means that every hour my soft phone will attempt to register with the proxy.

 

Request-Line: REGISTER sip:proxy.sip.test SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.168.34.132;rport;branch=z9hG4bKebbzhcmh
Max-Forwards: 70
To: “keithtest” <sip:keithtest@proxy.sip.test>
From: “keithtest” <sip:keithtest@proxy.sip.test>;tag=afrlz
Call-ID: jgatcznxemdrtux@croxford1
CSeq: 496 REGISTER
Contact: <sip:keithtest@192.168.34.132>;expires=3600
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
User-Agent: Twinkle/1.4.2
Content-Length: 0

 

It just so happens that my router will close any NAT pinholes after 60 seconds or inactivity.  Once the 60 seconds have lapsed my phone will not be able to communicate with the proxy. The phone will wait  for an additional fifty nine minutes  then send a registration message.  During this time if an inbound call or a SUBSCRIBE / NOTIFY event is sent to my phone it will not make it through the firewall and the call will be rejected.

 

Most service providers combat this by sending an acknowledgement to the REGISTER with a  lower expiration timer:

 

Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 192.168.34.132;branch=z9hG4bKihfnwefm;rport=5060
To: “keithtest” <sip:keithtest@proxy.sip.test>;tag=aprqg7m9pp1-gmmvhl200g0i0
From: “keithtest” <sip:keithtest@proxy.sip.test>;tag=qlhos
Call-ID: jgatcznxemdrtux@croxford1
CSeq: 521 REGISTER
Contact: <sip:keithtest@192.168.34.132>;expires=45

 

The provider has replied with an expiration time of 45 seconds.  As this is lower than the 3600 seconds from the original request, the phone will register as requested by the proxy.

If the provider does not have a Session Border Controller or proxy controlling the expiry timer, your NAT pinholes are going to close.  If a SIP ALG is in place on the router it may attempt to register >= 10 seconds prior to the NAT pinhole closing.  This should keep the registration active.

 

What about audio?

 

One way audio is a common issue in VOIP environments.  Besides the VIA and Contact headers, media is controlled by the Session Description Protocol (SDP). The SDP defines which ports RTP will use for audio. It will define the IP address for audio packets, codec preference and many other attributes.  In the below INVITE, scroll down to the Session Description Protocol section.

Session Initiation Protocol
Request-Line: INVITE sip:4801001001@proxy.sip.test SIP/2.0
Message Header
Via: SIP/2.0/UDP 192.168.34.132;rport;branch=z9hG4bKuukvcokj
Max-Forwards: 70
To: <sip:4801001001@proxy.sip.test>
From: “keithtest” <sip:keithtest@proxy.sip.test>;tag=xghqr
Call-ID: hosfhlkkboehkga@croxford1
CSeq: 155 INVITE
Contact: <sip:keithtest@192.168.34.132>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.4.2
Content-Length: 312

>Session Description Protocol
>Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): twinkle 457748375 1076164210 IN IP4 192.168.34.132
Session Name (s): –
Connection Information (c): IN IP4 192.168.34.132
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 20000 RTP/AVP 98 97 8 0 3 101
Media Attribute (a): rtpmap:98 speex/16000
Media Attribute (a): rtpmap:97 speex/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:3 GSM/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20

 

While other fields are important, we are specifically looking at the “Connection Information” . Notice the IP address of “192.168.34.132”. This is an RFC1918 address and not routable on the Internet.  This is essentially my phone saying “when you send me audio packets, send them to this private address”. This is fine, assuming that a bidirectional route to the other call agent is present.  If the other end replied with the Connection Information of “4.2.2.1” somthing similar to the below would happen.

Request : Soft-phone >> NAT Router >>  Internet  >> 4.2.2.2 (Audio is received)

Reply :     4.2.2.2 >> No route to the other host >> (Audio is dropped)

A SIP ALG will take the “Connection Information” and replace the RFC1918 address with a public IP address.  It will also change the VIA and Contact headers to reflect the same IP address :

 

Session Initiation Protocol
Request-Line: INVITE sip:4801001001@proxy.sip.test SIP/2.0
Message Header
Via: SIP/2.0/UDP 70.162.1.1 rport;branch=z9hG4bKuukvcokj
Max-Forwards: 70
To: <sip:4801001001@proxy.sip.test>
From: “keithtest” <sip:keithtest@proxy.sip.test>;tag=xghqr
Call-ID: hosfhlkkboehkga@croxford1
CSeq: 155 INVITE
Contact: <sip:keithtest@70.162.1.1>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.4.2
Content-Length: 312
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): twinkle 457748375 1076164210 IN IP4 192.168.34.132
Session Name (s): –
Connection Information (c): IN IP4 70.162.1.1
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 8000 RTP/AVP 98 97 8 0 3 101
Media Attribute (a): rtpmap:98 speex/16000
Media Attribute (a): rtpmap:97 speex/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:3 GSM/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20

 

In the above example the ALG also modified the audio port. Originally it was “20000” and the ALG changed it to “8000”. Assuming that the proxy does not use a method to detect  private IP addresses you should be in good shape. Call control should be functional and bi direction audio present.

 

If your service provider (or enterprise proxy)  utilizes an SBC,  the ALG will need to be disabled.  There is no need to have both ends of the connection making changes to the IP addresses and ports.  If an SBC is in place and you are a running a SIP ALG, I can almost guarantee problems.

 

 

 

SIP ALG – DLINK DIR-625

To disable the SIP ALG on a DLINK DIR-625 follow the below steps.

1. Log into the router.  The default user name on this model is “Admin” with a blank password.

2. Click on “Advanced” at the top of the screen.

3. Click on “Firewall Settings” on the left.

4. Scroll down toward the bottom. You will see the “Application Level Gateway (ALG)” section.

5. Remove the check mark next to “SIP”.

6. Scroll up to the top and click on “Save Settings”.

7.  The next screen should ask you to reboot the firewall. Reboot it.

8. Reboot your IP phone. Your provider should now see the phone registered properly.

 

SIP ALG – Zyxel

Zyxel equipment is often deployed by DSL providers such as Qwest and Century Link.  If you are using a VOIP telephone and experiencing call control or audio issues you may need to disable the SIP ALG feature.

1. Telnet into the router from your LAN.

2. Select menu 24.

3. Select menu 8.

4. To display current SIP ALG  status type in  “ip nat service sip active”.

5. If it returns a value of “1” the SIP is enabled.

6. To turn off the SIP ALG type in “ip nat service sip active 0”.

7. Reboot your VOIP phones.

SIP ALG – SonicWall

SonicOS has a feature called SIP Transformations that may cause issues with your VOIP end points.  Providers will often ask you to disable this setting if you are experiencing call control or quality issues.

To disable SIP Transformations:

1. Log into the web interface on the SonicWall.

2. On the left, find the VOIP tab. Depending on the version of SonicOS your screen may appear slightly different.

3. Make sure that ALL of the options are unchecked on this page.

* Prior to clicking on apply, make sure that there are no active calls. They will be disconnected or audio will be lost.

4. Click on “Apply”.

5. Reboot your VOIP endpoints.

 

**** UPDATE – TZ170 12/8/2011****

I recently needed to have someone enable “Consistent NAT” to resolve a call control drop issue.  Our soft switch would send a SIP UPDATE packet to the IPT at roughly 10 minutes into the call.  After no response from the IPT behind the TZ170 the call would drop. After further investigation I found that  the port used for call control was changed by the Sonicwall at about 9 minutes 30 seconds.

After enabling Consistent NAT calls would stay established until either the called or calling party disconnected the call.

SIP ALG – Cisco ASA (Version 7)

Most ASAs will have the “inspect sip” statement listed in the default policy-map.   Some service providers will recommend disabling this feature.

1. Log into the ASA through SSH, telnet or the console.

2. Once authenticated, move into “enable mode” by typing “enable”.

================================

ASA> enable
Password:

================================

3. Enter your password.

4. Type “show run policy-map”.  This will display all of the relevant details current policy-maps.

================================

ASA# sh run policy-map
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy <——————- “global_policy” is the name of the policy-map used here.
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect icmp
!
ASA#

=========================

5. If you see the “inspect sip” statement the ASA will keep track of the UDP ports used for call control (default of 5060). It will also keep track of the UDP ports used by RTP (audio packets).

6. If your service provider recommends turning this feature on, then make no changes.

7. If the feature needs to be disabled and your policy-map is named “global_policy” you can use the below script.  You MUST be in enable mode to copy and past this.

==================

!

configure terminal

policy-map global_policy
class inspection_default
no inspect sip
exit
exit
exit
write mem

=================

SIP ALG – Linksys BEFSR41

I have come across a number Linksys BEFSR41 routers that have a SIP ALG enabled on them. I have not been able to narrow this down to a specific firmware. When looking at the admin interface it doesn’t specifically state anything about the ALG feature.  When looking a packet capture however, the SDP has clearly been modified as well as various headers.

When the SDP is modified this could cause one way audio issues, especially if your provider utilizes a Session Border Controller (it’s a type of VOIP firewall) that handles NAT traversal.  When the headers are modified, call control (making and receiving calls) could be affected.

The SIP ALG can be bypassed with the below steps :

1. Log into the web interface of the Linksys.

2. Click on “Applications and Gaming”

3.  Click on “Port Triggering”

4. In the “Application” field type “SIP”.

5. Set the “Start Port” and “End Port” fields to “5060”.

6. If your service provider allows a secondary registration port, create that as a new application. As you can see above I am using port “5058” .

7. Reboot your SIP phones.