Technical Tip: GTPv2 inter-PLMN handover via S10 and Message Filtering

xsilver_FTNT · ‎09-15-2025

Description This article describes what FortiCarrier, as a GRX firewall, is capable of regarding the GTPv2 inter-PLMN handover via the S10 interface. And explain the options for GTPv2 S10 Message Filtering.

Scope The FortiCarrier (the FortiGate with CarrierOS license) is deployed as a GRX firewall.

Solution

What can be done with GTPv2 S10 messages in a GRX firewall:

Initial information:

Those S10 messages are covered by the 3GPP TS 29.274 standard in section 7.3, 'Mobility Management Messages' [1].

FortiCarrier v7.0.2 implemented partial S10 and Mobility Management Messages handling.
For details, see those two independent chapters of FortiCarrier documentation:

Filtering S10 interface Mobility Management tunnels: depicts S10 handling and includes a troubleshooting section.
GTPv2 message filtering: Generic GTPv2 Message Filtering, as some S10 messages do not require special care.

Note: Select the drop-down OS version menu and choose another OS version to read details on any newer FortiCarrier OS version above v7.0.2.

S10 interface support depicted in the first document includes only specific message filtering for the following GTPv2 messages on S10 interfaces:

Context Request (130).
Context Response (131).
Context Acknowledge (132).
Forward Relocation Request (133).
Forward Relocation Response (134).
Forward Relocation Complete Notification (135).
Forward Relocation Complete Acknowledge (136).

Any other GTPv2 messages described in 3GPP Technical Specification [1], possibly transmitted on S10 interfaces, are handled slightly differently. For those, see the GTPv2 message filtering document above.

Base S10 message filtering options:

To configure GTPv2 message filtering on S10 interfaces, the config gtp message-filter-v2 section includes the following option keys (the default values are 'allow'):

config gtp message-filter-v2
    edit 1
        set context-req-res-ack {allow | deny}
        set forward-relocation-req-res {allow | deny}
        set forward-relocation-cmp-notif-ack {allow | deny}
    end
end

These Context and Forward Relocation procedures have full support and a dissector implemented into the GTP-C helper.
It is therefore necessary for the GTP-C helper to be active for the GTP Control-plane traffic, which needs to be inspected.

Example of GTP-C session helper:

config system session-helper
    edit 21
        set name gtp-c
        set protocol 17
        set port 2123
    next
end

Example of related custom service using the helper above:

config firewall service custom
    edit "GTP"
        set udp-portrange 2123 2152 3386
    next
end

By default, this custom service helper configuration has 'set helper auto'.

The respective service is then used in the firewall policy for traffic inspection.

Note:

If it is necessary to block GTP-U inspection, a custom service needs to be set, like the one in the example below.

This will document the disabled helper, and such GTP-U services (or as part of a service group) can be used in the firewall policy handling the GTP User-plane traffic.

The helper will still be loaded to the kernel because of the 'config system session-helper' command, but it will not actively be used because of this service setting.

There is quite often no need to inspect the actual traffic payload, GTP-U (user-plane).

However, it could be beneficial in some scenarios, like for OT/IoT traffic towards specific APNs. And this way, a helper permanently loaded into the kernel can be enabled or disabled, as needed for specific traffic flows.

Example with the GTP-U helper disabled:

config firewall service custom
    edit "GTP_U_2152"
        set helper disable <-----
        set udp-portrange 2152
    next
end

Additional S10 messages filtering options:

In section 7.3, 'Mobility Management Messages [1]', 3GPP TS 29.274 describes various other messages which can be seen on the S10 interface and therefore can possibly be seen on a GRX firewall.

For example, a 'Relocation Cancel Request' can be seen on S10 as part of an inter-RAT handover cancel procedure.

A complete set of the GTPv2 messages known to the FortiCarrier OS is documented in this document GTPv2 Message Filtering.

Note: All message types are set to 'allow' by default, so they will be 'forwarded' and pass through the firewall, unless explicitly set otherwise via 'config gtp message-filter-v2'.

Example of a more complete 'Deny' filter for S10 messages:

By default, all GTPv2 messages in the message filter are 'allowed'. Some S10 messages can be seen on peering interfaces alongside S8 and S6a messages.

To deny S10 Mobility Management Messages on a GRX firewall, identify those S10 messages first.
To do so, use pen-tester (like Umlaut) results; consult the aforementioned 3GPP TS 29.274 section 7.3 [1]; or use packet capture output and peering procedures documentation and agreements.

GTPv2 Message Filter example:

config gtp message-filter-v2
    edit "filter_v2_no_S10"
        set unknown-message deny
        set change-notification deny
        set modify-bearer-cmd-fail deny
        set delete-bearer-cmd-fail deny
        set bearer-resource-cmd-fail deny
        set trace-session deny
        set identification-req-resp deny
        set context-req-res-ack deny
        set forward-relocation-req-res deny
        set forward-relocation-cmp-notif-ack deny
        set forward-access-notif-ack deny
        set relocation-cancel-req-resp deny
        set configuration-transfer-tunnel deny
    next
end

Note: This example focuses mainly on Forward Relocation, Trace Session, Configuration Transfer, and Relocation Cancel procedures. Therefore, it does not block a complete set of all possible S10 messages.
Use it as a functioning example and customize it according to the peering/network/(EPC)core security needs.

Additionally, except for messages in the Initial info and 'Filtering S10 interface Mobility Management tunnels' documentation, the other S10 messages are not fully covered by the GTP-C helper and dissector.
They can therefore be blocked, but logging options, anomaly detection (out-of-order detection, for example), etc., are limited for the S10 messages (such as the ones for the Relocation Cancel procedure).

This lack of granularity, logging options, etc., could be partially handled via custom IPS signatures.
More on this in another KB article [2] Technical-Tip: FortiCarrier GTP Message Filtering via IPS custom signatures.

Related documents:

[1] 3GPP TS 29.274 has been published by ETSI as 129.274 (note that the FortiCarrier is currently based on version 15.9.0 of those documents).

[2] Technical-Tip: FortiCarrier GTP Message Filtering via IPS custom signatures

Technical Tip: GTPv2 inter-PLMN handover via S10 and Message Filtering

You are leaving our website