Category Archives: FortiOS

FortiGate Upgrade Paths

If you are looking to upgrade your FortiGate to the latest version of code you need to stop and read the links listed below. There is a supported upgrade path for each version of FortiOS (4, 5, 5.2, 5.4, etc). If you want to progress through the versions of code without nuking parts of your config or causing yourself to experience strange explainable behavior (that’s a trick question since it is definitely explainable….you didn’t follow the upgrade path!) then you please follow these instructions.

Click the link below and scroll down to the “The Upgrade Path Tables”. This page will tell you how to get to the version of code that you wish in a safe and secure manner!

Click Here To View Upgrade Path Tables


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

Enhancing SIP pinhole security

Enhancing SIP pinhole security

You can use the strict-register option in a SIP VoIP profile to open smaller pinholes.

As shown below, when FortiGate unit is protecting a SIP server on a private network, the FortiGate unit 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 unit protecting a SIP server on a private network

FortiGate unit

In NAT/Route mode

Port

172.20.1  0.1

 

SIP Server Virtual IP: 172.20.120.50

SIP Phone A (PhoneA@172.20.120.20)

Phone A sends a REGSTER

message to the SIP Server

Client IP: 172.20.120.20

Server IP: 172.20.120.50

Port: UDP (x,5060)

REGISTER Contact: 172.20.120.20:y

SIP server

10.11.101.50

The FortiGate unit forwards the

REGSTER message to the

SIP Server

Client IP: 172.20.120.20

Server IP: 10.11.101.50

Port: UDP (x,5060)

REGISTER Contact: 172.20.120.20:y

The SIP server sends a

200 OK response to Phone A

The FortiGate unit accepts the session from the SIP server and forwards the INVITE request to Phone A

The SIP server sends an INVITE request to Phone A

 

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 f will only get through the FortiGate unit if an 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 unit is protecting the SIP server so there is no reason not to add a security policy to all 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 unit. In most cases the FortiGate unit 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 unit protecting a network with SIP phones

FortiGate unit

In NAT/Route mode

 

 

SIP proxy server

172.20.120.50

SIP Phone A (PhoneA@10.11.101.20)

 

  1. Phone A sends a REGSTER message to the SIP Proxy Server
  1. The FortiGate unit forwards the REGSTER message to the SIP Proxy Server

Client IP: 10.11.101.20

Server IP: 172.20.120.50

Port: UDP (x,5060)

REGISTER Contact: 10.11.101.20:y

  1. The FortiGate unit opens a pinhole to accept sessions from the SIP server. If strict-register is enabled the pinhole is (172.20.120.50, 172.20.120.141,y)

If strict-register is disabled the pinhole is (ANY, x,y)

  1. The SIP Proxy server sends a 200 OK response to Phone A
  1. The FortiGate unit accepts the response through the open pinhole and forwards the response to Phone A

The more specific a pinhole is the more secure it is because it will 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 unit 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


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

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

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


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

Translating SIP sessions to multiple destination ports

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

SIP Server

IP: 192.168.10.20

 

IP Phone

Virtual Server

IP Address

172.20.120.20

TCP Port 5060

 

 

To translated SIP sessions to multiple destination ports

1. Add the load balance 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_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


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

Translating SIP session destination ports

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

 

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.

 

Example translating SIP sessions to a different destination port

SIP Server

IP: 192.168.10.20

 

IP Phone

172.20.120.1

Virtual Server

IP Address

172.20.120.20

 

 

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”

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


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

Controlling NAT for addresses in SDP lines

Controlling NAT for addresses in SDP lines

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

The no-sdp-fixup option is disabled by default and the FortiGate unit performs NAT on addresses in SDP lines. Enable this option if you don’t want the FortiGate unit 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


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

Controlling how the SIP ALG NATs SIP contact header line addresses

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

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


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

NAT with IP address conservation

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 unit 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 unit would add the following i= line.

i=(o=IN IP4 10.31.101.20)


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