Category Archives: FortiOS 5.4 Handbook

The complete handbook for FortiOS 5.4

How the SIP ALG performs NAT

Leave a reply

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 unit 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.

 

Source address translation

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 unit. 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 unit 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.

 

Destination address translation

Incoming calls are directed from a SIP phone on the Internet to the interface of the FortiGate unit 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.

Accepting SIP register responses

Leave a reply

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 unit 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

Opening and closing SIP register, contact, via and record-route pinholes

Leave a reply

Opening and closing SIP register, contact, via and record-route pinholes

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

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

If open-contact-pinhole is enabled (the default setting) the FortiGate unit opens pinholes for non-Register SIP request messages. You can disable open-contact-pinhole so that the FortiGate unit 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 unit does not open pinholes for Via messages. You can enable open-via-pinhole so that the FortiGate unit opens pinholes for Via messages.

If open-record-route-pinhole is enabled (the default setting) the FortiGate unit opens pinholes for Record-Route messages. You can disable open-record-route-pinhole so that the FortiGate unit 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 unit. 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 non- register 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

end

set open-register-pinhole disable set open-contact-pinhole disable

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 unit is installed between two SIP servers and the only SIP traffic through the FortiGate unit 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.

RTP enable/disable (RTP bypass)

Leave a reply

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 signalling messages but do not want the RTP media streams to pass through the FortiGate unit. The FortiGate unit only acts as a signalling firewall and RTP media session bypass the FortiGate unit 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

Configuration example: SIP in Transparent Mode

Leave a reply

Configuration example: SIP in Transparent Mode

The figure below hows an example SIP network consisting of a FortiGate unit operating in Transparent mode between two SIP phones. Since the FortiGate unit is operating in Transparent mode both phones are on the same network and the FortiGate unit 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 unit 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 unit in Transparent mode

o

Po                                                         Port2

 

SIP Phone A (PhoneA@10.31.101.20)

rt1                                                     P

FortiGate unit in Transparent mode SIP Phone B (PhoneB@10.31.101.30)

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 – web-based manage

Before you begin this procedure you may have to go to System > Feature Select and turn on VoIP.

 

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

How the SIP ALG creates RTP pinholes

Leave a reply

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 unit operating in Transparent mode. Phone A and Phone B are on the same subnet. The FortiGate unit includes a security policy that accepts SIP sessions from port1 to port2 and from port2 to port1. The FortiGate unit 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 unit. 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 unit. Pinhole 2 is opened on the Port1 interface and will accept media traffic sent from Phone A to Phone B.

 

 

SIP call setup with a FortiGate unit in Transparent mode

 

 

 

ort1                                                  Po

 

 

 

 

FortiGate unit

P   t                                                    Port2

SIP Phone A (PhoneA@10.31.101.20)

in Transparent mode

SIP Phone B (PhoneB@10.31.101.30)

  1. Phone A sends an INVITE request to Phone B (SDP 10.31.101.20:4000)
  1. SIP ALG creates Pinhole 1. Accepts traffic on Port2 with destination address:port numbers 10.31.101.20:4000 and 4001
  1. The SIP ALG forwards the INVITE request Phone B.
  1. Phone B sends a 200 OK response to Phone A (SDP: 10.31.101.30:8000)
  1. SIP ALG creates Pinhole 2. Accepts traffic on Port1 with destination address:port numbers 10.31.101.30:8000 and 8001
  1. Phone B sends RTP and RTCP media sessions to Phone A through pinhole 1. Destination address:port number 172.20.120.20:4000 and 4001 Pinhole 1
  1. Phone A sends RTP and RTCP media sessions to Phone B through pinhole 2. Destination address:port number 172.20.120.30:8000 and 8001 Pinhole 2

SIP and RTP/RTCP

Leave a reply

SIP and RTP/RTCP

FortiGate units 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.

Stateful SIP tracking, call termination, and session inactivity timeout

2 Replies

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 unit 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:

  • Phones or servers crash during a call and a BYE message is not received.
  • To attack a SIP system, a malicious user never send a BYE message.
  • Poor implementations of SIP fail to process Record-Route messages and never send a BYE message.
  • 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 unit, 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 unit 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 unit 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 unit if they are sent after the FortiGate unit 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 unit 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

config sip

set provisional-invite-expiry-time 100 end

end