SIP over IPv6

FortiGate units operating in NAT/Route and in Transparent mode support 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.

In the scenario shown inthe figure below, a SIP phone connects to the Internet through a FortiGate unit operating. The phone and the SIP and RTP servers all have IPv6 addresses.

The FortiGate unit has IPv6 security policies that accept SIP sessions. The SIP ALG understands IPv6 addresses and can forward IPv6 sessions to their destinations. Using SIP application control features the SIP ALG can also apply rate limiting and other settings to SIP sessions.

SIP support for IPv6

IPv6 address IPv6 address

SIP Server

RTP Server

IPv6 addresses

IPv6 firewall policy

IPv6 address

To enable SIP support for IPv6 add an IPv6 security policy that accepts SIP packets and includes a VoIP profile.

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!

Hosted NAT traversal

Leave a reply

Hosted NAT traversal

With the increase in the use of VoIP and other media traffic over the Internet, service provider network administrators must defend their networks from threats while allowing voice and multimedia traffic to flow transparently between users and servers and among users. A common scenario could involve providing SIP VoIP services for customers with SIP phones installed behind NAT devices that are not SIP aware. NAT devices that are not SIP aware cannot translate IP addresses in SIP headers and SDP lines in SIP packets but can and do perform source NAT on the source or addresses of the packets. In this scenario the user’s SIP phones would communicate with a SIP proxy server to set up calls between SIP phones. Once the calls are set up RTP packets would be communicated directly between the phones through each user’s NAT device.

The problem with this configuration is that the SIP headers and SDP lines in the SIP packets sent from the phones and received by the SIP proxy server would contain the private network addresses of the VoIP phones that would not be routable on the service provider network or on the Internet. One solution could be to for each customer to install and configure SIP aware NAT devices. If this is not possible, another solution requires implement hosted NAT traversal.

In a hosted NAT traversal (HNT) configuration, a FortiGate unit is installed between the NAT device and the SIP proxy server and configured with a VoIP profile that enables SIP hosted NAT traversal. Security policies that include the VoIP profile also support destination NAT using a firewall virtual IP. When the SIP phones connect to the SIP server IP address the security policy accepts the SIP packets, the virtual IP translates the destination addresses of the packets to the SIP server IP address, and the SIP ALG NAT traversal configuration translates the source IP addresses on the SIP headers and SDP lines to the source address of the SIP packets (which would be the external IP address of the NAT devices). The SIP server then sees the SIP phone IP address as the external IP address of the NAT device. As a result SIP and RTP media sessions are established using the external IP addresses of the NAT devices instead of the actual IP addresses of the SIP phones.

FortiGate SIP Hosted NAT Traversal configuration

VoIP Session Controller

(SIP server)

(For example FortiGate Voice unit)

FortiGate unit with SIP ALG

SIP

172.20.120.141

NAT device

(not SIP aware)

Configured for Host d

NAT Traversal

0.21.101. SIP Server VIP

10.21.101.10

SIP + RTP

172.20.12

SIP Phone C (PhoneC@192.168.30.1)

SIP + RTP

Service Provider Network

SIP + RTP

10.11.101.10 10.11.101.20

NAT devic

(not SIP aware)

RTP Media session

NAT device

(not SIP aware)

SIP Phone A (PhoneA@192.168.10.1)

SIP Phone B (PhoneB@192.168.20.1)

Configuration example: Hosted NAT traversal for calls between SIP Phone A and SIP Phone B

The following address translation takes place to allow a SIP call from SIP Phone A to SIP Phone B in the above diagram.

1. SIP Phone A sends a SIP Invite message to the SIP server. Packet source IP address: 192.168.10.1, destination

IP address: 10.21.101.10.

2. The SIP packets are received by the NAT device which translates the source address of the SIP packets from

192.168.10.1 to 10.11.101.20.

3. The SIP packets are received by the FortiGate unit which translates the packet destination IP address to 10.30.120.20. The SIP ALG also translates the IP address of the SIP phone in the SIP header and SDP lines from 192.168.10.1 to 10.11.101.20.

4. The SIP server accepts the Invite message and forwards it to SIP Phone B at IP address10.11.101.20. The SIP server has this address for SIP Phone B because SIP packets from SIP Phone B have also been translated using the hosted NAT traversal configuration of the SIP ALG.

5. When the SIP call is established, the RTP session is between 10.11.101.10 and 10.11.101.20 and does not pass through the FortiGate unit. The NAT devices translated the destination address of the RTP packets to the private IP addresses of the SIP phones.

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 a VoIP profile that enables hosted NAT translation.

2. Add a SIP proxy server firewall virtual IP.

3. Add a firewall address for the SIP proxy server on the private network.

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

5. Add a security policy that accepts SIP sessions initiated by the SIP proxy server and destined for the Internet.

Configuration steps – web-based manager

To add the SIP proxy server firewall virtual IP

1. Go to Policy & Objects > Virtual IPs.

2. Add the SIP proxy server virtual IP.

Name SIP_Proxy_VIP

External Interface port1

Type Static NAT

External IP Address/Range 172.20.120.50

Mapped IP Address/Range 10.31.101.50

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:

Category Address

Name SIP_Proxy_Server

Type Subnet

Subnet / IP Range 10.31.101.50/255.255.255.255

Interface port2

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.

Incoming Interface port1

Outgoing Interface port2

Source all

Destination Address SIP_Proxy_VIP

Schedule always

Service SIP

Action ACCEPT

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:

Incoming Interface port2

Outgoing Interface port1

Source SIP_Proxy_Server

Destination Address all

Schedule always

Service SIP

Action ACCEPT

7. Tuen 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 a VoIP profile that enables hosted NAT translation

1. Enter the following command to add a VoIP profile named HNT that enables hosted NAT traversal. This command shows how to clone the default VoIP profile and enable hosted NAT traversal.

config voip profile

clone default to HNT

edit HNT

config sip

set hosted-nat-traversal enable end

end

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 10.21.101.10

set mappedip 10.30.120.20 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.30.120.20 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 A 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 profile-protocol-options default set voip-profile HNT

end

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:

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 profile-protocol-options default set voip-profile default

end

Hosted NAT traversal for calls between SIP Phone A and SIP Phone C

The following address translation takes place to allow a SIP call from SIP Phone A to SIP Phone C in the previous diagram.

1. SIP Phone A sends a SIP Invite message to the SIP server. Packet source IP address: 192.168.10.1 and destination IP address: 10.21.101.10.

2. The SIP packets are received by the NAT device which translates the source address of the SIP packets from 192.168.10.1 to 10.11.101.20.

4. The SIP server accepts the Invite message and forwards it to SIP Phone C at IP address 172.20.120.30. The SIP server has this address for SIP Phone C because SIP packets from SIP Phone C have also been translated using the hosted NAT traversal configuration of the SIP ALG.

5. When the SIP call is established, the RTP session is between 10.11.101.10 and 172.20.120.30. The packets pass through the FortiGate unit which performs NAT as required.

Restricting the RTP source IP

Use the following command in a VoIP profile to restrict the RTP source IP to be the same as the SIP source IP when hosted NAT traversal is enabled.

config voip profile edit VoIP_HNT

config sip

set hosted-nat-traversal enable set hnt-restrict-source-ip enable

end end

FortiGate Upgrade Paths

7 Replies

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

Enhancing SIP pinhole security

Leave a reply

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)

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)

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)

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)

Phone A sends a REGSTER message to the SIP Proxy Server

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)

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)

The SIP Proxy server sends a 200 OK response to Phone A

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

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

Leave a reply

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

Translating SIP sessions to multiple destination ports

Leave a reply

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

Translating SIP session destination ports

Leave a reply

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

Controlling NAT for addresses in SDP lines

Leave a reply

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