How the SIP ALG performs NAT

In most Network Address Translation (NAT) configurations, multiple hosts in a private network share a single public IP address to access the Internet. For sessions originating on the private network for the Internet, NAT replaces the private IP address of the PC in the private subnet with the public IP address of the NAT device. The NAT device converts the public IP address for responses from the Internet back into the private address before sending the response over the private network to the originator of the session.

Using NAT with SIP is more complex because of the IP addresses and media stream port numbers used in SIP message headers and bodies. When a caller on the private network sends a SIP message to a phone or SIP server on the Internet, the SIP ALG must translate the private network addresses in the SIP message to IP addresses and port numbers that are valid on the Internet. When the response message is sent back to the caller, the SIP ALG must translate these addresses back to valid private network addresses.

In addition, the media streams generated by the SIP session are independent of the SIP message sessions and use varying port numbers that can also change during the media session. The SIP ALG opens pinholes to accept these media sessions, using the information in the SIP messages to determine the pinholes to open. The ALG may also perform port translation on the media sessions.

When an INVITE message is received by the SIP ALG, the FortiGate extracts addressing and port number information from the message header and stores it in a SIP dialog table. Similar to an IP session table the data in the dialog table is used to translate addresses in subsequent SIP messages that are part of the same SIP call.

When the SIP ALG receives a response to the INVITE message arrives, (for example, an ACK or 200 OK), the SIP ALG compares the addresses in the message fields against the entries in the SIP dialog table to identify the call context of the message. The SIP ALG then translates addresses in the SIP message before forwarding them to their destination.

The addressing and port number information in SDP fields is used by the ALG to reserve ports for the media session and create a NAT mapping between them and the ports in the SDP fields. Because SDP uses sequential ports for the RTP and RTCP channels, the ALG provides consecutive even-odd ports.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Accepting SIP register responses

You can enable the VoIP profile open-via-pinhole options to accept a SIP Register response message from a SIP server even if the source port of the Register response message is different from the destination port.

Most SIP servers use 5060 as the source port in the SIP register response. Some SIP servers, however, may use a different source port. If your SIP server uses a different source port, you can enable open-via-pinhole and the SIP ALG will create a temporary pinhole when the Register request from a SIP client includes a different source port. The FortiGate will accept a SIP Register response with any source port number from the SIP server.

Enter the following command to enable accepting any source port from a SIP server:

config voip profile edit VoIP_Pro_1 config sip set open-via-pinhole enable

end

end

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Opening and closing SIP register, contact, via and recordroute pinholes

You can use the open-register-pinhole, open-contact-pinhole, open-via-port, and openrecord-route-pinhole VoIP profile CLI options to control whether the FortiGate opens various pinholes.

If open-register-pinhole is enabled (the default setting) the FortiGate opens pinholes for SIP Register request messages. You can disable open-register-pinhole so that the FortiGate does not open pinholes for SIP Register request messages.

If open-contact-pinhole is enabled (the default setting) the FortiGate opens pinholes for non-Register SIP request messages. You can disable open-contact-pinhole so that the FortiGate does not open pinholes for non-register requests. Non-register pinholes are usually opened for SIP INVITE requests.

If open-via-pinhole is disabled (the default setting) the FortiGate does not open pinholes for Via messages. You can enable open-via-pinhole so that the FortiGate opens pinholes for Via messages.

If open-record-route-pinhole is enabled (the default setting) the FortiGate opens pinholes for RecordRoute messages. You can disable open-record-route-pinhole so that the FortiGate does not open pinholes for Record-Route messages.

Usually you would want to open these pinholes. Keeping them closed may prevent SIP from functioning properly through the FortiGate. They can be disabled, however, for interconnect scenarios (where all SIP traffic is between proxies and traveling over a single session). In some cases these settings can also be disabled in access scenarios if it is known that all users will be registering regularly so that their contact information can be learned from the register request.

You might want to prevent pinholes from being opened to avoid creating a pinhole for every register or nonregister request. Each pinhole uses additional system memory, which can affect system performance if there are hundreds or thousands of users, and requires refreshing which can take a relatively long amount of time if there are thousands of active calls.

To configure a VoIP profile to prevent opening register and non-register pinholes:

config voip profile edit VoIP_Pro_1 config sip set open-register-pinhole disable set open-contact-pinhole disable

end

end

In some cases you may not want to open pinholes for the port numbers specified in SIP Contact headers. For example, in an interconnect scenario when a FortiGate is installed between two SIP servers and the only SIP traffic through the FortiGate is between these SIP servers pinholes may not need to be opened for the port numbers specified in the Contact header lines.

If you disable open-register-pinhole then pinholes are not opened for ports in Contact header lines in SIP Register messages. If you disable open-contact-pinhole then pinholes are not opened for ports in Contact header lines in all SIP messages except SIP Register messages.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

SIP and RTP/RTCP

FortiGates support the Real Time Protocol (RTP) application layer protocol for the VoIP call audio stream. RTP uses dynamically assigned port numbers that can change during a call. SIP control messages that start a call and that are sent during the call inform callers of the port number to use and of port number changes during the call.

During a call, each RTP session will usually have a corresponding Real Time Control Protocol (RTCP) session. By default, the RTCP session port number is one higher than the RTP port number.

The RTP port number is included in the m= part of the SDP profile. In the example above, the SIP INVITE message includes RTP port number is 49170 so the RTCP port number would be 49171. In the SIP response message the RTP port number is 3456 so the RTCP port number would be 3457.

 

How the SIP ALG creates RTP pinholes

The SIP ALG requires the following information to create a pinhole. The SIP ALG finds this information in SIP messages and some is provided by the SIP ALG:

Protocol	UDP (Extracted from SIP messages by the SIP ALG.)
Source IP	Any
Source port	Any
Destination IP	The SIP ALG extracts the destination IP address from the c= line in the SDP profile. The c= line can appear in either the session or media part of the SDP profile. The SIP ALG uses the IP address in the c= line of the media part of the SDP profile first. If the media part does not contain a c= line, the SIP ALG checks the c= line in the session part of the SDP profile. If the session part of the profile doesn’t contain a c= line the packet is dropped. Pinholes for RTP and RTCP sessions share the same destination IP address.
Destination port	The SIP ALG extracts the destination port number for RTP from the m= field and adds 1 to this number to get the RTCP port number.
Lifetime	The length of time during which the pinhole will be open. When the lifetime ends, the SIP ALG removes the pinhole.

The SIP ALG keeps RTP pinholes open as long as the SIP session is alive. When the associated SIP session is terminated by the SIP ALG or the SIP phones or servers participating in the call, the RTP pinhole is closed.

The figure below shows a simplified call setup sequence that shows how the SIP ALG opens pinholes. Phone A and Phone B are installed on either side of a FortiGate operating in transparent mode. Phone A and Phone B are on the same subnet. The FortiGate includes a security policy that accepts SIP sessions from port1 to port2 and from port2 to port1. The FortiGate does not require an RTP security policy, just the SIP policy.

You can see from this diagram that the SDP profile in the INVITE request from Phone A indicates that Phone A is expecting to receive a media stream sent to its IP address using port 4000 for RTP and port 4001 for RTCP. The SIP ALG creates pinhole 1 to allow this media traffic to pass through the FortiGate. Pinhole 1 is opened on the Port2 interface and will accept media traffic sent from Phone B to Phone A.

When Phone B receives the INVITE request from Phone A, Phone B will know to send media streams to Phone A using destination IP address 10.31.101.20 and ports 4000 and 4001. The 200 OK response sent from Phone B indicates that Phone B is expecting to receive a media stream sent to its IP address using ports 8000 and 8001. The SIP ALG creates pinhole 2 to allow this media traffic to pass through the FortiGate. Pinhole 2 is opened on the Port1 interface and will accept media traffic sent from Phone A to Phone B.

 

Configuration example: SIP in transparent mode

The figure below shows an example SIP network consisting of a FortiGate operating in transparent mode between two SIP phones. Since the FortiGate is operating in transparent mode both phones are on the same network and the FortiGate and the SIP ALG does not perform NAT. Even though the SIP ALG is not performing NAT you can use this configuration to apply SIP security features to the SIP traffic.

The FortiGate requires two security policies that accept SIP packets. One to allow SIP Phone A to start a session with SIP Phone B and one to allow SIP Phone B to start a session with SIP Phone A. SIP network with FortiGate in transparent mode

transparent mode

General configuration steps

The following general configuration steps are required for this SIP configuration. This example uses the default VoIP profile. The example also includes security policies that specifically allow SIP sessions using UDP port 5060 from Phone A to Phone B and from Phone B to Phone A. In most cases you would have more than two phones so would use more general security policies. Also, you can set the security service to ANY to allow traffic other than SIP on UDP port 5060.

1. Add firewall addresses for Phone A and Phone B.
2. Add a security policy that accepts SIP sessions initiated by Phone A and includes the default VoIP profile.
3. Add a security policy that accepts SIP sessions initiated by Phone B and includes the default VoIP profile.

Configuration steps – GUI

To add firewall addresses for the SIP phones

1. Go to Policy & Objects > Addresses.
2. Add the following addresses for Phone A and Phone B:

 

Category	Address
Name	Phone_A
Type	IP/Netmask
Subnet / IP Range	10.31.101.20/255.255.255.255
Interface	port1
Category	Address
Name	Phone_B
Type	IP/Netmask
Subnet / IP Range	10.31.101.30/255.255.255.255
Interface	port2

To add security policies to apply the SIP ALG to SIP sessions

1. Go to Policy & Objects > IPv4 Policy.
2. Add a security policy to allow Phone A to send SIP request messages to Phone B:

Incoming Interface	port1
Outgoing Interface	port2
Source	Phone_A
Destination Address	Phone_B
Schedule	always
Service	SIP
Action	ACCEPT

3. Turn on VoIP and select the default VoIP profile.
4. Select OK.
5. Add a security policy to allow Phone B to send SIP request messages to Phone A:

Incoming Interface	port2
Outgoing Interface	port1
Source	Phone_B
Destination Address	Phone_A

 

Schedule	always
Service	SIP
Action	ACCEPT

6. Turn on VoIP and select the default VoIP profile.
7. Select OK.

Configuration steps – CLI

To add firewall addresses for Phone A and Phone B and security policies to apply the SIP ALG to SIP sessions

1. Enter the following command to add firewall addresses for Phone A and Phone B. config firewall address edit Phone_A set associated-interface port1

set type ipmask

set subnet 10.31.101.20 255.255.255.255

next edit Phone_B set associated-interface port2

set type ipmask

set subnet 10.31.101.30 255.255.255.255

end

2. Enter the following command to add security policies to allow Phone A to send SIP request messages to Phone B and Phone B to send SIP request messages to Phone A.

config firewall policy edit 0 set srcintf port1 set dstintf port2 set srcaddr Phone_A set dstaddr Phone_B set action accept set schedule always set service SIP set utm-status enable set voip-profile default

next edit 0 set srcintf port2 set dstintf port1 set srcaddr Phone_B set dstaddr Phone_A set action accept set schedule always set service SIP set utm-status enable set voip-profile default end

 

RTP enable/disable (RTP bypass)

You can configure the SIP ALG to stop from opening RTP pinholes. Called RTP bypass, this configuration can be used when you want to apply SIP ALG features to SIP signaling messages but do not want the RTP media streams to pass through the FortiGate. The FortiGate only acts as a signaling firewall and RTP media session bypass the FortiGate and no pinholes need to be created.

Enter the following command to enable RTP bypass in a VoIP profile by disabling opening RTP pinholes:

config voip profile edit VoIP_Pro_1 config sip set rtp disable

end

end

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Stateful SIP tracking, call termination, and session inactivity timeout

The SIP ALG tracks SIP dialogs over their lifespan between the first INVITE message and the Final 200 OK and

ACK messages. For every SIP dialog, stateful SIP tracking reviews every SIP message and makes adjustment to SIP tracking tables as required. These adjustments include source and destination IP addresses, address translation, dialog expiration information, and media stream port changes. Such changes can also result in dynamically opening and closing pinholes. You can use the diagnose sys sip-proxy stats list and the diagnose sys sip-proxy filter command to view the SIP call data being tracked by the SIP ALG.

The SIP ALG uses the SIP Expires header line to time out a SIP dialog if the dialog is idle and a Re-INVITE or UPDATE message is not received. The SIP ALG gets the Session-Expires value, if present, from the 200 OK response to the INVITE message. If the SIP ALG receives an INVITE before the session times out, all timeout values are reset to the settings in the new INVITE message or to default values. As a precautionary measure, the SIP ALG uses hard timeout values to set the maximum amount of time a call can exist. This ensures that the FortiGate is protected if a call ends prematurely.

When a SIP dialog ends normally, the SIP ALG deletes the SIP call information and closes open pinholes. A SIP call can also end abnormally due to an unexpected signaling or transport event that cuts off the call. When a call ends abnormally the SIP messages to end the call may not be sent or received. A call can end abnormally for the following reasons:

l Phones or servers crash during a call and a BYE message is not received. l To attack a SIP system, a malicious user never send a BYE message. l Poor implementations of SIP fail to process Record-Route messages and never send a BYE message. l Network failures prevent a BYE message from being received.

Any phone or server in a SIP call can cancel the call by sending a CANCEL message. When a CANCEL message is received by the FortiGate, the SIP ALG closes open pinholes. Before terminating the call, the ALG waits for the final 200 OK message.

The SIP ALG can be configured to terminate SIP calls if the SIP dialog message flow or the call RTP (media) stream is interrupted and does not recover. You can use the following commands to configure terminating inactive SIP sessions and to set timers or counters to control when the call is terminated by the SIP ALG.

Adding a media stream timeout for SIP calls

Use the following command in a VoIP profile to terminate SIP calls accepted by a security policy containing the VoIP profile when the RTP media stream is idle for 100 seconds.

config voip profile edit VoIP_Pro_Name config sip set call-keepalive 100

end end

You can adjust this setting between 1 and 10,080 seconds. The default call keepalive setting of 0 disables terminating a call if the media stream is interrupted. Set call keepalive higher if your network has latency problems that could temporarily interrupt media streams. If you have configured call keepalive and the FortiGate terminates calls unexpectedly you can increase the call keepalive time to resolve the problem.

Call keep alive should be used with caution because enabling this feature results in extra FortiGate CPU overhead and can cause delay/jitter for the VoIP call. Also, the FortiGate terminates the call without sending SIP messages to end the call. And if the SIP endpoints send SIP messages to terminate the call they will be blocked by the FortiGate if they are sent after the FortiGate terminates the call.

Adding an idle dialog setting for SIP calls

Use the following command in a VoIP profile to terminate SIP calls when for a single security policy, when the configured number of SIP calls (or dialogs) has stopped receiving SIP messages or has not received legitimate SIP messages. Using this command you can configure how many dialogs that have been accepted by a security policy that the VoIP profile is added to become idle before the SIP ALG deletes the oldest ones. The following command sets the maximum number of idle dialogs to 200:

config voip profile edit VoIP_Pro_Name config sip set max-idle-dialogs 200

end

end

Idle dialogs would usually be dialogs that have been interrupted because of errors or problems or as the result of a SIP attack that opens a large number of SIP dialogs without closing them. This command provides a way to remove these dialogs from the dialog table and recover memory and resources being used by these open and idle dialogs.

You can adjust this setting between 1 and a very high number. The default maximum idle dialogs setting of 0 disables this feature. Set maximum dialogs higher if your network has latency problems that could temporarily interrupt SIP messaging. If you have configured max idle dialogs and the FortiGate terminates calls unexpectedly you can increase the max idle dialogs number to resolve the problem.

Changing how long to wait for call setup to complete

In some cases and some configurations your SIP system may experience delays during call setup. If this happens, some SIP ALG timers may expire before call setup is complete and drop the call. In some cases you may also want to reduce the amount of time the SIP ALG allows for call setup to complete.

You can use the provisional-invite-expiry-time SIP VoIP profile option to control how long the SIP ALG waits for provisional INVITE messages before assuming that the call setup has been interrupted and the SIP call should be dropped. The default value for this timer is 210 seconds. You can change it to between 10 and 3600 seconds.

Use the following command to change the expiry time to 100 seconds.

config voip profile edit Profile_name

Stateful SIP tracking, call termination, and session inactivity Changing how long to wait for call setup to timeout          complete

config sip set provisional-invite-expiry-time 100

end

end

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Conflicts between the SIP ALG and the session helper

If you suspect that the SIP session helper is being used instead of the ALG, you can use the diagnose sys sip command to determine if the SIP session helper is processing SIP sessions. For example, the following command displays the overall status of the SIP sessions being processed by the SIP session helper:

The diagnose sys sip command only displays current status information. To see activity the SIP session helper has to actually be processing SIP sessions when you enter the command. For example, if the SIP session helper had been used for processing calls that ended 5 minutes ago, the command output would show no SIP session helper activity.

diagnose sys sip status dialogs: max=32768, used=0 mappings: used=0 dialog hash by ID: size=2048, used=0, depth=0 dialog hash by RTP: size=2048, used=0, depth=0 mapping hash: size=2048, used=0, depth=0 count0: 0 count1: 0 count2: 0 count3: 0 count4: 0

This command output shows that the session helper is not processing SIP sessions because all of the used and count fields are 0. If any of these fields contains non-zero values then the SIP session helper may be processing SIP sessions.

Also, you can check to see if some ALG-only features are not being applied to all SIP sessions. For example, FortiView pages displays statistics for SIP and SCCP calls processed by the ALG but not for calls processed by the session helper. So if you see fewer calls than expected the session helper may be processing some of them.

Finally, you can check the policy usage and session information dashboard widgets to see if SIP sessions are being accepted by the wrong security policies.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

The SIP ALG

In most cases you should use the SIP Application Layer Gateway (ALG) for processing SIP sessions. The SIP ALG provides the same basic SIP support as the SIP session helper. Additionally, the SIP ALG provides a wide range of features that protect your network from SIP attacks, apply rate limiting to SIP sessions, check the syntax of SIP and SDP content of SIP messages, and provide detailed logging and reporting of SIP activity.

By default all SIP traffic is processed by the SIP ALG. If the policy that accepts the SIP traffic includes a VoIP profile, the SIP traffic is processed by that profile. If the policy does not include a SIP profile the SIP traffic is processed by the SIP ALG using the default VoIP profile.

If a FortiGate or a VDOM has been configured to use the SIP session helper, you can change this behavior to the default configuration of using the SIP ALG with the following command:

config system settings set default-voip-alg-mode proxy-based set sip-helper disable

end

From the GUI you can only configure VoIP security profiles and add them to security policies if VoIP is turned on under System > Feature Visibility. However, you can always configure VoIP profiles and add them to security profiles from the CLI. And if the default-voip-alg mode is set to proxy-based the default SIP profile will still be used even if VoIP security profiles are not visible from the GUI.

As shown in the figure below, the FortiGate SIP ALG intercepts SIP packets after they have been routed by the routing module, accepted by a security policy and passed through DoS and IPS Sensors (if DoS and IPS are enabled). The ALG raises SIP packets to the application layer, analyzes the SIP and SDP addressing information in the SIP messages, makes adjustments (for example, NAT) to this addressing if required, and then sends the packets out the egress interface to their destination.

The SIP ALG provides:

• All the same features as the SIP session helper including NAT and SIP and RTP Pinholes.
• In addition for the ALG you can enable or disable RTP pinholing, SIP register pinholing and SIP contact pinholing. In a signaling only environment where the RTP stream bypasses the FortiGate, you can disable RTP pinholing to improve performance. l SIP TCP and UDP support l SIP Message order checking l Configurable Header line length maximums

 

SIP session helper diagnose commands

The SIP ALG works at the application level after ingress packets are accepted by a security policy

	• IP routing and forwarding • IPsec VPN encryption, decryption
	• Rate limiting and message blocking • Stateful SIP tracking • Message, header, and SDP syntax checking • Network surveillance • NAT and IP topology Hiding • Logging and debugging
	• Intrusion detection and prevention • Defined by Fortinet and enterprise signatures • SIP decoder identifies SIP sessions
	• Security policy • IPsec VPN encryption, decryption • Access control
	• Native (D)DoS prevention • Anomaly detection and prevention

• Message fragment assembly (TCP) l If SIP messages are fragmented across multiple packets, the FortiGate assembles the fragments, does inspection and pass the message in its entirety to the SIP server as one packet. This offloads the server from doing all the TCP processing of fragments. l L4 Protocol Translation l Message Flood Protection l Protects a SIP server from intentional or unintentional DoS of flooding INVITE, REGISTER, and other SIP methods by allowing control of the rate that these massages pass through the FortiGate.
• SIP message type filtering l The FortiGate can prevent specified SIP message types from passing through the FortiGate to a SIP server. For example In a voice only SIP implementation, there may be no need to permit a SUBSCRIBE message to ever make it’s way to the SIP call processor. Also, if a SIP server cannot process some SIP message types you can use SIP message type filtering to block them. For example, a SIP server could have a bug that prevents it from processing certain SIP messages. In this case you can temporarily block these message types until problem with the SIP server has been fixed. l SIP statistics and logging l SIP over IPv6 l SIP over SSL/TLS
• Deep SIP message syntax checking (also called deep SIP header inspection or SIP fuzzing protection). Prevents attacks that use malformed SIP messages. Can check many SIP headers and SDP statements. Configurable bypass and modification options.
• Hosted NAT traversal, Resolves IP address issue in SIP and SDP lines due to NAT-PT in far end firewall. Important feature for VoIP access networks.
• SIP High Availability (HA), including active-passive clustering and session pickup (session failover) for SIP sessions.
• Geographical Redundancy. In an HA configuration, if the active SIP server fails (missing SIP heartbeat messages or SIP traffic) SIP sessions can be redirected to a secondary SIP server in another location. l SIP per request method message rate limitation with configurable threshold for SIP message rates per request method. Protects SIP servers from SIP overload and DoS attacks.
• RTP Bypass, Supports configurations with and without RTP pinholing. May inspect and protect SIP signaling only.
• SIP NAT with IP address conservation. Performs SIP and RTP aware IP Network Address translation. Preserves the lost IP address information in the SDP profile i= line for later processing/debugging in the SIP server. See NAT with IP address conservation on page 80.
• IP topology hiding l The IP topology of a network can be hidden through NAT and NAPT manipulation of IP and SIP level addressing. For example, see SIP NAT scenario: source address translation (source NAT) on page 65. l SIP inspection without address translation l The SIP ALG inspects SIP messages but addresses in the messages are not translated. This feature can be applied to a FortiGate operating in transparent mode or in NAT/Route mode. In transparent mode you add normal transparent mode security policies that enable the SIP ALG and include a VoIP profile that causes the SIP ALG to inspect SIP traffic as required. For an example configuration, see Configuration example: SIP in transparent mode on page 54.
• For a FortiGate operating in NAT/Route mode, if SIP traffic can pass between different networks without requiring NAT because is supported by the routing configuration, you can add security policies that accept SIP traffic without enabling NAT. In the VoIP profile you can configure the SIP ALG to inspect SIP traffic as required.

Enabling VoIP support from the GUI

Before you begin to configure VoIP security profiles, including SIP, from the GUI you should go to System > Feature Visibility and turn on VoIP (under Additional Features). VoIP settings are visible in both Inspection modes (flow and proxy).

SIP ALG configuration overview

To apply the SIP ALG, you add a SIP VoIP profile to a security policy that accepts SIP sessions. All SIP sessions accepted by the security policy will be processed by the SIP ALG using the settings in the VoIP profile. The VoIP profile contains settings that are applied to SIP, Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE) and Skinny Call Control Protocol (SCCP) sessions. All SCCP sessions accepted by the security policy are also processed by the ALG. You configure SIP and SCCP settings separately. SIP settings also apply to SIMPLE sessions.

VoIP profiles

You can customize the default VoIP profile or add new VoIP profiles.

To add a new VoIP profile from the GUI go to Security Profiles > VoIP and select Create New (the + button).

For SIP, from the GUI you can configure the VoIP profile to limit the number of SIP REGISTER and INVITE requests. Many additional options for configuring how the ALG processes SIP sessions are available from the CLI.

For SCCP you can limit the call setup time. Additional SCCP options are available from the CLI.

Use the following command to add a VoIP profile named VoIP_Pro_1 from the CLI:

config voip profile edit VoIP_Pro_1

end

FortiGates include two pre-defined VoIP profiles. On the GUI these profiles look identical. However, the CLI-only settings result in the following functionality.

default

The most commonly used VoIP profile. This profile enables both SIP and SCCP and places the minimum restrictions on what calls will be allowed to negotiate. This profile allows normal SCCP, SIP and RTP sessions and enables the following security settings: •               strict-register to open smaller more secure pinholes (see Enhancing SIP pinhole security on page 86). •               block-long-lines to block SIP messages with lines that exceed maximum line lengths. •               block-unknown to block unrecognized SIP request messages. •               open-record-route-pinhole to open pinholes for Record-Route messages. •               nat-trace (see NAT with IP address conservation on page 80). •               contact-fixup perform NAT on the IP addresses and port numbers in SIP headers in SIP CONTACT messages even if they don’t match the session’s IP address and port numbers. •               ips-rtp to enable IPS in security policies that also accept SIP sessions to protect the SIP traffic from SIP-based attacks.

strict

This profile is available for users who want to validate SIP messages and to only allow SIP sessions that are compliant with RFC 3261. In addition to the settings in the default VoIP profile, the strict profile sets all SIP deep message inspection header checking options (for example, malformed-request-line and many others) to discard. So the strict profile blocks and drops SIP messages that contain malformed SIP or SDP lines that can be detected by the ALG. For more information about SIP deep header inspection, see Deep SIP message inspection on page 96.

Neither of the default profiles applies SIP rate limiting. To apply more ALG features to SIP sessions you can clone (copy) the pre-defined VoIP profiles and make your own modifications to them. You can clone VoIP profiles from the GUI or the CLI. For example, from the CLI, to clone the default profile and configure the limit for SIP NOTIFY request messages to 1000 messages per second per security policy and block SIP INFO request messages.

config voip profile clone default to my_voip_pro edit my_voip_pro config sip set notify-rate 1000 set block-info enable

end

end

Changing the port numbers that the SIP ALG listens on

Most SIP configurations use TCP or UDP port 5060 for SIP sessions and port 5061 for SIP SSL sessions. If your SIP network uses different ports for SIP sessions you can use the following command to configure the SIP ALG to listen on a different TCP, UDP, or SSL ports. For example, to change the TCP port to 5064, the UDP port to 5065, and the SSL port to 5066.

config system settings set sip-tcp-port 5064 set sip-udp-port 5065 set sip-ssl-port 5066

end

You also configure the SIP ALG to listen in two different TCP ports and two different UDP ports for SIP sessions. For example, if you receive SIP TCP traffic on port 5060 and 5064 and UDP traffic on ports 5061 and 5065 you can enter the following command to receive the SIP traffic on all of these ports:

config system settings set sip-tcp-port 5060 5064 set sip-udp-port 5061 5065

end

Disabling the SIP ALG in a VoIP profile

SIP is enabled by default in a VoIP profile. If you are just using the VoIP profile for SCCP you can use the following command to disable SIP in the VoIP profile.

config voip profile edit VoIP_Pro_2 config sip set status disable

end

SIP ALG diagnose commands

You can use the diagnose sys sip-proxy command to display diagnostic information for the SIP ALG. A number of options are available including:

Use the following command to list all active SIP calls being processed by the SIP ALG. You can also use the clear option to delete all active SIP calls being processed by the SIP ALG, the idle option to list idle SIP calls, and the invite option to list SIP invite transactions.

SIP ALG diagnose commands

diagnose sys sip-proxy calls {clear | list | idle | invite}

Use the following commands to employ filters to display specific information about the SIP ALG and the session that it is processing. You can build up a filter by including a number of options such as source address, VoIP profile, policy, and so on.

diagnose sys sip-proxy filter <filter_options> diagnose sys sip-proxy log-filter <filter_options>

Use the following command to display the active SIP rate limiting meters and their current settings.

diagnose sys sip-proxy meters list

Use the following command to display status information about the SIP sessions being processed by the SIP ALG. You can also clear all SIP ALG statistics.

diagnose sys sip-proxy stats {clear | list}

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

The SIP session helper

The SIP session-helper is a high-performance solution that provides basic support for SIP calls passing through the FortiGate by opening SIP and RTP pinholes and by performing NAT of the addresses in SIP messages.

The SIP session helper:

• Understands SIP dialog messages. l Keeps the states of the SIP transactions between SIP UAs and SIP servers. l Translates SIP header and SDP information to account for NAT operations performed by the FortiGate. l Opens up and closes dynamic SIP pinholes for SIP signaling traffic. l Opens up and closes dynamic RTP and RTSP pinholes for RTP and RTSP media traffic.
• Provides basic SIP security as an access control device.
• Uses the intrusion protection (IPS) engine to perform basic SIP protocol checks.

SIP session helper configuration overview

By default FortiOS uses the SIP ALG for SIP traffic. If you want to use the SIP session helper you need to enter the following commands to disable the SIP ALG and to enable the SIP session helper:

config system settings set default-voip-alg-mode kernel-helper-based set sip-helper enable

end

The SIP session helper is disabled by default and must be enabled for the SIP session helper to process VoIP traffic. The SIP session help is set to listen for SIP traffic on TCP or UDP port 5060. SIP sessions using port 5060 accepted by a security policy that does not include a VoIP profile are processed by the SIP session helper.

You might want to disable the SIP session helper and the SIP ALG if you don’t want the FortiGate to apply NAT or other SIP session helper features to SIP traffic. With the SIP session helper and the SIP ALG disabled, the FortiGate can still accept SIP sessions if they are allowed by a security policy, but the FortiGate will not be able to open pinholes or NAT the addresses in the SIP messages.

You can enable and disable the SIP session helper, change the TCP or UDP port that the session helper listens on for SIP traffic, and enable or disable SIP NAT tracing. If the FortiGate is operating with multiple VDOMs, each VDOM can have a different SIP session helper configuration.

To have the SIP session helper process SIP sessions you need to add a security policy that accepts SIP sessions on the configured SIP UDP or TCP ports. The security policies can have service set to ANY, or to the SIP predefined firewall service, or a custom firewall service. The SIP pre-defined firewall service restricts the security policy to only accepting sessions on UDP port 5060.

If NAT is enabled for security policies that accept SIP traffic, the SIP session helper translates addresses in SIP headers and in the RDP profile and opens up pinholes as required for the SIP traffic. This includes security policies that perform source NAT and security policies that contain virtual IPs that perform destination NAT and port forwarding. No special SIP configuration is required for this address translation to occur, it is all handled

 

Viewing, removing, and adding the SIP session helper configuration

automatically by the SIP session helper according to the NAT configuration of the security policy that accepts the SIP session.

To use the SIP session helper you must not add a VoIP profile to the security policy. If you add a VoIP profile, SIP traffic bypasses the SIP session helper and is processed by the SIP ALG.

In most cases you would want to use the SIP ALG since the SIP session helper provides limited functionality. However, the SIP session helper is available and can be useful for high-performance solutions where a high level of SIP security is not a requirement.

Viewing, removing, and adding the SIP session helper configuration

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

show system session-helper .

.

.

edit 13 set name sip set port 5060 set protocol 17

next .

. .

This command output shows that the sip session helper listens on UDP port 5060 for SIP sessions.

Enter the following command to delete session-helper list entry number 13:

config system session-helper delete 13

end

If you want to use the SIP session helper you can verify whether it is available using the show system session-helper command.

If the SIP session helper has been removed from the session-helper list you can use the following command to add it back to the session helper list:

config system session-helper edit 0 set name sip set port 5060 set protocol 17

end

Changing the port numbers that the SIP session helper listens on

You can use the following command to change the port number that the SIP session helper listens on for SIP traffic to 5064. The SIP session helper listens on the same port number for UDP and TCP SIP sessions. In this The SIP session helper        Configuration example: SIP session helper in transparent mode

example, the SIP session helper is session helper 13:

config system session-helper edit 13 set port 5064

end

The config system settings options sip-tcp-port, sip-udp-port, and sip-ssl-port control the ports that the SIP ALG listens on for SIP sessions. See Changing the port numbers that the SIP ALG listens on on page 45.

Your FortiGate may use a different session helper number for SIP. Enter the following command to view the session helpers:

show system session-helper .

. .

edit 13 set name sip set port 5060 set protocol 17

end .

. .

Configuration example: SIP session helper in transparent mode

The figure below shows an example SIP network consisting of a FortiGate operating in transparent mode between two SIP phones. Since the FortiGate is operating in transparent mode both phones are on the same network and the FortiGate and the SIP session helper does not perform NAT. Even though the SIP session helper is not performing NAT you can use this configuration to apply SIP session helper security features to the SIP traffic.

The FortiGate requires two security policies that accept SIP packets. One to allow SIP Phone A to start a session with SIP Phone B and one to allow SIP Phone B to start a session with SIP Phone A. SIP network with FortiGate in transparent mode

transparent mode

Configuration example: SIP session helper in transparent mode

General configuration steps

The following general configuration steps are required for this SIP configuration that uses the SIP session helper. This example includes security policies that specifically allow SIP sessions using UDP port 5060 from Phone A to Phone B and from Phone B to Phone A. In most cases you would have more than two phones so would use more general security policies. Also, you can set the firewall service to ANY to allow traffic other than SIP on UDP port 5060.

This example assumes that you have entered the following command to enable using the SIP session helper:

config system settings set default-voip-alg-mode kernel-helper-based

end

1. Add firewall addresses for Phone A and Phone B.
2. Add a security policy that accepts SIP sessions initiated by Phone A. Add a security policy that accepts SIP sessions initiated by Phone B.

Configuration steps – GUI

To add firewall addresses for the SIP phones

1. Go to Policy & Objects > Addresses.
2. Select Create New > Address to add the following addresses for Phone A and Phone B:

Category	Address
Name	Phone_A
Type	IP/Netmask
Subnet / IP Range	10.31.101.20/255.255.255.255
Interface	port1
Category	Address
Name	Phone_B
Type	IP/Netmask
Subnet / IP Range	10.31.101.30/255.255.255.255
Interface	port2

To add security policies to accept SIP sessions

3. Go to Policy & Objects > IPv4 Policy.
4. Select Create New to add a security policy.
5. Add a security policy to allow Phone A to send SIP request messages to Phone B:

Incoming Interface	port1
Outgoing Interface	port2
Source	Phone_A
Destination Address	Phone_B
Schedule	always
Service	SIP
Action	ACCEPT

4. Select OK.
5. Add a security policy to allow Phone B to send SIP request messages to Phone A:

Incoming Interface	port2
Outgoing Interface	port1
Source Address	Phone_B
Destination Address	Phone_A
Schedule	always
Service	SIP
Action	ACCEPT

6. Select OK.

Configuration steps – CLI

To add firewall addresses for Phone A and Phone B and security policies to accept SIP sessions

1. Enter the following command to add firewall addresses for Phone A and Phone B. config firewall address edit Phone_A set associated interface port1 set type ipmask

set subnet 10.31.101.20 255.255.255.255

next edit Phone_B set associated interface port2 set type ipmask

set subnet 10.31.101.30 255.255.255.255 end

SIP session helper diagnose commands

2. Enter the following command to add security policies to allow Phone A to send SIP request messages to Phone B and Phone B to send SIP request messages to Phone A.

config firewall policy edit 0 set srcintf port1 set dstintf port2 set srcaddr Phone_A set dstaddr Phone_B set action accept set schedule always set service SIP

next edit 0 set srcintf port2 set dstintf port1 set srcaddr Phone_B set dstaddr Phone_A set action accept set schedule always set service SIP set utm-status enable end

SIP session helper diagnose commands

You can use the diagnose sys sip commands to display diagnostic information for the SIP session helper.

Use the following command to set the debug level for the SIP session helper. Different debug masks display different levels of detail about SIP session helper activity.

diagnose sys sip debug-mask <debug_mask_int>

Use the following command to display the current list of SIP dialogs being processed by the SIP session help. You can also use the clear option to delete all active SIP dialogs being processed by the SIP session helper.

diagnose sys sip dialog {clear | list}

Use the following command to display the current list of SIP NAT address mapping tables being used by the SIP session helper.

diagnose sys sip mapping list

Use the following command to display the current SIP session helper activity including information about the SIP dialogs, mappings, and other SIP session help counts. This command can be useful to get an overview of what the SIP session helper is currently doing.

diagnose sys sip status

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!