GTP-U Tunnel Inspection on Next-Generation Firewalls - 夜莺博客

GTP-U Tunnel Inspection on Next-Generation Firewalls

Mobile backhaul is the one place where a firewall can be bypassed without anyone noticing: if the policy engine treats GPRS Tunnelling Protocol as an opaque UDP flow on port 2152, every subscriber packet inside the tunnel travels unexamined between the radio access network and the packet core. GTP-aware inspection fixes that by teaching the firewall the tunnel control plane, so it can enforce per-subscriber policy and reject malformed tunnel traffic. This guide covers the interface model (S1-U/N3 vs S11/S5), what a stateful GTP profile actually checks, the configuration sequence on a modern firewall, and the capacity numbers you must size for before enabling it.

Why Plain UDP Filtering Is Not Enough

From the perspective of a conventional stateful firewall, GTP-U is a single long-lived UDP flow per bearer between an eNodeB/gNodeB and the S-GW/UPF. There is no TCP handshake to validate, no sequence state to track, and — critically — the payload inside the tunnel is invisible. Two problems follow:

  • Security blind spot. Malformed, spoofed or overlapping tunnel endpoint identifiers (TEID) pass straight through. Attacks inside GTP (GTP-in-GTP, TEID enumeration, signalling storms) are invisible.
  • Policy blind spot. Without GTP awareness you cannot write rules that reference subscriber IP addresses, because those addresses only exist inside the tunnel.

Interface Roles You Must Define First

Interface Protocol Direction What the firewall learns
S1-U / N3 GTP-U (UDP 2152) Access side Tunnel + bearer endpoints to enforce on
S11 GTP-C (UDP 2123) Control plane Session creation/modification, TEID binding
S5/S8 GTP-C + GTP-U Core / roaming Home-routed roaming tunnels, GRX/IPX policy
Gi / N6 Plain IP Egress Post-decap subscriber traffic for URL/IPS policy

The rule of thumb: GTP-U and GTP-C terminate on different interface pairs. Binding both to the same zone makes the firewall unable to correlate control-plane signalling with user-plane bearers, which is what enables per-session policy.

Configuration Sequence

1. Enable GTP inspection and set global limits

# Interface-level: enable GTP processing on the mobile-facing interfaces
set network interface ethernet1/1 layer3 gtp gtp-inspection enable
set network interface ethernet1/2 layer3 gtp gtp-inspection enable

# Global tunnel capacity and log-only vs block behaviour
set network gtp gtp-inspection-limit 200000
set network gtp gtp-inspection-rate-limit 50000
set network gtp log-allowed-gtp-inspection-tunnel yes

2. Build a Mobile Network Protection profile

set network gtp gtp-security-profile <name>
   # user plane checks
   set user-plane anti-spoof yes
   # signalling checks on GTP-C
   set control-plane sequence-check yes
   set control-plane teid-check yes
   # stateful session limits
   set control-plane max-message-rate 20000

A stateful GTP profile typically performs: packet sanity checks (header length, version/E-flag/PN consistency, message type), stateful sequence checking with configurable window, end-user address validation (the source IP inside the tunnel must belong to the subscription), and TEID validation against the control-plane learned table.

3. Attach the profile to a security policy rule

set rulebase security rules MOBILE-UPLINK from ZONE-s1u to ZONE-core
set rulebase security rules MOBILE-UPLINK source any
set rulebase security rules MOBILE-UPLINK application gtp-u
set rulebase security rules MOBILE-UPLINK action allow
set rulebase security rules MOBILE-UPLINK profile group MOBILE-SEC

Keep the first rollout in log/monitor mode for at least a full busy hour. Anti-spoof checks in particular can produce false positives on multi-IMSI roaming partners until the end-user address ranges are correctly learned.

Capacity: The Numbers That Decide Success

GTP inspection is state heavy. Every bearer is a session, and the tunnel count is not the session count. Sizing inputs to collect in advance:

  • Peak bearer count per interface pair (ask the core team, not the interface graphs).
  • Bearer setup rate at busy hour (attempted sessions/second) — the control-plane rate limit must exceed this with headroom.
  • Average packet size; a 100 Gbit/s user plane of small packets is millions of packets per second and will exhaust session-table lookup budgets long before bandwidth.
  • Log volume: enabling log-allowed-gtp-inspection-tunnel on a large core can generate more log events than the management plane can absorb.

Failure Modes and Troubleshooting

  • Tunnel down, no logs. The control plane is not traversing the firewall, so the user-plane table never learns the bearer. Verify S11 GTP-C reaches the same inspection engine.
  • All tunnels failing suddenly. Usually a sequence-check window that is too tight after a vendor changed signalling behaviour — widen the window or set the profile to detect-only and re-baseline.
  • One subscriber class failing. Anti-spoof rejecting the tunnel because the inner source address is an IPv6 SLAAC address or a private range used by a specific roaming partner; add an exception rather than disabling the check.
  • Session table exhaustion. Raise gtp-inspection-limit only after confirming platform hardware capacity, otherwise you trade drops for memory pressure.

For adjacent topics see our posts on CGNAT design, 5G/LTE branch failover and Suricata IPS deployment.

原文链接:https://docs.paloaltonetworks.com/service-providers/11-0/mobile-network-infrastructure-getting-started/gtp/gtp-configure-stateful-inspection