FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
athirat
Staff
Staff
Article Id 341516
Description
 
This article describes how to enable support for GTP-U sessions with dynamic source ports and how the GTP-U session would look like if this feature is enabled.
 

By default, FortiGate tracks sessions using a 5-tuple system: source port, destination port, source IP, destination IP, and protocol.

In networks utilizing GTP-U with dynamic source ports, Fortigate will see multiple GTP-U sessions with the same source and destination IPs but varying source ports. In this scenario, FortiOS creates a new session for each unique source port. As a result, if dynamic source ports are used with GTP-U, Fortigate may need to manage a large number of sessions, potentially impacting CPU and memory resources as the session count grows.

 

To enhance GTP-U scalability, on NP7 platforms, the 'gtpu-dynamic-source-port' option can be enabled.

This setting changes session tracking for GTP-U traffic to a 4-tuple system ignoring the source port - where all packets between the source and destination IP addresses share the same session, even if the source port changes dynamically.

 

Scope

 

NP7 FortiGate v7.6.0 onwards 

 

Solution

 

Use the following command to enable support for GTP-U with dynamic source ports:

 

config system global

    set gtpu-dynamic-source-port enable  <----- Disabled by default.

end

 

The GTP-U session will look like below when this setting is enabled :

 

info: proto=17 proto_state=00 duration=72 expire=177 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ tun_id=0.0.0.0/100.111.250.199 vlan_cos=0/255
state=log may_dirty npu f00 dym_src_port
statistic(bytes/packets/allow_err): org=39088/28/1 reply=0/0/0 tuples=2
tx speed(Bps/kbps): 541/4 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=102->74/74->102 gwy=0.0.0.0/0.0.0.0
hook=pre dir=org act=noop 100.111.250.199:0->10.28.1.13:2152(0.0.0.0:0)   -----> source port marked as 0 
hook=post dir=reply act=noop 10.28.1.13:2152->100.111.250.199:0(0.0.0.0:0)
misc=0 policy_id=100 pol_uuid_idx=16111 auth_info=0 chk_client_info=0 vd=2
serial=52a2a11e tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id=00000000 ngfwid=n/a
npu_state=0x4000400 ofld-O
npu info: flag=0x81/0x00, offload=9/0, ips_offload=0/0, epid=213/0, ipid=3968/0, vlan=0x09d5/0x0000
vlifid=3968/0, vtag_in=0x09d5/0x0000 in_npu=255/0, out_npu=255/0, fwd_en=0/0, qid=10/0 ----> 
no_ofld_reason:

 

Taking the above flow as an example, to summarize :

 

  • With gtpu-dynamic-source-port enabled, even if GTP-U packets between 100.111.250.199 -> 10.28.1.13 are seen from different source ports, it is still handled by this session and will continue to be offloaded to NP7.
  • With gtpu-dynamic-source-port disabled, a new session is set up for GTP-U packets between 100.111.250.199 -> 10.28.1.13 for every different source port. All session setups will be handled by the CPU increasing the load on the CPU.
Contributors