How the SIP ALG translates IP addresses in SIP headers

The SIP ALG applies NAT to SIP sessions by translating the IP addresses contained in SIP headers. For example, the following SIP message contains most of the SIP fields that contain addresses that need to be translated:

INVITE PhoneB@172.20.120.30 SIP/2.0

Via: SIP/2.0/UDP 172.20.120.50:5434

From: PhoneA@10.31.101.20

To: PhoneB@172.20.120.30

Call-ID: a12abcde@172.20.120.50

Contact: PhoneA@10.31.101.20:5434

Route: <sip:example@172.20.120.50:5060>

Record-Route: <sip:example@172.20.120.50:5060>

How the SIP ALG translates IP addresses in SIP headers

How IP address translation is performed depends on whether source NAT or destination NAT is applied to the session containing the message:

Source NAT translation of IP addresses in SIP messages

Source NAT translation occurs for SIP messages sent from a phone or server on a private network to a phone or server on the Internet. The source addresses in the SIP header fields of the message are typically set to IP addresses on the private network. The SIP ALG translates these addresses to the address the FortiGate interface connected to the Internet.

Source NAT translation of IP addresses in SIP request messages

Response messages from phones or servers on the Internet are sent to the FortiGate interface connected to the Internet where the destination addresses are translated back to addresses on the private network before forwarding the SIP response message to the private network.

Source NAT translation of IP addresses in SIP response messages

How the SIP ALG translates IP addresses in SIP headers

Destination NAT translation of IP addresses in SIP messages

Destination NAT translation occurs for SIP messages sent from a phone or server on the Internet to a firewall virtual IP address. The destination addresses in the SIP header fields of the message are typically set to the virtual IP address. The SIP ALG translates these addresses to the address of a SIP server or phone on the private network on the other side of the FortiGate.

Destination NAT translation of IP addresses in SIP request messages

SIP response messages sent in response to the destination NAT translated messages are sent from a server or a phone on the private network back to the originator of the request messages on the Internet. These reply

How the SIP ALG translates IP addresses in the SIP body

messages are accepted by the same security policy that accepted the initial request messages, The firewall VIP in the original security policy contains the information that the SIP ALG uses to translate the private network source addresses in the SIP headers into the firewall virtual IP address.

Destination NAT translation of IP addresses in SIP response messages

How the SIP ALG translates IP addresses in the SIP body

The SDP session profile attributes in the SIP body include IP addresses and port numbers that the SIP ALG uses to create pinholes for the media stream.

The SIP ALG translates IP addresses and port numbers in the o=, c=, and m= SDP lines. For example, in the following lines the ALG could translate the IP addresses in the o= and c= lines and the port number (49170) in the m= line.

o=PhoneA 5462346 332134 IN IP4 10.31.101.20 c=IN IP4 10.31.101.20 m=audio 49170 RTP 0 3

If the SDP session profile includes multiple RTP media streams, the SIP ALG opens pinholes and performs the required address translation for each one.

The two most important SDP attributes for the SIP ALG are c= and m=. The c= attribute is the connection information attribute. This field can appear at the session or media level. The syntax of the connection attribute is:

c=IN {IPV4 | IPV6} <destination_ip_address> Where l IN is the network type. FortiGates support the IN or Internet network type.

• {IPV4 | IPV6} is the address type. FortiGates support IPv4 or IPv6 addresses in SDP statements. However, FortiGates do not support all types of IPv6 address translation. See SIP over IPv6 on page 95.
• <destination_IP_address> is the unicast numeric destination IP address or domain name of the connection in either IPv4 or IPv6 format.

source address translation (source NAT)

The syntax of the media attribute is:

m=audio <port_number> RTP <format_list> Where l audio is the media type. FortiGates support the audio media type. l <port_number> is the destination port number used by the media stream.

• RTP is the application layer transport protocol used for the media stream. FortiGates support the Real Time Protocol (RTP) transport protocol. l <format_list> is the format list that provides information about the application layer protocol that the media uses.

SIP NAT scenario: source address translation (source NAT)

The following figures show a source address translation scenario involving two SIP phones on different networks, separated by a FortiGate. In the scenario, SIP Phone A sends an INVITE request to SIP Phone B and SIP Phone B replies with a 200 OK response and then the two phones start media streams with each other.

To simplify the diagrams, some SIP messages are not included (for example, the Ringing and ACK response messages) and some SIP header lines and SDP profile lines have been removed from the SIP messages.

SIP NAT scenario: source address translation (source

SIP source NAT scenario part 1: INVITE request sent from Phone A to Phone B

For the replies to SIP packets sent by Phone A to be routable on Phone Bs network, the FortiGate uses source NAT to change their source address to the address of the WAN1 interface. The SIP ALG makes similar changes the source addresses in the SIP headers and SDP profile. For example, the original INVITE request from Phone A includes the address of Phone A (10.31.101.20) in the from header line. After the INVITE request passes through the FortiGate, the address of Phone A in the From SIP header line is translated to 172.20.120.122, the address of the FortiGate WAN1 interface. As a result, Phone B will reply to SIP messages from Phone A using the WAN1 interface IP address.

The FortiGate also opens a pinhole so that it can accept media sessions sent to the WAN1 IP address using the port number in the m= line of the INVITE request and forward them to Phone A after translating the destination address to the IP address of Phone A.

Phone B sends the 200 OK response to the INVITE message to the WAN1 interface. The SDP profile includes the port number that Phone B wants to use for its media stream. The FortiGate forwards 200 OK response to Phone A after translating the addresses in the SIP and SDP lines back to the IP address of Phone A. The SIP ALG also source address translation (source NAT)

opens a pinhole on the Internal interface that accepts media stream sessions from Phone A with destination address set to the IP address of Phone B and using the port that Phone B added to the SDP m= line.

SIP NAT scenario: destination address translation (destination NAT)

The following figures show how the SIP ALG translates addresses in a SIP INVITE message sent from SIP Phone B on the Internet to SIP Phone A on a private network using the SIP proxy server. Because the addresses on the private network are not visible from the Internet, the security policy on the FortiGate that accepts SIP sessions includes a virtual IP. Phone A sends SIP the INVITE message to the virtual IP address. The FortiGate accepts the INVITE message packets and using the virtual IP, translates the destination address of the packet to the IP address of the SIP proxy server and forwards the SIP message to it.

SIP destination NAT scenario part 1: INVITE request sent from Phone B to Phone A

To simplify the diagrams, some SIP messages are not included (for example, the Ringing and ACK response messages) and some SIP header lines and SDP profile lines have been removed from the SIP messages. destination address translation (destination NAT)

The SIP ALG also translates the destination addresses in the SIP message from the virtual IP address (172.20.120.50) to the SIP proxy server address (10.31.101.50). For this configuration to work, the SIP proxy server must be able to change the destination addresses for Phone A in the SIP message from the address of the SIP proxy server to the actual address of Phone A.

The SIP ALG also opens a pinhole on the Port2 interface that accepts media sessions from the private network to SIP Phone B using ports 4900 and 4901.

Phone A sends a 200 OK response back to the SIP proxy server. The SIP proxy server forwards the response to Phone B. The FortiGate accepts the 100 OK response. The SIP ALG translates the Phone A addresses back to the SIP proxy server virtual IP address before forwarding the response back to Phone B. The SIP ALG also opens a pinhole using the SIP proxy server virtual IP which is the address in the o= line of the SDP profile and the port number in the m= line of the SDP code.

SIP NAT scenario: destination address translation (destination

SIP destination NAT scenario part 2: 200 OK returned to Phone B and media streams established

The media stream from Phone A is accepted by pinhole one and forwarded to Phone B. The source address of this media stream is changed to the SIP proxy server virtual IP address. The media stream from Phone B is accepted by pinhole 2 and forwarded to Phone B. The destination address of this media stream is changed to the IP address of Phone A.

SIP NAT configuration example: source address translation (source NAT)

This configuration example shows how to configure the FortiGate to support the source address translation scenario shown below. 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. Both of these policies must include source NAT. In this example the networks are not hidden from each other so destination NAT is not required.

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 firewall service to ANY to allow traffic other than SIP on UDP port 5060.

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

Configuration steps – GUI

To add firewall addresses for the SIP phones

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

SIP NAT configuration example: source address translation (source

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

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

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

7. Turn on NAT and select Use Outgoing Interface Address.
8. Turn on VoIP and select the default VoIP profile.
9. 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 internal set type ipmask

set subnet 10.31.101.20 255.255.255.255

next edit Phone_B set associated interface wan1 set type ipmask

set subnet 172.20.120.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 internal set dstintf wan1 set srcaddr Phone_A set dstaddr Phone_B set action accept set schedule always set service SIP set nat enable set utm-status enable set voip-profile default

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

SIP NAT configuration example: destination address translation (destination NAT)

This configuration example shows how to configure the FortiGate to support the destination address translation scenario shown in the figure below. The FortiGate requires two SIP security policies:

l A destination NAT security policy that allows SIP messages to be sent from the Internet to the private network. This policy must include destination NAT because the addresses on the private network are not routable on the Internet. l A source NAT security policy that allows SIP messages to be sent from the private network to the Internet.

SIP destination NAT scenario part two: 200 OK returned to Phone B and media streams established

FortiGate HA cluster in NAT mode

General configuration steps

The following general configuration steps are required for this destination NAT SIP configuration. This example uses the default VoIP profile.

1. Add the SIP proxy server firewall virtual IP.
2. Add a firewall address for the SIP proxy server on the private network.
3. Add a destination NAT security policy that accepts SIP sessions from the Internet destined for the SIP proxy server virtual IP and translates the destination address to the IP address of the SIP proxy server on the private network.
4. Add a security policy that accepts SIP sessions initiated by the SIP proxy server and destined for the Internet.

Configuration steps – GUI

To add the SIP proxy server firewall virtual IP

1. Go to Policy & Objects > Virtual IPs.
2. Add the following SIP proxy server virtual IP.

destination address translation (destination NAT)

To add a firewall address for the SIP proxy server

1. Go to Policy & Objects > Addresses.
2. Add the following for the SIP proxy server:

To add the security policies

1. Go to Policy & Objects > IPv4 Policy.
2. Add a destination NAT security policy that includes the SIP proxy server virtual IP that allows Phone B (and other SIP phones on the Internet) to send SIP request messages to the SIP proxy server.

3. Turn on NAT and select Use Outgoing Interface Address.
4. Turn on VoIP and select the default VoIP profile.
5. Select OK.
6. Add a source NAT security policy to allow the SIP proxy server to send SIP request messages to Phone B and the

Internet:

SIP NAT configuration example: destination address translation (destination

7. Turn on NAT and select Use OutgingInterface Address.
8. Turn on VoIP and select the default VoIP profile.
9. Select OK.

Configuration steps – CLI

To add the SIP proxy server firewall virtual IP and firewall address

1. Enter the following command to add the SIP proxy server firewall virtual IP. config firewall vip edit SIP_Proxy_VIP set type static-nat set extip 172.20.120.50 set mappedip 10.31.101.50 set extintf port1

end

2. Enter the following command to add the SIP proxy server firewall address. config firewall address edit SIP_Proxy_Server set associated interface port2 set type ipmask

set subnet 10.31.101.50 255.255.255.255

end

To add security policies

1. Enter the following command to add a destination NAT security policy that includes the SIP proxy server virtual IP that allows Phone B (and other SIP phones on the Internet) to send SIP request messages to the SIP proxy server.

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

and RTP source NAT

2. Enter the following command to add a source NAT security policy to allow the SIP proxy server to send SIP request messages to Phone B and the Internet:

config firewall policy edit 0 set srcintf port2 set dstintf port1 set srcaddr SIP_Proxy_Server

set dstaddr all set action accept set schedule always set service SIP set nat enable set utm-status enable set voip-profile default end

SIP and RTP source NAT

In the source NAT scenario shown below, a SIP phone connects to the Internet through a FortiGate with and IP address configured using PPPoE. The SIP ALG translates all private IPs in the SIP contact header into public IPs.

You need to configure an internal to external SIP security policy with NAT selected, and include a VoIP profile with SIP enabled.

SIP source NAT

SIP and RTP destination NAT

SIP and RTP destination NAT

In the following destination NAT scenario, a SIP phone can connect through the FortiGate to private IP address using a firewall virtual IP (VIP). The SIP ALG translates the SIP contact header to the IP of the real SIP proxy server located on the Internet.

SIP destination NAT

In the scenario, shown above, the SIP phone connects to a VIP (10.72.0.60). The SIP ALG translates the SIP contact header to 217.10.79.9, opens RTP pinholes, and manages NAT.

The FortiGate also supports a variation of this scenario where the RTP media server’s IP address is hidden on a private network or DMZ.

Source NAT with an IP pool

SIP destination NAT-RTP media server hidden

In the scenario shown above, a SIP phone connects to the Internet. The VoIP service provider only publishes a single public IP. The FortiGate is configured with a firewall VIP. The SIP phone connects to the FortiGate (217.233.90.60) and using the VIP the FortiGate translates the SIP contact header to the SIP proxy server IP address (10.0.0.60). The SIP proxy server changes the SIP/SDP connection information (which tells the SIP phone which RTP media server IP it should contact) also to 217.233.90.60.

Source NAT with an IP pool

You can choose NAT with the Dynamic IP Pool option when configuring a security policy if the source IP of the SIP packets is different from the interface IP. The FortiGate ALG interprets this configuration and translates the SIP header accordingly.

This configuration also applies to destination NAT.

FortiGate marketing isn’t always on point. Let’s face it, a lot of people got confused with the naming convention on the E models back in 2016. This covers some basics that will hopefully provide insight so you can buy the right device for you.

Different source and destination NAT for SIP and RTP

This is a more complex scenario that a SIP service provider may use. It can also be deployed in large-scale SIP environments where RTP has to be processed by the FortiGate and the RTP server IP has to be translated differently than the SIP serverIP.

NAT with IP address conservation

Different source and destination NAT for SIP and RTP

RTP servers

192.168.0.21 – 192.168.0.23                            219.29.81.10

In this scenario, shown above, assume there is a SIP server and a separate media gateway. The SIP server is configured so that the SIP phone (219.29.81.20) will connect to 217.233.90.60. The media gateway (RTP server:

219.29.81.10) will connect to 217.233.90.65.

What happens is as follows:

1. The SIP phone connects to the SIP VIP. The FortiGate ALG translates the SIP contact header to the SIP server: 219.29.81.20 > 217.233.90.60 (> 10.0.0.60).
2. The SIP server carries out RTP to 217.233.90.65.
3. The FortiGate ALG opens pinholes, assuming that it knows the ports to be opened.
4. RTP is sent to the RTP-VIP (217.233.90.65.) The FortiGate ALG translates the SIP contact header to 192.168.0.21.

NAT with IP address conservation

In a source or destination NAT security policy that accepts SIP sessions, you can configure the SIP ALG or the SIP session helper to preserve the original source IP address of the SIP message in the i= line of the SDP profile. NAT with IP address conservation (also called SIP NAT tracing) changes the contents of SIP messages by adding the source IP address of the originator of the message into the SDP i= line of the SIP message. The SDP i= line is used for free-form text. However, if your SIP server can retrieve information from the SDP i= line, it can be useful for keeping a record of the source IP address of the originator of a SIP message when operating in a NAT environment. You can use this feature for billing purposes by extracting the IP address of the originator of the message.

Configuring SIP IP address conservation for the SIP ALG

You can use the following command to enable or disable SIP IP address conservation in a VoIP profile for the SIP ALG. SIP IP address conservation is enabled by default in a VoIP profile.

config voip profile edit VoIP_Pro_1 config sip set nat-trace disable

end

end

If the SIP message does not include an i= line and if the original source IP address of the traffic (before NAT) was 10.31.101.20 then the FortiGate would add the following i= line.

i=(o=IN IP4 10.31.101.20)

You can also use the preserve-override option to configure the SIP ALG to either add the original o= line to the end of the i= line or replace the i= line in the original message with a new i= line in the same form as above for adding a new i= line.

By default, preserver-override is disabled and the SIP ALG adds the original o= line to the end of the original i= line. Use the following command to configure the SIP ALG to replace the original i= line:

config voip profile edit VoIP_Pro_1 config sip set preserve-override enable

end

end

Configuring SIP IP address conservation for the SIP session helper

You can use the following command to enable or disable SIP IP address conservation for the SIP session helper. IP address conservation is enabled by default for the SIP session helper.

config system settings set sip-nat-trace disable

end

If the SIP message does not include an i= line and if the original source IP address of the traffic (before NAT) was 10.31.101.20 then the FortiGate would add the following i= line.

i=(o=IN IP4 10.31.101.20)

Controlling how the SIP ALG NATs SIP contact header line addresses

You can enable contact-fixup so that the SIP ALG performs normal SIP NAT translation to SIP contact headers as SIP messages pass through the FortiGate.

Disable contact-fixup if you do not want the SIP ALG to perform normal NAT translation of the SIP contact header if a Record-Route header is also available. If contact-fixup is disabled, the FortiGate ALG does the following with contact headers:

• For Contact in Requests, if a Record-Route header is present and the request comes from the external network, the SIP Contact header is not translated.

Controlling NAT for addresses in SDP lines

• For Contact in Responses, if a Record-Route header is present and the response comes from the external network, the SIP Contact header is not translated.

If contact-fixup is disabled, the SIP ALG must be able to identify the external network. To identify the external network, you must use the config system interface command to set the external keyword to enable for the interface that is connected to the external network.

Enter the following command to perform normal NAT translation of the SIP contact header:

config voip profile edit VoIP_Pro_1 config sip set contact-fixup enable

end

end

Controlling NAT for addresses in SDP lines

You can use the no-sdp-fixup option to control whether the FortiGate performs NAT on addresses in SDP lines in the SIP message body.

The no-sdp-fixup option is disabled by default and the FortiGate performs NAT on addresses in SDP lines. Enable this option if you don’t want the FortiGate to perform NAT on the addresses in SDP lines.

config voip profile edit VoIP_Pro_1 config sip set no-sdp-fixup enable

end

end

Translating SIP session destination ports

Using port forwarding virtual IPs you can change the destination port of SIP sessions as they pass through the FortiGate.

Translating SIP sessions to a different destination port

To configure translating SIP sessions to a different destination port you must add a static NAT virtual IP that translates tie SIP destination port to another port destination. In the example the destination port is translated from 5060 to 50601. This configuration can be used if SIP sessions uses different destination ports on different networks.

Translating SIP session destination ports

Example translating SIP sessions to a different destination port

To translate SIP sessions to a different destination port

1. Add the static NAT virtual IP.

This virtual IP forwards traffic received at the port1 interface for IP address 172.20.120.20 and destination port 5060 to the SIP server at IP address 192.168.10.20 with destination port 5061.

config firewall vip edit “sip_port_trans_vip” set type static-nat set portforward enable set protocol tcp set extip 172.20.120.20 set extport 5060 set extintf “port1” set mappedip 192.168.10.20 set mappedport 50601

set comment “Translate SIP destination port”

end

2. Add a security policy that includes the virtual IP and the default VoIP profile.

config firewall policy edit 1 set srcintf “port1” set dstintf “port2” set srcaddr “all”

Translating SIP sessions to multiple destination ports

set dstaddr “sip_port_trans_vip” set action accept set schedule “always” set service “ANY” set utm-status enable

set profile-protocol-options default set comments “Translate SIP destination port” end

Translating SIP sessions to multiple destination ports

You can use a load balance virtual IP to translate SIP session destination ports to a range of destination ports. In this example the destination port is translated from 5060 to the range 50601 to 50603. This configuration can be used if your SIP server is configured to receive SIP traffic on multiple ports.

Example translating SIP traffic to multiple destination ports

To translated SIP sessions to multiple destination ports

1. Add the load balance virtual IP.

Adding the original IP address and port to the SIP message header after NAT

This virtual IP forwards traffic received at the port1 interface for IP address 172.20.120.20 and destination port 5060 to the SIP server at IP address 192.168.10.20 with destination port 5061.

config firewall vip edit “sip_port_ldbl_vip” set type load-balance set portforward enable set protocol tcp set extip 172.20.120.20 set extport 5060 set extintf “port1” set mappedip 192.168.10.20 set mappedport 50601-50603

set comment “Translate SIP destination port range”

end

2. Add a security policy that includes the virtual IP and VoIP profile. config firewall policy edit 1 set srcintf “port1” set dstintf “port2” set srcaddr “all” set dstaddr “sip_port_ldbl_vip” set action accept set schedule “always” set service “ANY” set utm-status enable set voip-profile default

set comments “Translate SIP destination port” end

Adding the original IP address and port to the SIP message header after NAT

In some cases your SIP configuration may require that the original IP address and port from the SIP contact request is kept after NAT. For example, the original SIP contact request could include the following:

Contact: <sip:0150302438@172.20.120.110:5060>;

After the packet goes through the FortiGate and NAT is performed, the contact request could normally look like the following (the IP address translated to a different IP address and the port to a different port):

Contact: <sip:0150302438@10.10.10.21:33608>;

You can enable register-contact-trace in a VoIP profile to have the SIP ALG add the original IP address and port in the following format:

Contact: <sip:0150302438@<nated-ip>:<nated-port>;o=<original-ip>: <original-port>>; So the contact line after NAT could look like the following:

Contact: <sip:0150302438@10.10.10.21:33608;o=172.20.120.110:5060>; Enter the following command to enable keeping the original IP address and port:

config voip profile edit Profile_name config sip set register-contract-trace enable

end

Enhancing SIP pinhole security

You can use the strict-register option in a SIP VoIP profile to open smaller pinholes. This option is enabled by default on the default VoIP profiles and in all new VoIP profiles that you create.

As shown below, when FortiGate is protecting a SIP server on a private network, the FortiGate does not have to open a pinhole for the SIP server to send INVITE requests to a SIP Phone on the Internet after the SIP Phone has registered with the server.

FortiGate protecting a SIP server on a private network

In the example, a client (SIP Phone A) sends a REGISTER request to the SIP server with the following information:

Client IP: 10.31.101.20

Server IP: 10.21.101.50

Port: UDP (x,5060)

REGISTER Contact: 10.31.101.20:y Where x and y are ports chosen by Phone A.

As soon as the server sends the 200 OK reply it can forward INVITE requests from other SIP phones to SIP Phone A. If the SIP proxy server uses the information in the REGISTER message received from SIP Phone A the INVITE messages sent to Phone A will only get through the FortiGate if a policy has been added to allow the server to send traffic from the private network to the Internet. Or the SIP ALG must open a pinhole to allow traffic from the server to the Internet. In most cases the FortiGate is protecting the SIP server so there is no reason not to add a security policy to allow the SIP server to send outbound traffic to the Internet.

In a typical SOHO scenario, shown below, SIP Phone A is being protected from the Internet by a FortiGate. In most cases the FortiGate would not allow incoming traffic from the Internet to reach the private network. So the only way that an INVITE request from the SIP server can reach SIP Phone A is if the SIP ALG creates an incoming pinhole. All pinholes have three attributes:

(source address, destination address, destination port)

SOHO configuration, FortiGate protecting a network with SIP phones

Enhancing SIP pinhole security                Adding the original IP address and port to the SIP message header after NAT

The more specific a pinhole is the more secure it is because it accept less traffic. In this situation, the pinhole would be more secure if it only accepted traffic from the SIP server. This is what happens if strict-register is enabled in the VoIP profile that accepts the REGISTER request from Phone A.

(SIP server IP address, client IP address, destination port)

If strict-register is disabled (the default configuration) the pinhole is set up with the following attributes

(ANY IP address, client IP address, destination port)

This pinhole allows connections through the FortiGate from ANY source address which is a much bigger and less secure pinhole. In most similar network configurations you should enable strict-register to improve pinhole security.

Enabling strict-register can cause problems when the SIP registrar and SIP proxy server are separate entities with separate IP addresses.

Enter the following command to enable strict-register in a VoIP profile.

config voip profile edit Profile_name config sip set strict-register enable

end