GTP Explained: GTP-C, GTP-U, Roaming Interfaces and GTP Firewalls

GTP, the GPRS Tunnelling Protocol, is the set of UDP based protocols mobile networks use to carry a subscriber's data session between core network nodes. GTP-C (control plane, UDP port 2123) creates, changes and deletes tunnels; GTP-U (user plane, UDP port 2152) carries the subscriber's packets inside those tunnels, each one labelled with a Tunnel Endpoint Identifier (TEID). It runs in 2G and 3G packet cores, across the 4G Evolved Packet Core on S1-U, S5 and S8, and its user plane still runs on 5G's N3 and N9.

GTP was designed for a closed club of trusted operators, so the protocol itself does not authenticate or encrypt anything. The security comes from around it: IPsec under Network Domain Security (NDS/IP), filtering at the network edge, unpredictable TEIDs, and in 5G a dedicated Inter-PLMN User Plane Security (IPUPS) function on N9.

Key takeaways

• GTP is a family, not a single protocol. GTPv1 (3GPP TS 29.060) covers 2G and 3G control and user plane; GTPv2-C (TS 29.274) is the 4G control plane; GTPv1-U (TS 29.281) is the user plane for 3G, 4G and 5G alike.
• GTP-C listens on UDP 2123 and GTP-U on UDP 2152, both registered ports named in the specs. PFCP, which 4G CUPS and 5G use between control and user plane functions, uses UDP 8805 (TS 29.244).
• The receiving side of each tunnel picks the TEID; current specs require PGW S5/S8/S2a/S2b TEIDs to be "non-predictable".
• GTP has no built in authentication or encryption. 3GPP points GTP protection at NDS/IP (TS 33.210), which mandates IPsec integrity protection between security domains and recommends encryption, but explicitly does not cover GTP-U.
• Roaming carries GTP between operators over shared inter-operator backbones (GRX and IPX). ENISA's 2018 study rated interconnect signalling risk "medium to high" and found only 53% of surveyed operators monitored GTP-C traffic.
• 5G moves roaming control signalling to HTTP/2 through the SEPP, but GTP-U remains on N3 and N9, which is why TS 33.501 adds IPUPS: forward only GTP-U packets whose F-TEID belongs to an active PDU session, and drop malformed ones.
• A GTP firewall tracks tunnels created by GTP-C and checks GTP-U against them. It complements IPsec rather than replacing it.

What is GTP and where is it used?

GTP exists because a mobile subscriber moves. The device's IP address is anchored at a gateway deep in the core network, but the radio cell, and sometimes the serving node, change as the user travels. Instead of rerouting the internet to follow the phone, the network keeps the IP address fixed at the anchor and builds tunnels between nodes. When the user moves, the network moves the tunnel endpoints, not the address.

The scope clauses of TS 29.060, TS 29.274, TS 29.281 and TS 29.244 list where each part runs. TS 29.060 defines Gn, the interface between GPRS support nodes (GSNs) inside one network, and Gp, the interface between GSNs "in different PLMNs", which is the roaming case. TS 29.274 lists GTPv2-C on S2a, S2b, S3, S4, S5, S8, S10, S11, S16, Sm, Sn and N26, the 4G to 5G interworking interface. TS 29.281 lists GTP-U on interfaces from 3G Iu through 4G S1-U, S5 and S8 to 5G F1-U, N3, N9 and N19.

So one user plane format has survived from 3G to 5G, while the control plane has been rewritten twice: GTPv1-C for 2G and 3G, GTPv2-C for 4G, and then mostly replaced in 5G by HTTP/2 service based interfaces plus PFCP.

The interfaces you will hear about most

S5 and S8 also have a PMIP based variant; TS 29.274 means the GTP based ones "unless otherwise specified".

How do GTPv1 and GTPv2 differ?

GTPv0 came first, in GSM 09.60; TS 29.060 notes its header version is 0. Release 8 removed interworking with it, and TS 29.281 says a GTPv1-U entity "should not listen to the well-known GTPv0 port 3386". GTPv1 (TS 29.060) covers 2G and 3G control and user plane, though since Release 8 the user plane part is superseded by TS 29.281. GTPv2 (TS 29.274) is control plane only, introduced with the Evolved Packet System in Release 8; as the spec puts it, "GTP-U is based on GTP version 1 (GTPv1)".

The practical differences between GTPv1-C and GTPv2-C that matter to a defender:

Both versions share the registered GTP-C port, so a filter that only looks at the port cannot tell them apart. It has to read the version field in the header.

How do GTP-C and GTP-U work?

Tunnels and TEIDs

TS 29.274 describes a GTP tunnel simply: it separates traffic "into different communication flows", and in each node a tunnel "is identified in each node with a TEID, an IP address and a UDP port number". The key design decision is who picks the TEID. In both GTPv2-C and GTP-U, "the receiving end side of a GTP tunnel locally assigns the TEID value the transmitting side has to use". The TEIDs are then exchanged in control plane messages.

Each side effectively tells its peer "send me traffic for this session with TEID X at address Y", using a Fully Qualified TEID (F-TEID) information element in GTPv2-C. On the control plane, TS 29.274 makes the TEID-C unique per PDN connection on S5 and S8 and one pair per UE on S11; on the user plane, a TEID-U identifies one bearer (4G) or one PDU session tunnel (5G).

Two rules in the current specs matter for security:

1. TEIDs on the gateway's roaming facing interfaces must be unpredictable. The current versions of both TS 29.274 and TS 29.281 say the TEID "shall be assigned in a non-predictable manner for PGW S5/S8/S2a/S2b interfaces", referencing the PGW security assurance specification TS 33.250. A sequential TEID allocator is easy to write and easy to guess.
2. The all zeros TEID is special. In GTP-U, Echo Request, Echo Response, Supported Extension Headers Notification and Error Indication messages carry a TEID of all zeros, and TS 29.281 says a GTP-U entity "shall not assign the value 'all zeros' to its own TEID" when setting up a tunnel (it still accepts one from an old peer for backward compatibility). That makes TEID zero a useful filtering signal: only a few message types should ever carry it.

The GTP-U header

TS 29.281 describes the GTP-U header as variable length, with a minimum of 8 bytes. The mandatory part holds:

• a version field set to 1;
• a protocol type bit that distinguishes GTP (1) from GTP prime (0), the charging variant defined in TS 32.295;
• three flags, E, S and PN, that signal an extension header, a sequence number and an N-PDU number;
• a message type;
• a length field that counts everything after the first 8 octets;
• the 32 bit TEID.

If any flag is set, all three optional fields are present and the receiver ignores those whose flag is clear.

The GTP-U message set is small. From TS 29.281 Table 6.1-1:

Almost all traffic on a busy N3 or S1-U link is type 255: the subscriber's IP packet inside a GTP-U header, inside UDP, inside an outer IP header between two network nodes.

The GTPv2-C header

TS 29.274 Figure 5.1-1 shows the general GTPv2-C header: a version field (2), a P flag for piggybacking, a T flag that says whether a TEID follows, a message type, a two octet length, then the TEID in octets 5 to 8 "if T flag is set to 1", then a three octet sequence number and a spare octet. Echo messages are sent without a TEID; session messages carry one.

Ports and message direction

The specs set the ports per message class. GTPv2 initial messages go to UDP 2123 and responses return to the requester's source port (TS 29.274). GTPv1 control requests go to 2123 and user plane requests to 2152 (TS 29.060). Echo Requests, G-PDUs and Error Indications go to 2152, and senders "should" vary the source port of user packets to help load balancing (TS 29.281). PFCP requests go to UDP 8805 (TS 29.244).

TS 29.281 adds a note every firewall team should read: "non-GTP-aware stateful firewalls" must be configured "to allow response messages coming from a different UDP port and IP address than the triggering message". Ordinary five tuple stateful firewalls can break GTP-U error handling, which is part of why protocol aware GTP filtering exists.

A create session flow in 4G, step by step

A simplified LTE attach and default bearer setup, as a defender sees it on the wire:

TS 29.274 confirms that "the Create Session Request message shall be sent on the S11 interface by the MME to the SGW, and on the S5/S8 interface by the SGW to the PGW". When the session ends, Delete Session Request (36) and Response (37) tear it down. The message type values come from TS 29.274 Table 6.1-1.

The important point for security is the dependency: the user plane TEIDs only become valid because a control plane exchange created them. A filter that has watched the GTP-C exchange knows which TEIDs, addresses and peers belong together. A filter that has not seen it can only check ports and addresses.

Echo messages, restart counters and path management

GTP keeps paths alive with Echo Request and Echo Response; TS 29.281 says a peer "may send an Echo Request on a path to the other GTP-U peer to find out if it is alive". In GTPv2-C the response's Recovery information element carries the node's Restart Counter (TS 23.007), so a changed value tells the peer the other side lost its state and stale sessions can be cleaned up. In GTP-U the Restart Counter is set to zero and an optional Recovery Time Stamp records when the entity started. Reliability over UDP comes from a T3-RESPONSE timer and up to N3-REQUESTS retransmissions (TS 29.281 clause 11). For defenders, restart counter changes, bursts of Error Indications and peers that stop answering echoes are early health signals worth logging.

How does roaming traffic cross operators?

When you roam, two operators must share your data session. The visited network owns the radio and the serving node; the home network owns your subscription and, in many designs, the gateway that anchors your IP address. GTP runs between them.

Gp and S8

In 2G and 3G, the SGSN in the visited network talks GTPv1 to the GGSN in the home network over Gp, which TS 29.060 defines as the "interface between GPRS Support Nodes (GSNs) in different PLMNs". In 4G, the SGW in the visited network talks GTPv2-C and GTPv1-U to the PGW in the home network over S8, the inter-operator version of S5. In 5G, roaming user plane traffic crosses on N9 between the visited UPF and the home UPF.

Home routed versus local breakout

There are two broad ways to route a roamer's data:

Both models appear in the specs. TS 29.274 refers to "Home Routed PDN connections" when it describes flags the visited SGW sets toward the home PGW, and TS 33.501 notes that "in case of a single SMF being involved in the PDU session setup, e.g. non-roaming or local breakout, that single SMF takes the role of both V-SMF and H-SMF". Home routing is the reason GTP-U crosses operator boundaries at all. Each roaming relationship that uses it adds another set of peers whose GTP traffic a home network has to accept.

GRX and IPX

Operators do not usually connect to every roaming partner directly. They connect through shared private IP backbones run for the mobile industry: the GPRS Roaming Exchange (GRX), which grew up to carry GPRS roaming traffic, and the IP Packet Exchange (IPX) that followed it. ENISA's 2018 report describes the 5G SEPP as terminating signalling "received from other PLMN (through IPX)", lists GSMA guidance documents such as IR.77 ("Inter-Operator IP Backbone Security Requirements") and IR.67 (DNS and ENUM guidelines for "GRX and IPX Providers") among the controls operators reported using, and names a subscription to an "SS7 / GRX / IPX Carrier" as one way an attacker could gain interconnect access. The same report says deeper aspects of IPX security, "like IPX service provider usage and hop-by-hop routing", might be addressed in later 3GPP releases. For the signalling side of the same backbone, see the sibling posts on SS7 and Diameter and SCTP.

The trust problem follows from the design. A roaming backbone is closed to the public internet but open to its members, and GTP has no field that proves who originated a message, so a message is only as trustworthy as the least careful network that can reach you. ENISA notes that interconnect technology did not evolve with mobile services ("security was hardly a requirement") and that "the electronic communication providers are the only ones capable of adopting any kind of security measures for customer protection."

What weaknesses have been documented?

No built in authentication, integrity or confidentiality

Nothing in a GTP header proves who sent a packet or that it was not altered. The specs push protection down to the network layer: TS 29.060 clause 12 points to TS 33.210, TS 29.274 clause 9 to TS 33.401, and TS 29.281 clause 10 to TS 33.102 and TS 33.401.

NDS/IP (TS 33.210) is the common answer. It creates security domains, each run by one administrative authority, with Security Gateways (SEGs) at the edges. On the Za interface between SEGs of different domains, "authentication/integrity protection is mandatory and encryption is recommended", using IPsec ESP negotiated with IKEv2. On the Zb interface inside a domain, IPsec is optional to implement.

There is a catch that surprises many readers. NDS/IP Annex B, "Security protection for GTP", explains why GTP-C needs protection (it carries "mobility management messages, the authentication data and MM context data") and then says: "Network domain security is not intended to cover protection of user plane data and hence GTP-U is not protected by NDS/IP mechanisms." Annex B even notes that GTP-C's unique UDP port lets IPsec policy pick out control traffic and leave user traffic alone. So a network can be fully NDS/IP compliant and still send GTP-U in the clear between domains.

Spoofed or out of context control messages

A node receiving an unauthenticated GTP-C message from an allowed address has to decide whether it makes sense: does this peer own the session it refers to, and is this message type valid on this interface at all? Many message types belong only on internal interfaces such as S11, never on S8 from a roaming partner. ENISA's 2018 report lists "a data session hijacking which was achieved by performing GTP attacks" among publicly demonstrated signalling attacks. Defenders design against fraudulent session creation or modification, teardown that denies service, disclosure of subscriber identifiers, and gateway exhaustion from floods of create requests.

TEID guessing and user plane injection

The user plane decides which session a packet belongs to using only the outer addresses and the TEID. If an attacker can reach a GTP-U endpoint and guess a valid TEID, packets can be injected into a session that is not theirs. That is why the current specs require non-predictable TEIDs on the PGW's S5, S8, S2a and S2b interfaces, and why 5G's IPUPS (covered below) checks every GTP-U packet against active sessions. Sequential or easily inferred TEIDs make the problem far worse.

A related class is tunnel within tunnel traffic, where a subscriber packet itself contains GTP-U aimed at core endpoints. Gateways and firewalls should drop GTP-U arriving from the subscriber side.

Exposure and monitoring gaps

ENISA's survey found that only 28% of responding operators had implemented signalling firewalls, only 38% imposed security requirements on their carriers, and 53% monitored GTP-C traffic. Those figures come from ENISA's 2018 survey, so treat them as a snapshot of the gap that existed while 5G was being specified, not as today's numbers. ENISA's recommendation was "global and exhaustive monitoring of SS7 / Diameter / GTP", covering both capture and detection.

The 2021 ENISA report on 5G specifications adds a warning about internal interfaces: it cites research on the 5G standalone core that "highlighted several possible attack scenarios on N4 interface between user and control plane that may result in denial of service or redirection of data", and concludes that internal interfaces such as N4 must be configured "to prevent external access to them."

How does 5G change it?

5G changed the control plane completely and kept the user plane.

PFCP between SMF and UPF

4G Control and User Plane Separation (CUPS) split the SGW and PGW into control and user parts that talk PFCP (TS 29.244) over Sxa, Sxb and Sxc; 5G uses the same protocol on N4 between the SMF and the UPF, on UDP 8805. PFCP installs the rules that tell the UPF which TEIDs to accept and where to forward packets, so whoever can speak PFCP to a UPF can change how subscriber traffic flows. TS 33.501 clause 9.9 lists N4 among internal interfaces that "shall be confidentiality, integrity, and replay protected", using IPsec "unless security is provided by other means, e.g. physical security".

SEPP for control plane roaming

5G roaming signalling uses HTTP/2 between operators' Security Edge Protection Proxies (SEPPs) over N32, not GTP-C. TS 33.501 requires the receiving SEPP to check the sender is authorised for the network identity it claims and to "discard messages that are not allowed on the N32 interface". The sibling post on 5G core architecture and SEPP security covers N32 in depth.

GTP-U remains on N3 and N9

The SEPP protects signalling, not user data. Every gNB still sends user traffic to a UPF in GTP-U on N3, and home routed roaming still carries it on N9. TS 33.501 clause 9.3 says "the transport of user data over N3 shall be integrity, confidentiality and replay-protected", with IPsec "mandatory to implement on the gNB and the ng-eNB", but a note makes using it "an operator's decision". Clause 9.9 requires the same protection on N9 and other interconnect interfaces except N32, again unless security is provided by other means.

IPUPS: a standard GTP-U check at the border

TS 33.501 clause 4.2.2 introduces Inter-PLMN UP Security as "a functionality of the UPF that enforces GTP-U security on the N9 interface between UPFs of the visited and home PLMNs". Clause 5.9.3.4 sets two rules: "The IPUPS shall only forward GTP-U packets that contain an F-TEID that belongs to an active PDU session and discard all others", and it "shall discard malformed GTP-U messages". IPUPS is a session aware GTP-U filter written into the standard.

What still runs GTPv2-C in a 5G world

GTPv2-C survives on N26 for 4G interworking, on S8 for 4G roaming, and throughout non-standalone 5G. TS 33.501 clause 9.5 requires NDS/IP protection for "DIAMETER or GTP-based interfaces" such as N26.

Comparison table: GTPv1-C, GTPv2-C, GTP-U and PFCP

What do GTP firewalls and IPsec on backhaul do?

There are two complementary controls, and teams often mistake one for the other.

IPsec (NDS/IP) answers "who sent this and was it changed?"

IPsec between security gateways authenticates the peer network and protects packets in transit over untrusted backhaul and interconnect links. It does not look inside GTP: a packet over a valid tunnel from a roaming partner can still carry a message that does not belong on that interface, or target a TEID the partner does not own.

A GTP firewall answers "does this message make sense here?"

A GTP firewall, sometimes called a GTP aware security gateway, is a category of network security device that understands GTP and keeps state about tunnels. The functions that define the category are:

Placement follows the interfaces: roaming borders (Gp, S8, N9) and the edge between the radio network and the core (S1-U, N3). On internal control interfaces, segmentation and IPsec do most of the work.

Decision table: which control for which link

The private 5G angle

Some private 5G networks, campus networks and small operators run cores built from open source software on ordinary servers and containers. The protocols and the boundary problems are the same as in a national network. A typical small deployment has a few gNBs on the site network, a UPF, SMF and AMF on one server or cluster, and an N6 link to the enterprise LAN or the internet. Three boundaries need filtering:

• N3, radio to core. Only the gNBs' addresses should be able to send UDP 2152 to the UPF. On a flat site network, any laptop can otherwise reach the UPF's GTP-U port. TS 33.501 makes IPsec on N3 mandatory to implement on the gNB; whether to use it is the operator's decision, and in a private site the "operator" is the enterprise.
• N4, control to user plane. PFCP on UDP 8805 should only be reachable from the SMF. In an all in one lab install, that often means binding it to a loopback or internal bridge address, not every interface.
• N6, user plane to data network. This is the internet facing side. Nothing arriving here should ever be GTP or PFCP. A plain stateful firewall that drops UDP 2123, 2152 and 8805 inbound on N6 closes the most common accidental exposure.

ENISA's 5G report lists "protection of internet facing functions (e.g. N6 interface connecting UPF to external data network)" and "protection from DDoS flood from IoT devices over N3 interface" among the additional controls operators should consider. Both apply directly to private 5G, where IoT devices are often the main user.

There is also a software angle: an open source core's GTP and PFCP parsers, TEID allocator and dependencies are code you are responsible for updating, and a pinned old image keeps old parser bugs in the component that faces the radio network.

Step by step: audit and harden a small core's GTP boundaries

This walkthrough is for a team that runs a lab, private or small production core on Linux hosts. It is defensive: it finds what is exposed, restricts it, verifies IPsec on backhaul, and sets up logging. Adapt addresses to your network. Test changes in a maintenance window, because a wrong allow list will drop live user traffic.

Step 1: list what is listening on GTP and PFCP ports

On each core host, see which processes bind the three ports and on which addresses.

# UDP sockets on GTP-C (2123), GTP-U (2152) and PFCP (8805), with owning process
sudo ss -lunp | grep -E ':(2123|2152|8805)\b'

# For containerised cores, check published ports too
docker ps --format '{{.Names}}\t{{.Ports}}' | grep -E '2123|2152|8805'

Any line bound to 0.0.0.0 or [::] is listening on every interface, including N6 and management networks. Write down which interface each one should be on.

Step 2: restrict each port to its legitimate peers

The example below uses nftables. It allows GTP-U only from the gNB subnet, PFCP only from the SMF, GTP-C only from known 4G peers (if you run any), and logs and drops everything else.

sudo tee /etc/nftables.d/gtp-edge.nft >/dev/null <<'EOF'
table inet gtp_edge {
  set ran_peers   { type ipv4_addr; flags interval; elements = { 10.10.0.0/24 } }
  set smf_peers   { type ipv4_addr; elements = { 10.20.0.5 } }
  set gtpc_peers  { type ipv4_addr; elements = { 10.30.0.7, 10.30.0.8 } }

  chain input {
    type filter hook input priority 0; policy accept;

    udp dport 2152 ip saddr @ran_peers  accept
    udp dport 2152 log prefix "gtpu-drop " limit rate 10/second counter drop

    udp dport 8805 ip saddr @smf_peers  accept
    udp dport 8805 log prefix "pfcp-drop " limit rate 10/second counter drop

    udp dport 2123 ip saddr @gtpc_peers accept
    udp dport 2123 log prefix "gtpc-drop " limit rate 10/second counter drop
  }
}
EOF
sudo nft -f /etc/nftables.d/gtp-edge.nft
sudo nft list table inet gtp_edge

Notes on this rule set:

• It is a port and address filter, not a GTP firewall. It cannot see TEIDs or message types. It closes accidental exposure; it does not replace protocol aware filtering on roaming borders.
• Remember the TS 29.281 note: Error Indications and Echo Responses may come from a different port or address than the packet that triggered them. Allowing by source address range, not by tracked connection, avoids breaking them.
• On the N6 interface, drop UDP 2123, 2152 and 8805 in both directions on the perimeter firewall as well.

Step 3: verify IPsec on untrusted backhaul

If gNBs reach the core over a network you do not fully control, check that the IKEv2 security associations are up and that GTP-U is actually inside them.

# Kernel IPsec security associations and policies
sudo ip xfrm state
sudo ip xfrm policy

# GTP-U should not appear in clear text on the backhaul interface
# (replace eth1 with the backhaul interface; capture a few seconds only)
sudo timeout 10 tcpdump -ni eth1 -c 50 'udp port 2152'
sudo timeout 10 tcpdump -ni eth1 -c 50 'esp'

If the first capture shows packets and the second shows none, user traffic is crossing the backhaul unprotected. Check that both ends use IKEv2 with certificates and ESP with integrity, confidentiality and replay protection, as TS 33.501 clause 9.1.2 specifies, and that certificate expiry is monitored.

Step 4: log GTP-C and path anomalies

You need to know when something unusual happens. A minimal set of signals for a small core:

# Count dropped packets by rule (from the nftables counters above)
sudo nft list table inet gtp_edge | grep -E 'drop|counter'

# Kernel log entries from the drop rules
sudo journalctl -k --since "1 hour ago" | grep -E 'gtpu-drop|pfcp-drop|gtpc-drop' | tail -n 20

# A short sample of GTP-C traffic for baseline review (write to a file you protect)
sudo timeout 60 tcpdump -ni any -w /var/tmp/gtpc-sample.pcap 'udp port 2123'

Feed the core software's own logs into the same place. The events worth alerting on are restart counter changes from a peer, bursts of Error Indications, Echo Request timeouts, create request rates far above baseline, and any message type that should not appear on a given interface.

Timeline: how the GTP specifications evolved

The "Release" rows use the initial planned release shown on each spec's 3GPP portal page, not a calendar date.

Common mistakes

Exposing GTP or PFCP ports to the internet. A UPF or gateway that binds UDP 2152, 2123 or 8805 on every interface can end up reachable from N6, a management network or the internet. Bind to the intended interface and drop all three ports at the perimeter.

Assuming NDS/IP protects user data. TS 33.210 Annex B says plainly that GTP-U "is not protected by NDS/IP mechanisms". If the backhaul or interconnect is untrusted, GTP-U needs its own IPsec, as TS 33.501 requires for N3 and N9.

Reading "mandatory to implement" as "mandatory to use". IPsec on N3 is mandatory to implement on the gNB, but using it is the operator's decision. Check that it is actually on.

Trusting roaming partners by default. A closed inter-operator backbone is still shared by many networks. Filter by partner and interface, track GTP-C state, and treat messages that do not fit an existing session as suspicious.

Relying on a plain stateful firewall for GTP-U. TS 29.281 warns that Error Indications and Echo Responses can come from a different port and address. A five tuple stateful firewall may drop legitimate error handling while still passing a packet with a forged TEID. Use address based allow lists for exposure control and protocol aware filtering for session checks.

Sequential TEIDs. The specs require non-predictable TEIDs on the PGW's S5, S8, S2a and S2b interfaces. Check what your gateway or open source core actually does, and treat a predictable allocator as a defect.

No logging of GTP-C anomalies. ENISA found many operators did not monitor GTP-C in 2018. Without logs, a burst of create requests or a peer restart looks the same as a quiet day.

Pinning old core images. The parsers that face the radio network are code. Track versions and rebuild when fixes land.

FAQ

What is GTP in mobile networks?

GTP, the GPRS Tunnelling Protocol, carries a subscriber's data session between core network nodes in tunnels. GTP-C manages the tunnels and GTP-U carries the user packets. It is used in 2G, 3G and 4G cores, and GTP-U is still used on 5G's N3 and N9 interfaces.

What ports does GTP use?

GTP-C uses UDP port 2123 and GTP-U uses UDP port 2152, both registered ports named in TS 29.274, TS 29.060 and TS 29.281. The old GTPv0 used port 3386, which Release 8 and later entities should not use. PFCP, the 5G N4 protocol, uses UDP 8805.

What is the difference between GTP-C and GTP-U?

GTP-C is signalling: it creates, modifies and deletes sessions and exchanges the TEIDs and addresses each side will use. GTP-U carries the subscriber's actual IP packets inside those tunnels, plus a few path management messages such as Echo and Error Indication.

What is a TEID?

A Tunnel Endpoint Identifier is a 32 bit value in the GTP header that identifies which tunnel a packet belongs to at the receiving node. The receiving side chooses it and tells the sender through control signalling. Current 3GPP specs require TEIDs on the PGW's S5, S8, S2a and S2b interfaces to be non-predictable.

Is GTP encrypted?

No. GTP has no built in encryption or authentication. Protection comes from IPsec under Network Domain Security (TS 33.210) for control signalling, and from IPsec on interfaces such as N3 and N9 as TS 33.501 specifies for 5G. NDS/IP itself does not cover GTP-U.

Does 5G still use GTP?

Yes, for the user plane. GTP-U runs on N3 between the radio network and the UPF and on N9 between UPFs, including in roaming. The 5G control plane uses HTTP/2 service based interfaces and PFCP instead of GTP-C, although GTPv2-C remains on N26 for 4G interworking.

What is a GTP firewall?

A GTP firewall is a protocol aware, stateful filter that understands GTP messages. It validates headers, allows only the right message types per interface, tracks sessions created by GTP-C and checks GTP-U packets against them, and logs anomalies. It complements IPsec, which authenticates the sending network but does not check whether a message makes sense.

What is IPUPS in 5G?

Inter-PLMN UP Security is a UPF function defined in TS 33.501 that enforces GTP-U security on N9 between visited and home networks. It forwards only GTP-U packets whose F-TEID belongs to an active PDU session and discards malformed messages.

Where Safeguard fits

Safeguard does not inspect GTP traffic, run a signalling firewall, test radio networks or monitor a packet core. Those jobs belong to network security controls and to the core's own operations tooling. The fit is narrower and still real: the software that runs a modern core, private or public, is built from open source components and shipped as container images, and that software has to be kept current like any other.

Safeguard scans repositories, container images and SBOM files for known vulnerable components (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>), shows which projects contain a given component and version, and evaluates policies and gates so that an image carrying a known vulnerable library does not ship. Reachability analysis helps rank findings in the code paths your build actually uses. When a fixed version exists, autonomous remediation can open a fix pull request; it ships switched off. None of this checks whether your N3 is encrypted or your TEIDs are random. It covers the parsers, libraries and base images underneath the core functions, which is where a small team running an open source core carries most of its unseen risk.

A packet core is software, and the GTP and PFCP parsers that face the radio network and roaming partners are some of its most exposed code. Rebuilding a core function pulls its dependencies again, so knowing which versions you ship, and getting fixed versions in quickly, is part of keeping those boundaries safe even though no dependency update replaces IPsec or a GTP firewall.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos show the software side only; none of them touches GTP traffic.

This first demo is a real CLI session: install, open the interactive terminal, ask it to fix a vulnerable lodash version in a repository, and watch it read the finding and advisory, edit the manifest, and run the install and tests. The CLI asks before any command that changes something and pushes nothing. The same flow applies to the repository where you build your core network functions or their management tooling.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code, and then scans from the terminal. For a private 5G team, that is how you would scan the core's container images and source on a build host inside your own network.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It is a quick way to ask which of your projects ship a given component version without leaving a chat.

Click through it at your own pace, or open it full screen.

Try it on your own build: download Safeguard and read the CLI docs.

Quick check

Sources

• 3GPP TS 29.060, GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (specification page)
• 3GPP TS 29.060 archive, V19.0.0
• 3GPP TS 29.274, GTPv2-C Stage 3 (specification page)
• 3GPP TS 29.274 archive, V20.0.0
• 3GPP TS 29.281, GTPv1-U (specification page)
• 3GPP TS 29.281 archive, V19.2.0
• 3GPP TS 29.244, PFCP between control plane and user plane nodes (specification page)
• 3GPP TS 29.244 archive, V20.1.0
• 3GPP TS 33.501, Security architecture and procedures for 5G System (specification page)
• 3GPP TS 33.501 archive, V20.3.0
• 3GPP TS 33.210, Network Domain Security, IP network layer security (specification page)
• 3GPP TS 33.210 archive, V20.0.0
• ENISA, Signalling Security in Telecom SS7/Diameter/5G (28 March 2018)
• ENISA, Signalling Security in Telecom SS7/Diameter/5G (PDF)
• ENISA, Security in 5G Specifications: Controls in 3GPP (24 February 2021)
• ENISA, Security in 5G Specifications (PDF)

Last reviewed: 25 October 2026.