A lot of people that have fairly strict policy sets end up having matchmaking issues with their gaming consoles when behind a FortiGate. I discuss two methods to resolving this issue. Videos are going to start discussing a lot more architecture driven topics to help ensure everyone is building the best network possible!
Latest status update discussing some video quality upgrades we will be getting soon etc.
This section explains how to configure other log features within your existing log configuration. You may want to include other log features after initially configuring the log topology because the network has either outgrown the initial configuration, or you want to add additional features that will help your network’s logging requirements.
The following topics are included in this section:
l Log backup and restore tools l Configuring logging to multiple Syslog servers l Using Automatic Discovery to connect to a FortiAnalyzer unit l Activating a FortiCloud account for logging purposes l Viewing log storage space l Customizing and filtering log messages l Viewing logs from the CLI l Configuring NAC Quarantine logging l Logging local-in policies l Tracking specific search phrases in reports l Interpreting and configuring FSSO syslog log messages
Local disk logs can now be backed up and restored to local files, using CLI commands:
execute log backup <filename> execute log restore <filename>
Restoring logs will wipe the current log and report content off the disk.
Logs can also now be exported to a USB storage device, as LZ4 compressed files, from both CLI and GUI. When you insert a USB drive into the FortiGate’s USB port, the USB menu will appear in the GUI. The menu shows the amount of storage on the USB disk, and the log file size, and you can select Copy to USB to copy the log data to the drive.
This section explains how to troubleshoot logging configuration issues, as well as connection issues, that you may have with your FortiGate unit and a log device. This section also contains information about how to use log messages when troubleshooting issues that are about other FortiGate features, such as VPN tunnel errors.
Log messages can help when troubleshooting issues that occur, since they can provide details about what is occurring. The uses and methods for involving logging in troubleshooting vary depending on the problem. The following are examples of how log messages can assist when troubleshooting networking issues.
This type of logging should only be enabled when you need to know about specific diagnostic information, for example, when you suspect a signature is triggered by a false positive. These log messages can help troubleshoot individual problems with misidentified or missing packets and network intrusions involving malicious packets.
If you want to configure the packet quota, number of packets that are recorded before alerts and after attacks, use the following procedure.
config ips settings set ips-packet-quota <integer> set packet-log-history <integer> set packet-log-post-attack <integer>
end
When the FortiGate unit is in HA mode, you may see the following log message content within the event log:
type=event subtype=ha level=critical msg= “HA slave heartbeat interface internal lost neighbor information”
OR
type=event subtype=ha level=critical msg= “Virtual cluster 1 of group 0 detected new joined HA member” OR
type=event subtype=ha level=critical msg= “HA master heartbeat interface internal get peer information”
The log messages occur within a given time, and indicate that the units within the cluster are not aware of each other anymore. These log messages provide the information you need to fix the problem.
If external logging devices are not recording the log information properly or at all, the problem will likely be due to one of two situations: no data is being received because the log device cannot be reached, or no data is being sent because the FortiGate unit is no longer logging properly.
After configuring logging to a supported log device, and testing the connection, you may find you cannot connect. To determine whether this is the problem:
If the FortiGate unit stopped logging to a device, test the connection between both the FortiGate unit and device using the execute ping command. The log device may have been turned off, is upgrading to a new firmware version, or just not working properly.
The FortiGate unit may also have a corrupted log database. When you log into the web-based manager and you see an SQL database error message, it is because the SQL database has become corrupted. View “SQL database errors” in the next section before taking any further actions, to avoid losing your current logs.
If attempting to troubleshoot issues with the SQL log database, use the following to help guide you to solving issues that occur.
There may be errors or inconsistencies in the SQL used to maintain the database. Here are some example error messages and possible causes:
You have an error in your SQL syntax (remote/MySQL)
or
ERROR: syntax error at or near… (local/PostgreSQL)
No data is covered.
If well-formed SQL queries do not produce results, and logging is turned on for the log type, there may be a database configuration problem with the remote database.
Ensure that:
l MySQL is running and using the default port 3306. l You have created an empty database and a user who has read/write permissions for the database. l Here is an example of creating a new MySQL database named fazlogs, and adding a user for the database:
If the database seems inacessible, you may encounter the following error message after upgrading or downgrading the FortiGate unit’s firmware image.
The error message indicates that the SQL database is corrupted and cannot be updated with the SQL schemas any more. When you see this error message, you can do one of the following:
l select Cancel and back up all log files; then select Rebuild to blank and rebuild the database. l select Rebuild immediately, which will blank the database and previous logs will be lost.
Until the database is rebuilt, no information will be logged by the FortiGate unit regardless of the log settings that are configured on the unit. When you select Rebuild, all logs are lost because the SQL database is erased and then rebuilt again. Logging resumes automatically according to your settings after the SQL database is rebuilt.
To view the status of the database, use the diagnose debug sqldb-error status command in the CLI. This command will inform you whether the database has errors present.
If you want to view the database’s errors, use the diagnose debug sqldb-error read command in the CLI. This command indicates exactly what errors occurred, and what tables contain those errors.
Log files are backed up using the execute backup {disk | memory } {alllogs | logs} command
in the CLI. You must use the text variable when backing up log files because the text variable allows you to view the log files outside the FortiGate unit. When you back up log files, you are really just copying the log files from the database to a specified location, such as a TFTP server.
The number of logging daemon child processes has been made available for editing. A higher number can affect performance, and a lower number can affect log processing time, although no logs will be dropped or lost if the number is decreased.
If you are suffering from performance issues, you can alter the number of logging daemon child processes, from 0 to 15, using the following syntax. The default is 8.
Troubleshooting and logging Logging daemon (Miglogd)
config system global set miglogd-children <integer> end
This FortiOS Handbook chapter contains detailed information about how FortiGates processes SIP VoIP calls and how to configure the FortiGate to apply security features to SIP calls. This document describes all FortiGate SIP configuration options and contains detailed configuration examples.
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).
Also, VoIP settings are only available if the FortiGate or current VDOM Inspection Mode is set to Proxy. To view the inspection mode go to System > Settings to confirm that Inspection Mode is set to Proxy. You can also use the following CLI command to change the inspection mode to proxy:
config system settings set inspection-mode proxy
end
The System Information dashboard widget also shows the current Mode.
This FortiOS Handbook chapter contains the following sections:
Inside FortiOS: VoIP Protection introduces FortiOS VoIP Protection
Common SIP VoIP configurations describes some common SIP configurations.
SIP messages and media protocols describes SIP messages and some common SIP media protocols.
The SIP session helper describes how the SIP session helper works and how to configure SIP support using the SIP session helper.
The SIP ALG describes how the SIP Application Layer Gateway (ALG) works and how to configure SIP support using the SIP ALG.
Conflicts between the SIP ALG and the session helper describes how to sort out conflicts between the SIP session helper and the ALG.
Stateful SIP tracking, call termination, and session inactivity timeout describes how the SIP ALG performs SIP stateful tracking, call termination and session activity timeouts.
What’s new in FortiOS 6.0.1 Introduction
SIP and RTP/RTCP describes how SIP relates to RTP and RTCP.
How the SIP ALG creates RTP pinholes describes how the SIP ALG creates pinholes.
Configuration example: SIP in transparent mode describes how to configure a FortiGate in transparent mode to support SIP.
RTP enable/disable (RTP bypass) describes RTP bypass.
Opening and closing SIP register, contact, via and record-route pinholes describes how FortiOS opens and closes these pinholes.
Accepting SIP register responses describes how to enable accepting SIP register responses.
How the SIP ALG performs NAT describes how the SIP ALG performs NAT.
Enhancing SIP pinhole security describes how to open smaller pinholes.
Hosted NAT traversal describes SIP hosted NAT traversal and how to configure it.
SIP over IPv6 describes how to configure SIP over IPv6.
Deep SIP message inspection describes how deep SIP message inspection works.
Blocking SIP request messages describes how to block SIP request messages to prevent some common SIP attacks.
SIP rate limiting includes more options for preventing SIP attacks.
SIP logging describes how to enable SIP logging.
Inspecting SIP over SSL/TLS (secure SIP) describes how to inspection encrypted SIP traffic.
SIP and HA–session failover and geographic redundancy describes how to use FGCP HA to support SIP geographic redundancy.
SIP and IPS describes how to turn on IPS for SIP sessions.
SIP debugging describes some tools for debugging your SIP configuration.
VoIP features appear on the GUI when the FortiGate is operating in Flow mode, see Enabling VoIP support from the GUI on page 43.
By default, FortiOS 6.0 disables the SIP session helper, see SIP session helper configuration overview on page 35.
The FortiOS SIP Application Layer Gateway (ALG) allows SIP calls to pass through a FortiGate by opening SIP and RTP pinholes and performing source and destination IP address and port translation for SIP and RTP packets.
There are a large number of SIP-related Internet Engineering Task Force (IETF) documents (Request for
Comments) that define behavior of SIP and related applications. FortiOS completly support RFC 3261 for SIP, RFC 4566 for SDP and RFC 3262 for Provisional Response Acknowledgment (PRACK). FortiOS also supports other SIP and SIP-related RFCs and performs Deep SIP message inspection for SIP statements defined in other SIP RFCs.
The FortiOS SIP Application Level Gateway (ALG) protects Voice over IP (SIP and SDP) services in Unified Communication and NGN/IMS networks with the following advanced VoIP defense mechanisms.
Verifies SIP and SDP header syntax and protects SIP servers from potential SIP Fuzzing attacks. When a violation is detected, FortiOS can impose counter measures and can also send automatic SIP response messages to offload processing from the SIP server.
Allows rate limiting of SIP messages per SIP request method. This prevents a SIP server from overload or from DoS attacks using particular SIP methods. For example, FortiOS can protect SIP servers from a flood of SIP REGISTER or INVITE messages, which can be caused by a DoS attack or a flash crowd.
RTP pinholing only forwards RTP/RTCP packets that conform to the particular session description of the associated SIP dialog. If a SIP dialog is finished, FortiOS automatically closes the pinhole. RTP/RTCP pinholing is supported by FortiASIC acceleration and achieves high packet throughput at low jitter and delay.
FortiOS tracks SIP message sequences and prevents unwanted SIP messages that are not related to a particular SIP dialog. For instance, FortiOS can detect malicious SIP BYE messages that do not conform with the associated context of the SIP dialog.
Some SIP phones and SIP servers use SSL or TLS to encrypt SIP signalling traffic. To allow SIP over SSL/TLS calls to pass through the FortiGate unit, the encrypted signalling traffic has to be unencrypted and inspected. FortiOS intercepts and unencrypts and inspects the SIP packets. Allowed packets are then re-encrypted and forwarded to their destination.
Carrier grade
FortiOS can detect and inspect SIP and SDP UDP and TCP sessions and SIP SSL sessions and ou can configure the ports that the SIP ALG monitors for these sessions. In addition you can configure two different ports for SIP UDP sessions and two different ports for SIP TCP sessions. The port configuration can be changed without affecting other parts of the SIP configuration.
To protect VoIP infrastructure in carrier networks, FortiOS complies with typical carrier requirements for availability and robustness.
FortiOS supports a hot failover configuration with an active and a standby FortiGate device. FortiOS dynamically updates the context on the standby unit with SIP and RTP related data. This enables the standby unit to takeover stable voice calls in case of a planned or unplanned outage or failover of the active unit.
In FortiOS SIP server cluster configurations the active and standby units can be deployed in different geographical locations. This configuration prevents a total outage of a SIP server infrastructure if one location goes offline. FortiOS supports the detection of SIP server outages (loss of heartbeats) and a redirect of SIP messages to the redundant SIP server location.
FortiOS can log call related information internally or to an external SYSLOG or FortiAnalyzer unit. This includes event logs that show particular SIP-related attacks or syntax violations with SIP messages or logs that summarize call statistics.
FortiOS performs configurable network address translation for IP addresses in the SIP and SDP header. The SIP ALG follows the configured NAT addresses in firewall virtual IPs and changes SIP header IP addresses accordingly. RTP NAT is controlled by SIP/SDP and the firewall policy. This allows translating an unlimited number of IP addresses without adding specific RTP policies.
FortiOS SIP and SDP header manipulation supports SIP Network Address Translation (NAT) through FortiGate units configured as NAT firewalls.
NAT/NAPT
In many service provider networks, CPE firewall devices provide NAT without application awareness. This causes issues for SIP/SDP and RTP traffic, since UAC IP address information references to the internal network behind the far end firewall. VoIP calls cannot be connected successfully. FortiOS mitigates far end NAT issues (called Hosted NAT traversal) by probing the first RTP packet from the UAC and learning the far end NA(P)T binding.
FortiOS then updates the internal NAT binding for RTP accordingly.
In case of SIP and RTP NAT IP the original address information can get lost after translating to the provisioned IP addresses. This IP address information is sometimes required for detailed billing records or debugging purposes. FortiOS can maintain the original IP address information in a translated SIP header by adding it to the SIP/SDP info line (i=) or by adding it to the original attribute (o=). Either option can be selected depending on the SIP billing environment.
The FortiOS SIP ALG is applied to SIP traffic accepted by a firewall policy that includes a VoIP profile. The VoIP profile controls how the SIP ALG processes SIP sessions. FortiOS also includes a high-performance SIP session helper that provides limited SIP functionality. In most cases the SIP ALG should be used because the SIP ALG supports the complete range of FortiOS SIP features.
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
FortiOS, operating in NAT/Route and in transparent mode supports SIP over IPv6. The SIP ALG can process SIP messages that use IPv6 addresses in the headers, bodies, and in the transport stack. The SIP ALG cannot modify the IPv6 addresses in the SIP headers so FortiGate units cannot perform SIP or RTP NAT over IPv6 and also cannot translate between IPv6 and IPv4 addresses.
FortiOS supports VoIP protection with the SIP ALG on all FortiGate hardware platforms. Whenever a FortiGate unit provides FortiASIC or SPM HW acceleration, the SIP ALG will use this option to fast-path RTP/RTCP traffic.
As well, since the SIP ALG is proxy-based, SIP control packets are not offloaded to NP4 or NP6 processors. But actual voice or other media traffic can be offloaded to NP4 or NP6 processors after the SIP session is established. Many FortiGate units also support low latencey hardware acceleration configurations that also enhance SIP voice transmission.
FortiGate hardware acceleration provides a high throughput solution at very low jitter and delay. FortiOS provides efficient and highly scalable protection for VoIP in emerging Enterprise and Carrier network. This complements Fortinet’s NGFW and UTM offerings. VoIP protection can be easily added to any firewall policy just by adding a VoIP profile.
Platform support and hardware acceleration
VoIP protection is supported in FortiAnalyzer and FortiManager. Centralized logging and management are essential for carrier and MSSP service provider and are influencing business case calculations.
This section describes some common SIP VoIP configurations and simplified SIP dialogs for these configurations. This section also shows some examples of how adding a FortiGate affects SIP processing.
In the peer to peer configuration shown below, two SIP phones (in the example, FortiFones) communicate directly with each other. The phones send SIP request and response messages back and forth between each other to establish the SIP session.
Peer to peer configurations are not very common because they require the SIP phones to keep track of the names and addresses of all of the other SIP phones that they can communicate with. In most cases a SIP proxy or redirect server maintains addresses of a large number of SIP phones and a SIP phone starts a call by contacting the SIP proxy server.
A SIP proxy server act as intermediary between SIP phones and between SIP phones (for example, two FortiFones) and other SIP servers. As shown below, SIP phones send request and response messages the SIP proxy server. The proxy server forwards the messages to other clients or to other SIP proxy servers. Proxy servers can hide SIP phones by proxying the signaling messages. To the other users on the VoIP network, the signaling invitations look as if they come from the SIP proxy server.
redirect server configuration
SIP in proxy mode
A common SIP configuration would include multiple networks of SIP phones. Each of the networks would have its own SIP server. Each SIP server would proxy the communication between phones on its own network and between phones in different networks.
A SIP redirect server accepts SIP requests, maps the addresses in the request into zero or more new addresses and returns those addresses to the client. The redirect server does not initiate SIP requests or accept calls. As shown below, SIP clients send INVITE requests to the redirect server, which then looks up the destination address. The redirect server returns the destination address to the client. The client uses this address to send the INVITE request directly to the destination SIP client.
Common SIP VoIP configurations SIP registrar configuration
SIP redirect server
A SIP registrar accepts SIP REGISTER requests from SIP phones for the purpose of updating a location database with this contact information. This database can then become a SIP location service that can be used by SIP proxy severs and redirect servers to locate SIP clients. As shown below, SIP clients send REGISTER requests to the SIP registrar.
Depending on your security requirements and network configuration FortiGates may be in many different places in a SIP configuration. This section shows a few examples.
The diagram below shows a FortiGate installed between a SIP proxy server and SIP phones on the same network. The FortiGate is operating in transparent mode so both the proxy server and the phones are on the same subnet. In this configuration, called SIP inspection without address translation, the FortiGate could be protecting the SIP proxy server on the private network by implementing SIP security features for SIP sessions between the SIP phones and the SIP proxy server.
Common SIP VoIP configurations SIP with a FortiGate
call by proxy server. the INVITE request to Phone B.
The phone rings.
The phones and server use the same SIP dialogs as they would if the FortiGate was not present. However, the FortiGate can be configured to control which devices on the network can connect to the SIP proxy server and can also protect the SIP proxy server from SIP vulnerabilities.
The following diagram shows a FortiGate operating in NAT/Route mode and installed between a private network and the Internet. Some SIP phones and the SIP proxy server are connected to the private network and some SIP phones are connected to the Internet. The SIP phones on the Internet can connect to the SIP proxy server through the FortiGate and communication between SIP phones on the private network and SIP phones on the Internet must pass through the FortiGate.
(PhoneB@172.20.120.30) SIP proxy server. using the SIP proxy server virtual IP.
| 2. Phone A dials Phone B | ||
| by sending an INVITE request to the SIP proxy server. | 3. The proxy server looks up the SIP address of Phone B and forwards | 4. Phone B is notified of an incoming |
the INVITE request to Phone B. call by proxy server – phone rings.
Phone A and Phone B when Phone B answers
The phones and server use the same SIP dialog as they would if the FortiGate was not present. However, the FortiGate can be configured to control which devices on the network can connect to the SIP proxy server and can also protect the SIP proxy server from SIP vulnerabilities. In addition, the FortiGate has a firewall virtual IP that forwards packets sent to the SIP proxy server Internet IP address (172.20.120.50) to the SIP proxy server internal network IP address (10.31.101.30).
Since the FortiGate is operating in NAT/Route mode it must translate packet source and destination IP addresses (and optionally ports) as the sessions pass through the FortiGate. Also, the FortiGate must translate the addresses contained in the SIP headers and SDP body of the SIP messages. As well the FortiGate must open SIP and RTP pinholes through the FortiGate. SIP pinholes allow SIP signaling sessions to pass through the FortiGate between phones and between phones and SIP servers. RTP pinholes allow direct RTP communication between the SIP phones once the SIP dialog has established the SIP call. Pinholes are opened automatically by the FortiGate. Administrators do not add security policies for pinholes or for RTP sessions. All that is required is a security policy that accepts SIP traffic.
Opening an RTP pinhole means opening a port on a FortiGate interface to allow RTP traffic to use that port to pass through the FortiGate between the SIP phones on the Internet and SIP phones on the internal network. A pinhole only accepts packets from one RTP session. Since a SIP call involves at least two media streams (one from Phone A to Phone B and one from Phone B to Phone A) the FortiGate opens two RTP pinholes. Phone A sends RTP packets through a pinhole in port2 and Phone B sends RTP packets through a pinhole in port1. The FortiGate opens the pinholes when required by the SIP dialog and closes the pinholes when the SIP call is completed. The FortiGate opens new pinholes for each SIP call.
Each RTP pinhole actually includes two port numbers. The RTP port number as defined in the SIP message and an RTCP port number, which is the RTP port number plus 1. For example, if the SIP call used RTP port 3346 the FortiGate would create a pinhole for ports 3346 and 3347.
This section provides an overview of SIP messages and how they communicate information about SIP sessions and how SDP, RTP, and RTCP fits in with SIP communications.
SIP uses clear text messages to start, maintain, and end media sessions between SIP user agent clients (UACs) and user agent servers (UASs). These messages form a SIP dialog. A typical SIP dialog begins with an INVITE request message sent from a UAC to another UAC or to a UAS. The first INVITE request message attempts to start a SIP call and includes information about the sending UAC and the receiving UAC as well as information about the communication session.
If only two UACs are involved as shown below, the receiving UAC (Phone B) responds with a 180 Ringing and then a 200 OK SIP response message that informs Phone A that Phone B received and accepted the request. Phone A then sends an ACK message to notify Phone B that the SIP response was received. Phone A and Phone B can then participate in the RTP media session set up by the SIP messages.
When the phone call is complete, one of the UACs (in the example Phone B) hangs up sending a BYE request message to Phone A. Phone A then sends a 200 OK response to Phone B acknowledging that the session has ended.
| SIP Phone A
(Sending UAC PhoneA@10.31.101.20) |
SIP Phone B
(Receiving UAC PhoneB@10.31.101.30) |
that the request is accepted).
SIP Phone A received the response from SIP Phone B).
If a UAS in the form of a SIP proxy server is involved, similar messages are sent and received, but the proxy server participates as an intermediary in the initial call setup. In the example below the SIP proxy server receives the INVITE request from Phone A and forwards it to Phone B. The proxy server then sends a 100 Trying response to Phone A. Phone B receives the INVITE request and responds with a 180 Ringing and then a 200 OK SIP response message. These messages are received by the proxy server and forwarded to Phone A to notify Phone A that Phone B received and accepted the request. Phone A then sends an ACK message to notify Phone B that the SIP response was received. This response is received by the proxy server and forwarded to Phone B. Phone A and Phone B can then participate in the media session independently of the proxy server.
When the phone call is complete Phone B hangs up sending a BYE request message to Phone A. Phone A then sends a 200 OK response to Phone B acknowledging that the session has ended.
The SIP messages include SIP headers that contain names and addresses of Phone A, Phone B and the proxy server. This addressing information is used by the UACs and the proxy server during the call set up.
The SIP message body includes Session Description Protocol (SDP) statements that Phone A and Phone B use to establish the media session. The SDP statements specify the type of media stream to use for the session (for example, audio for SIP phone calls) and the protocol to use for the media stream (usually the Real Time Protocol (RTP) media streaming protocol).
Hardware accelerated RTP processing
Phone A includes the media session settings that it would like to use for the session in the INVITE message. Phone B includes its response to these media settings in the 200 OK response. Phone A’s ACK response confirms the settings that Phone A and Phone B then use for the media session.
FortiGates can offload RTP packet processing to network processor (NP) interfaces. This acceleration greatly enhances the overall throughput and resulting in near speed RTP performance.
SIP sessions always start with a SIP request message (also just called a SIP request). SIP request messages also establish, maintain, and terminate SIP communication sessions. The following table lists some common SIP request message types.
| Message Type | Description |
| INVITE | A client sends an INVITE request to invite another client to participate in a multimedia session. The INVITE request body usually contains the description of the session. |
| ACK | The originator of an INVITE message sends an ACK request to confirm that the final response to an INVITE request was received. If the INVITE request did not contain the session description, it must be included in the ACK request. |
| PRACK | In some cases, SIP uses provisional response messages to report on the progress of the response to a SIP request message. The provisional response messages are sent before the final SIP response message. Similar to an ACK request message, a PRACK request message is sent to acknowledge that a provisional response message has been received. |
| OPTIONS | The UA uses OPTIONS messages to get information about the capabilities of a SIP proxy. The SIP proxy server replies with a description of the SIP methods, session description protocols, and message encoding that are supported. |
| BYE | A client sends a BYE request to end a session. A BYE request from either end of the SIP session terminates the session. |
| CANCEL | A client sends a CANCEL request to cancel a previous INVITE request. A CANCEL request has no effect if the SIP server processing the INVITE sends a final response to the INVITE before receiving the CANCEL. |
response messages
| Message Type | Description |
| REGISTER | A client sends a REGISTER request to a SIP registrar server with information about the current location (IP address and so on) of the client. A SIP registrar server saves the information it receives in REGISTER requests and makes this information available to any SIP client or server attempting to locate the client. |
| Info | For distributing mid-session signaling information along the signaling path for a SIP call. I |
| Subscribe | For requesting the current state and state updates of a remote node. |
| Notify | Informs clients and servers of changes in state in the SIP network. |
| Refer | Refers the recipient (identified by the Request-URI) to a third party according to the contact information in the request. |
| Update | Opens a pinhole for new or updated SDP information. |
| Response codes
(1xx, 202, 2xx, 3xx, 4xx, 5xx, 6xx) |
Indicates the status of a transaction. For example: 200 OK, 202 Accepted, or 400 Bad Request. |
SIP response messages (often just called SIP responses) provide status information in response to SIP request messages. All SIP response messages include a response code and a reason phrase. There are five SIP response message classes. They are described below.
There are also two types of SIP response messages, provisional and final. Final response messages convey the result of the request processing, and are sent reliably. Provisional responses provide information on the progress of the request processing, but may not be sent reliably. Provisional response messages start with 1xx and are also called informational response messages.
Informational or provisional responses indicate that a request message was received and imply that the endpoint is going to process the request. Information messages may not be sent reliably and may not require an acknowledgment.
If the SIP implementation uses Provisional Response Acknowledgment (PRACK) (RFC 3262) then informational or provisional messages are sent reliably and require a PRACK message to acknowledge that they have been received.
Informational responses can contain the following reason codes and reason phrases:
100 Trying
SIP response messages
Success responses indicate that a request message was received, understood, and accepted. Success responses can contain the following reason codes and reason phrases:
200 OK
202 Accepted
Redirection responses indicate that more information is required for the endpoint to respond to a request message. Redirection responses can contain the following reason codes and reason phrases:
305 Use proxy
380 Alternative service
Client error responses indicate that a request message was received by a server that contains syntax that the server cannot understand (i.e. contains a syntax error) or cannot comply with. Client error responses include the following reason codes and reason phrases:
400 Bad request 401 Unauthorized
402 Payment required 403 Forbidden
404 Not found 405 Method not allowed
406 Not acceptable 407 Proxy authentication required
408 Request time-out 409 Conflict
410 Gone 411 Length required
413 Request entity too large 414 Request-URL too large
415 Unsupported media type 420 Bad extension
484 Address incomplete 483 Too many hops
486 Busy here 485 Ambiguous
488 Not acceptable here 487 Request canceled
Server error responses indicate that a server was unable to respond to a valid request message. Server error responses include the following reason codes and reason phrases:
502 Service unavailable
message start line
Global failure responses indicate that there are no servers available that can respond to a request message. Global failure responses include the following reason codes and reason phrases:
600 Busy everywhere
The first line in a SIP message is called the start line. The start line in a request message is called the requestline and the start line in a response message is called the status-line.
| Request-line | The first line of a SIP request message. The request-line includes the SIP message type, the SIP protocol version, and a Request URI that indicates the user or service to which this request is being addressed. The following example request-line specifies
the INVITE message type, the address of the sender of the message (inviter@example.com), and the SIP version: INVITE sip:inviter@example.com SIP/2.0 |
| Status-line | The first line of a SIP response message. The status-line includes the SIP protocol version, the response code, and the reason phrase. The example status-line includes the SIP version, the response code (200) and the reason phrase (OK).
SIP/2.0 200 OK |
Following the start line, SIP messages contain SIP headers (also called SIP fields) that convey message attributes and to modify message meaning. SIP headers are similar to HTTP header fields and always have the following format:
<header_name>:<value>
SIP messages can include the SIP headers listed in the following table:
SIP headers
| SIP Header | Description |
| Allow | Lists the set of SIP methods supported by the UA generating the message. All methods, including ACK and CANCEL, understood by the UA MUST be included in the list of methods in the Allow header field, when present. For example:
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE |
| Call-ID | A globally unique identifier for the call, generated by the combination of a random string and the sender’s host name or IP address. The combination of the To, From, and Call-ID headers completely defines a peer-to-peer SIP relationship between the sender and the receiver. This relationship is called a SIP dialog.
Call-ID: ddeg45e793@10.31.101.30 |
| Contact | Included in SIP request messages, the Contact header contains the SIP URI of the sender of the SIP request message. The receiver uses this URI to contact the sender.
For example: Contact: Sender <sip:sender@10.31.100.20>t |
| Content-Length | The number of bytes in the message body (in bytes).
Content-Length: 126 |
| Content-Type | In addition to SIP headers, SIP messages include a message body that contains information about the content or communication being managed by the SIP session. The Content-Type header specifies what the content of the SIP message is. For example, if you are using SIP with SDP, the content of the SIP message is SDP code.
Content-Type: application/sdp |
| CSeq | The command sequence header contains a sequence integer that is increased for each new SIP request message (but is not incremented in the response message). This header also includes the request name found in the request message requestline. For example:
CSeq: 1 INVITE |
| Expires | Gives the relative time after which the message (or content) expires. The actual time and how the header is used depends on the SIP method. For example:
Expires: 5 |
| From | Identifies the sender of the message. Responses to a message are sent to the address of the sender. The following example includes the sender’s name (Sender) and the sender’s SIP address (sender@10.31.101.20.):
From: Sender <sip:sender@10.31.101.20> |
headers
| SIP Header | Description |
| Max-forwards | An integer in the range 0-255 that limits the number of proxies or gateways that can forward the request message to the next downstream server. Also called the number of hops, this value is decreased every time the message is forwarded. This can also be useful when the client is attempting to trace a request chain that appears to be failing or looping in mid-chain.
For example: Max-Forwards: 30 |
| P-AssertedIdentity | The P-Asserted-Identity header is used among trusted SIP entities to carry the identity of the user sending a SIP message as it was verified by authentication. See RFC 3325. The header contains a SIP URI and an optional display-name, for example:
P-Asserted-Identity: “Example Person” <sip:10.31.101.50> |
| RAck | Sent in a PRACK request to support reliability of information or provisional response messages. It contains two numbers and a method tag. For example:
RAck: 776656 1 INVITE |
| Record-Route | Inserted into request messages by a SIP proxy to force future requests to be routed through the proxy. In the following example, the host at IP address 10.31.101.50 is a SIP proxy. The lr parameter indicates the URI of a SIP proxy in Record-Route headers.
Record-Route: <sip:10.31.101.50;lr> |
| Route | Forces routing for a request message through one or more SIP proxies. The following example includes two SIP proxies:
Route: <sip:172.20.120.10;lr>, <sip:10.31.101.50;lr> |
| RSeq | The RSeq header is used in information or provisional response messages to support reliability of informational response messages. The header contains a single numeric value. For example:
RSeq: 33456 |
| To | Identifies the receiver of the message. The address in this field is used to send the message to the receiver. The following example includes the receiver’s name (Receiver) and the receiver’s SIP address (receiver@10.31.101.30.):
To: Receiver <sip:receiver@10.31.101.30> |
| Via | Indicates the SIP version and protocol to be used for the SIP session and the address to which to send the response to the message that contains the Via field. The following example Via field indicates to use SIP version 2, UDP for media communications, and to send the response to 10.31.101.20 using port 5060.
Via: SIP/2.0/UDP 10.31.101.20:5060 |
30
The SIP message body and SDP session profiles
The SIP message body describes the session to be initiated. For example, in a SIP phone call the body usually includes audio codec types, sampling rates, server IP addresses and so on. For other types of SIP session the body could contain text or binary data of any type which relates in some way to the session. The message body is included in request and response messages.
Two possible SIP message body types:
l Session Description Protocol (SDP), most commonly used for SIP VoIP. l Multipurpose Internet Mail Extensions (MIME)
SDP is most often used for VoIP and FortiGates support SDP content in SIP message bodies. SDP is a textbased protocol used by SIP to control media sessions. SDP does not deliver media but provides a session profile that contains media details, transport addresses, parameter negotiation, and other session description metadata for the participants in a media session. The participants use the information in the session profile to negotiate how to communicate and to manage the media session. SDP is described by RFC 4566.
An SDP session profile always contains session information and may contain media information. Session information appears at the start of the session profile and media information (using the m= attribute) follows.
SDP session profiles can include the attributes listed in the following table.
| Attribute | Description |
| a= | Attributes to extend SDP in the form a=<attribute> or a=<attribute>:<value>. |
| b= | Contains information about the bandwidth required for the session or media in the form b=<bandwidth_type>:<bandwidth>. |
| c= | Connection data about the session including the network type (usually IN for Internet), address type (IPv4 or IPv6), the connection source address, and other optional information. For example:
c=IN IPv4 10.31.101.20 |
| i= | A text string that contains information about the session. For example:
i=A audio presentation about SIP |
| k= | Can be used to convey encryption keys over a secure and trusted channel. For example:
k=clear:444gdduudjffdee |
The SIP message body and SDP session profiles
| Attribute | Description |
| m= | Media information, consisting of one or more lines all starting with m= and containing details about the media including the media type, the destination port or ports used by the media, the protocol used by the media, and a media format description.
m=audio 49170 RTP 0 3 m-video 3345/2 udp 34 m-video 2910/2 RTP/AVP 3 56 Multiple media lines are needed if SIP is managing multiple types of media in one session (for example, separate audio and video streams). Multiple ports for a media stream are indicated using a slash. 3345/2 udp means UDP ports 3345 and 3346. Usually RTP uses even-numbered ports for data with the corresponding one-higher odd ports used for the RTCP session belonging to the RTP session. So 2910/2 RTP/AVP means ports 2910 and 2912 are used for RTP and 2911 and 2913 are used for RTCP. Media types include udp for an unspecified protocol that uses UDP, RTP or RTP/AVP for standard RTP and RTP/SAVP for secure RTP. |
| o= | The sender’s username, a session identifier, a session version number, the network type (usually IN for Internet), the address type (for example, IPv4 or IPv6), and the sending device’s IP address. The o= field becomes a universal identifier for this version of this session description. For example:
o=PhoneA 5462346 332134 IN IP4 10.31.101.20 |
| r= | Repeat times for a session. Used if a session will be repeated at one or more timed intervals. Not normally used for VoIP calls. The times can be in different formats. For example:
r=7d 1h 0 25h r=604800 3600 0 90000 |
| s= | Any text that describes the session or s= followed by a space. For example:
s=Call from inviter |
| t= | The start and stop time of the session. Sessions with no time restrictions (most VoIP calls) have a start and stop time of 0.
t=0 0 |
| v= | SDP protocol version. The current SDP version is 0 so the v= field is always:
v=0 |
| z= | Time zone adjustments. Used for scheduling repeated sessions that span the time between changing from standard to daylight savings time.
z=2882844526 -1h 2898848070 0 |
The following example SIP INVITE request message was sent by PhoneA to PhoneB. The first nine lines are the SIP headers. The SDP profile starts with v=0 and the media part of the session profile is the last line, starting with m=.
INVITE sip:PhoneB@172.20.120.30 SIP/2.0
Via: SIP/2.0/UDP 10.31.101.50:5060
From: PhoneA <sip:PhoneA@10.31.101.20>
To: PhoneB <sip:PhoneB@172.20.120.30>
Call-ID: 314159@10.31.101.20
CSeq: 1 INVITE
Contact: sip:PhoneA@10.31.101.20
Content-Type: application/sdp
Content-Length: 124 v=0
o=PhoneA 5462346 332134 IN IP4 10.31.101.20 s=Let’s Talk t=0 0
c=IN IP4 10.31.101.20 m=audio 49170 RTP 0 3
The following example shows a possible 200 OK SIP response message in response to the previous INVITE request message. The response includes 200 OK which indicates success, followed by an echo of the original SIP INVITE request followed by PhoneB’s SDP profile.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.31.101.50:5060
From: PhoneA <sip:PhoneA@10.31.101.20>
To: PhoneB <sip:PhoneB@172.20.120.30>
Call-ID: 314159@10.31.101.20
CSeq: 1 INVITE
Contact: sip:PhoneB@10.31.101.30
Content-Type: application/sdp
Content-Length: 107 v=0 o=PhoneB 124333 67895 IN IP4 172.20.120.30 s=Hello! t=0 0
c=IN IP4 172.20.120.30 m=audio 3456 RTP 0
SIP can support multiple media streams for a single SIP session. Each media steam will have its own c= and m= lines in the body of the message. For example, the following message includes three media streams:
INVITE sip:PhoneB@172.20.120.30 SIP/2.0
Via: SIP/2.0/UDP 10.31.101.20:5060
From: PhoneA <sip:PhoneA@10.31.101.20>
To: PhoneB <sip:PhoneB@172.20.120.30>
Call-ID: 314159@10.31.101.20
CSeq: 1 INVITE
Contact: sip:PhoneA@10.31.101.20
Content-Type: application/sdp
Content-Length: 124 v=0
o=PhoneA 5462346 332134 IN IP4 10.31.101.20 s=Let’s Talk
Example SIP messages
t=0 0 c=IN IP4 10.31.101.20 m=audio 49170 RTP 0 3 c=IN IP4 10.31.101.20 m=audio 49172 RTP 0 3 c=IN IP4 10.31.101.20 m=audio 49174 RTP 0 3
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:
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.
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
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 .
. .
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
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
| 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 |
| Incoming Interface | port1 |
| Outgoing Interface | port2 |
| Source | Phone_A |
| Destination Address | Phone_B |
| Schedule | always |
| Service | SIP |
| Action | ACCEPT |
| Incoming Interface | port2 |
| Outgoing Interface | port1 |
| Source Address | Phone_B |
| Destination Address | Phone_A |
| Schedule | always |
| Service | SIP |
| Action | ACCEPT |
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
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
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
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:
SIP session helper diagnose commands
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
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).
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.
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
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
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
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}
The Fortinet GURU store is officially open. The full arsenal of products aren’t there just yet but you guys are welcome to do your FortiBUYING here now! Going to have some specials and more that will enable you to really take advantage as well!
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.
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.
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.
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.
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
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.
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.
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
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.
| 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 |
| Incoming Interface | port1 |
| Outgoing Interface | port2 |
| Source | Phone_A |
| Destination Address | Phone_B |
| Schedule | always |
| Service | SIP |
| Action | ACCEPT |
| Incoming Interface | port2 |
| Outgoing Interface | port1 |
| Source | Phone_B |
| Destination Address | Phone_A |
| Schedule | always |
| Service | SIP |
| Action | ACCEPT |
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
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
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
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.
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
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.
When a SIP call is started by a phone on a private network destined for a phone on the Internet, only source address translation is required. The phone on the private network attempts to contact the actual IP address of the phone on the Internet. However, the source address of the phone on the private network is not routable on the Internet so the SIP ALG must translate all private IP addresses in the SIP message into public IP addresses.
To configure the FortiGate for source address translation you add security policy that accepts sessions from the internal network destined for the Internet. You must enable NAT for the security policy and add a VoIP profile.
When a SIP request is received from the internal to the external network, the SIP ALG replaces the private network IP addresses and port numbers in the SIP message with the IP address of the FortiGate interface connected to the Internet. Depending on the content of the message, the ALG translates addresses in the Via:, Contact:, Route:, and Record-Route: SIP header fields. The message is then forwarded to the destination (either a VoIP phone or a SIP server on the Internet).
The VoIP phone or server in the Internet sends responses to these SIP messages to the external interface of the FortiGate. The addresses in the response messages are translated back into private network addresses and the response is forwarded to the originator of the request.
For the RTP communication between the SIP phones, the SIP ALG opens pinholes to allow media through the FortiGate on the dynamically assigned ports negotiated based on information in the SDP and the Via:, Contact:, and Record-Route: header fields. The pinholes also allow incoming packets to reach the Contact:, Via:, and Record-Route: IP addresses and ports. When processing return traffic, the SIP ALG inserts the original Contact:, Via:, Route:, and Record-Route: SIP fields back into the packets.
Incoming calls are directed from a SIP phone on the Internet to the interface of the FortiGate connected to the Internet. To receive these calls you must add a security policy to accept SIP sessions from the Internet. The security policy requires a firewall virtual IP. SIP INVITE messages from the Internet connect to the external IP address of the virtual IP. The SIP ALG uses the destination address translation defined in the virtual IP to translated the addresses in the SIP message to addresses on the private network.
When a 200 OK response message arrives from the private network, the SIP ALG translates the addresses in the message to Internet addresses and opens pinholes for media sessions from the private network to the Internet.
When the ACK message is received for the 200 OK, it is also intercepted by the SIP ALG. If the ACK message contains SDP information, the SIP ALG checks to determine if the IP addresses and port numbers are not changed from the previous INVITE. If they are, the SIP ALG deletes pinholes and creates new ones as required. The ALG also monitors the Via:, Contact:, and Record-Route: SIP fields and opens new pinholes as required.
SIP Re-INVITE messages can dynamically add and remove media sessions during a call. When new media sessions are added to a call the SIP ALG opens new pinholes and update SIP dialog data. When media sessions are ended, the SIP ALG closes pinholes that are no longer needed and removes SIP dialog data.