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
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:
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
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)
Additional SIP NAT scenarios
This section lists some additional SIP NAT scenarios.
Source NAT (SIP and RTP)
In the source NAT scenario shown below, a SIP phone connects to the Internet through a FortiGate unit 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
217.10.79.9 217.10.69.11
SIP Proxy
Server
RTP Media
Server
SIP service provider has a SIP server and a separate RTP server 217.233.122.132
10.72.0.57
FortiGate Unit
Destination NAT (SIP and RTP)
In the following destination NAT scenario, a SIP phone can connect through the FortiGate unit 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
217.10.79.9
217.10.69.11
SIP Proxy
Server
RTP Media
Server
SIP service provider has a SIP server and a separate RTP server
In the scenario, shownabove, 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 unit also supports a variation of this scenario where the RTP media server’s IP address is hidden on a private network or DMZ.
SIP destination NAT-RTP media server hidden
192.168.200.99
219.29.81.21
RTP Media
Server
10.0.0.60
217.233.90.60
SIP Proxy Server
FortiGate Unit
In the scenario shown above, a SIP phone connects to the Internet. The VoIP service provider only publishes a single public IP. The FortiGate unit is configured with a firewall VIP. The SIP phone connects to the FortiGate unit (217.233.90.60) and using the VIP the FortiGate unit 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.
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 unit and the RTP server IP has to be translated differently than the SIP serverIP.
Different source and destination NAT for SIP and RTP
RTP Servers
192.168.0.21 – 192.168.0.23
219.29.81.10
219.29.81.20
RTP Server
10.0.0.60
SIP Server
IP: 217.233.90.60
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.
SIP NAT configuration example: destination address translation (destination NAT)
This configuration example shows how to configure the FortiGate unit to support the destination address translation scenario shown in the figure below. The FortiGate unit requires two SIP security policies:
SIP destination NAT scenario part two: 200 OK returned to Phone B and media streams established
FortiGate-620B Cluster
SIP proxy server
Virtual IP: 172.20.120.50
SIP Phone A (PhoneA@10.31.101.20)
SIP proxy server
10.31.101.50
SIP Phone B (PhoneB@172.20.120.30)
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 – web-based manager
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.
VIP Type IPv4
Name SIP_Proxy_VIP
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:
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
Destination Address all
Source SIP_Proxy_Server
Schedule always
Service SIP
Action ACCEPT
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
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
So, if you guys have viewed or read my “Where Fortinet is Messing Up” page….you know that I much prefer the way Palo Alto Networks does app assignment on policies.
5.6 Beta 2 is flipping that on it’s head though as it seems to be more aligned. The ability to select the policy and the web category from the policy is going to make policy creation significantly more granular and simple / straight forward.
I am a happy boy!
SIP NAT configuration example: source address translation (source NAT)
This configuration example shows how to configure the FortiGate unit to support the source address translation scenario shownbelow. 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. 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.
SIP source NAT configuration
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 – web-based manager
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 Internal
Category Address
Name Phone_B
Type IP/Netmask
Subnet / IP Range 172.20.120.30/255.255.255.255
Interface wan1
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:
Incoming Interface internal
Outgoing Interface wan1
Source Phone_A
Destination Address Phone_B
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 security policy to allow Phone B to send SIP request messages to Phone A:
Incoming Interface wan1
Outgoing Interface internal
Source Phone_B
Destination Address Phone_A
Schedule always
Service SIP
Action ACCEPT
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 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 unit that accepts SIP sessions includes a virtual IP. Phone A sends SIP the INVITE message to the virtual IP address. The FortiGate unit 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
FortiGate-620B Cluster
In NAT/Route mode
Port2
|
72 |
|
100 |
10.11.101. 00
P t1
|
Por 172.20. |
|
. |
20 120.141
SIP Virtual IP: 172.20.120.50
SIP Phone A (PhoneA@10.31.101.20)
SIP proxy server
10.31.101.50
SIP Phone B (PhoneB@172.20.120.30)
Phone B sends an INVITE request for Phone A to the SIP Proxy Server Virtual IP (SDP 172.20.120.30:4900)
INVITE sip:PhoneA@172.20.120.50 SIP/2.0
Via: SIP/2.0/UDP 172.20.120.50:5060
From: PhoneB <sip:PhoneB@172.20.120.30> To: PhoneA <sip:PhoneA@172.20.120.50> Call-ID: 314134@172.20.120.30
CSeq: 1 INVITE
Contact: sip:PhoneB@172.20.120.30 v=0
o=PhoneB 2346 134 IN IP4 172.20.120.30 c=IN IP4 172.20.120.30
m=audio 4900 RTP 0 3
SIP ALG creates Pinhole 1. Accepts traffic on Port2 with destination address:port numbers 172.20.120.30:4900 and 4901
The SIP ALG performs destination NAT on the INVITE request and forwards it to the SIP proxy server.
The SIP proxy server forwards the INVITE request to Phone A (SDP: 172.20.120.30:4900)
INVITE sip:PhoneA@10.31.101.50 SIP/2.0
Via: SIP/2.0/UDP 10.31.101.50:5060
From: PhoneB <sip:PhoneB@172.20.120.30> To: PhoneA <sip:PhoneA@10.31.101.50>
Call-ID: 314134@172.20.120.30
CSeq: 1 INVITE
Contact: sip:PhoneB@172.20.120.30 v=0
o=PhoneB 2346 134 IN IP4 172.20.120.30 c=IN IP4 172.20.120.30
m=audio 4900 RTP 0 3
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.
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 unit 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 destination NAT scenario part 2: 200 OK returned to Phone B and media streams established
FortiGate-620B Cluster
In NAT/Route mode
Port2
SIP Virtual IP: 172.20.120.50
SIP Phone A (PhoneA@10.31.101.20)
SIP proxy server
10.31.101.50
SIP Phone B (PhoneB@172.20.120.30)
Phone A sends a 200 OK response to the SIP proxy server (SDP: 10.31.101.20:8888)
The SIP proxy server forwards the response to Phone B (SDP: 10.31.101.20:8888)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.31.101.50:5060
From: PhoneB <sip:PhoneB@172.20.120.30> To: PhoneA <sip:PhoneA@10.31.101.50>
Call-ID: 314134@172.20.120.30
CSeq: 1 INVITE
Contact: sip:PhoneB@172.20.120.30 v=0
o=PhoneB 2346 134 IN IP4 172.20.120.30 c=IN IP4 10.31.101.20
m=audio 5500 RTP 0
The SIP ALG NATs the SDP address to the Virtual IP address before forwarding the response to Phone B (SDP: 172.20.120.50:5500)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.20.120.50:5060
From: PhoneB <sip:PhoneB@172.20.120.30> To: PhoneA <sip:PhoneA@172.20.120.50> Call-ID: 314134@172.20.120.30
CSeq: 1 INVITE
Contact: sip:PhoneB@172.20.120.30 v=0
o=PhoneB 2346 134 IN IP4 172.20.120.30 c=IN IP4 172.20.120.50
m=audio 5500 RTP 0
Phone A sends RTP and RTCP media sessions to Phone B through pinhole 1. Destination address:port number 172.20.120.30:4900 and 4901
Pinhole 2 created. Accepts traffic on Port1 with destination address:port numbers 172.20.120.50:5500 and 5501
Pinhole 1
1 The SIP ALG NATs the destination address to 10.31.101.20.
Phone B sends RTP and RTCP media sessions to Phone A through pinhole 2. Destination address:port number 172.20.120.50:5500 and 5501.
Pinhole 2
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.