Chapter 6 – FortiOS Carrier

Chapter 6 – FortiOS Carrier

This FortiOS Handbook chapter contains the following sections:

  • Overview of FortiOS Carrier features provides an overview of the three major topics for FortiOS Carrier — Dynamic Profiles, MMS, and GTP.
  • Carrier web-based manager settings describes the web-based manager interface of FortiOS Carrier specific features.
  • MMS Security features describes FortiOS security features as they apply to MMS including MMS virus scanning, MMS file filtering, MMS content-based Antispam protection, and MMS DLP archiving.
  • Message flood protection describes setting thresholds to protect your MMS servers from receiving too many messages from the same sender.
  • Duplicate message protection describes setting thresholds to protect your MMS servers from receiving the same message from more than one sender.
  • Configuring GTP on FortiOS Carrier explains configuration of the more basic FortiOS Carrier GTP features. GTP message type filtering explains this feature, and how to configure it on FortiOS Carrier.
  • GTP identity filtering explains this feature, and how to configure it on FortiOS Carrier. Troubleshooting provides answer to common FortiOS Carrier GTP issues.


Overview of FortiOS Carrier features

FortiOS Carrier specific features include Multimedia messaging service (MMS) protection, and GPRS Tunneling Protocol (GTP) protection.

All FortiGate units, carrier-enabled or not, are capable of handling Stream Control Transmission Protocol (SCTP) traffic, which is a protocol designed for and primarily used in Carrier networks. This section includes:

  • Overview
  • Registering FortiOS Carrier
  • MMS background
  • How FortiOS Carrier processes MMS messages
  • MMS protection profiles
  • Bypassing MMS protection profile filtering based on carrier endpoints
  • Applying MMS protection profiles to MMS traffic
  • GTP basic concepts
  • GPRS network common interfaces Packet flow through the GPRS network SCTP




FortiOS Carrier provides all the features found on FortiGate units plus added features specific to carrier networks: MMS and GTP.



MMS is a standard for sending messages that include multimedia content between mobile phones. MMS is also popular as a method of delivering news and entertainment content including videos, pictures, and text. Carrier networks include four different MMS types of messages — MM1, MM3, MM4, and MM7. See “MMS background”.



The GPRS Tunneling Protocol (GTP) runs on GPRS carrier networks. GPRS is a GSM packet radio standard. It provides more efficient usage of the radio interface so that mobile devices can share the same radio channel. FortiOS supports GTPv1 and GTPv2.

GPRS provides direct connections to the Internet (TCP/IP) and X.25 networks for point-to-point services (connection-less/connection oriented) and point-to-multipoint services (broadcast).

GPRS currently supports data rates from 9.6 kbps to more than 100 kbps, and it is best suited for burst forms of traffic. GPRS involves both radio and wired components. The mobile phone sends the message to a base station unit (radio based) that converts the message from radio to wired, and sends the message to the carrier network and eventually the Internet (wired carrier network). See GTP basic concepts.


Registering FortiOS Carrier

A license is purchased from Fortinet, and is delivered by mail as a scratch card. The contained registration code is entered into the CLI according to the instructions on the card. The FortiGate unit will then factory reset itself into Carrier mode.

Only certain FortiGate models support Carrier mode. Contact Fortinet Support for more information and firmware images.


MMS background

MMS is a common method for mobile users to send and receive multimedia content. A Carrier network supports MMS across its network. This makes up the MMS Service Provider Network (MSPN).

Messages can be sent or received between the MMSC and a number of other services including the Internet, content providers, or other carriers. Each of these different service connections uses different MMS formats including MM1 and MM7 messages (essentially HTTP format), and MM3 and MM4 messages (SMTP formatted). These different formats reflect the different purposes and content for each type of MMS message.



MMS content interfaces

MMS messages are sent from devices and servers to other devices and servers using MMS content interfaces

There are eight interfaces defined for the MMS standard, referred to as MM1 through MM8. The most important of these interfaces for the transfer of data is the MM1 interface, as this defines how mobile users communicate from the mobile network to the Multimedia Message Service Center (MMSC). MMS content to be monitored and controlled comes from these mobile users and is going to the provider network.

Other MMS content interfaces that connect a service provider network to other external sources can pose threats as well. MM3 handles communication between the Internet and the MMSC and is a possible source of viruses and other content problems from the Internet. MM4 handles communication between different content provider MMSCs. Filtering MM4 content protects the service provider network from content sent from foriegn service providers and their subscribers. Finally MM7 is used for communication between content providers and the MMSC. Filtering MM3 content can also keep harmful content off of the service provider network.


MMS content interfaces


Type Transaction Similar to

MM 1


Handset to MMSC




MM 3


Between MMSC and Internet




MM 4


Between Operator MMSCs




MM 7


Content Providers to MMSC




How MMS content interfaces are applied

As shownbelow, the sender’s mobile device encodes the MMS content in a form similar to MIME email message (MMS MIME content formats are defined by the MMS Message Encapsulation specification). The encoded message is then forwarded to the service provider’s MMSC. Communication between the sending device and the MMSC uses the MM1 content interface. The MM1 content interface establishes a connection and sends an MM1 send request (m-send.req) message that contains the MMS message. The MMSC processes this request and sends back an MM1 send confirmation (m-send.conf) HTTP response indicating the status of the message — accepted or an error occurred, for example.


MM1 transactions between senders and receivers and the MMSC


(sends MMS message

to receiver)


Receiver (receives MMS message from sender)

1. m-send.req (contains the MMS message and is directed to the URI of the MMSC)

3. m-send.conf (confirms message receipt and handles any error conditions, also includes transaction identity)

2. m-notification.req (indicates mesage is available for delivery, includes size, expiry and URI)

4. m-notifyresp.ind (WSP/HTTP POST to confirm receipt of notification)


(Requests the MM.content)

6. m-retrieve.conf (the MMS content)

8. m-delivery.ind (optional, confirms delivery of MMS content)

7. m-acknowledge.ind (if requested, optional acknowledgment of receipt of MMS content)


If the recipient is on another carrier, the MMSC forwards the message to the recipient’s carrier. This forwarding uses the MM4 content interface for forwarding content between operator MMSCs (see the figure below).

Before the MMSC can forward the message to the final recipient, it must first determine if the receiver’s handset can receive MMS messages using the MM1 content interface. If the recipient can use the MM1 content interface, the content is extracted and sent to a temporary storage server with an HTTP front-end.

To retrieve the message, the receiver’s handset establishes a connection with the MMSC. An HTTP get request is then sent from the recipient to the MMSC. This message contains the URL where the content of the message is stored. The MMSC responds with a retrieve confirmation (m-retrieve.conf) HTTP response that contains the message.


MM4 messages sent between operator MMSCs

Sending Operator


Receiving Operator


1. MM4-forward.req (contains the MMS content and is directed to the receiving MMSC. X-MMS headers contain MMS extensions)

2. MM4-forward.res (administrative message to confirm transaction with status code)

3. MM4-delivery-report.req (feedback required by UA pr VASP)

4. MM4-delivery_report.res (response to feedback request with status codes)


This causes the receiver’s handset to retrieve the content from the embedded URL. Several messages are exchanged to indicate status of the delivery attempt. Before delivering content, some MMSCs also include a content adaptation service that attempts to modify the multimedia content into a format suitable for the recipient’s handset.

If the receiver’s handset is not MM1 capable, the message can be delivered to a web based service and the receiver can view the content from a normal Internet browser. The URL for the content can be sent to the receiver in an SMS text message. Using this method, non-MM1 capable recipients can still receive MMS content.

The method for determining whether a handset is MMS capable is not specified by the standards. A database is usually maintained by the operator, and in it each mobile phone number is marked as being associated with a legacy handset or not. It can be a bit hit and miss since customers can change their handset at will and this database is not usually updated dynamically.

Email and web-based gateways from MMSC to the Internet use the MM3 content interface. On the receiving side, the content servers can typically receive service requests both from WAP and normal HTTP browsers, so delivery via the web is simple. For sending from external sources to handsets, most carriers allow MIME encoded message to be sent to the receiver’s phone number with a special domain.

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!

This entry was posted in FortiOS 5.4 Handbook and tagged , , on by .

About Mike

Michael Pruett, CISSP has a wide range of cyber-security and network engineering expertise. The plethora of vendors that resell hardware but have zero engineering knowledge resulting in the wrong hardware or configuration being deployed is a major pet peeve of Michael's. This site was started in an effort to spread information while providing the option of quality consulting services at a much lower price than Fortinet Professional Services. Owns PacketLlama.Com (Fortinet Hardware Sales) and Office Of The CISO, LLC (Cybersecurity consulting firm).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.