Analizzare i problemi di MTU e frammentazione e evitarli tramite GRE/IPsec

I problemi di MTU e frammentazione sono tra le cause principali di errori imprevisti di performance e raggiungibilità nei VPN Site‑to‑Site e nei tunnel GRE. Il termine chiave MTU- und Fragmentierungsprobleme lo spiego subito all’inizio, perché molti guasti sono direttamente correlati: MTU effettive troppo piccole dovute a header aggiuntivi (GRE, IPsec/ESP, NAT‑T) causano frammentazione o pacchetti scartati, e se gli errori ICMP sono bloccati, la Path‑MTU‑Discovery (PMTUD) fallisce. Questo articolo mostra in modo pratico le cause, sequenze di verifica con comandi chiari, contromisure concrete e una strategia di fallback sicura per l’esercizio in produzione.

MTU- und Fragmentierungsprobleme: Warum GRE und IPsec MTU‑Probleme verursachen

Una breve panoramica tecnica: MTU (Maximum Transmission Unit) è la dimensione massima di un pacchetto Layer‑3 che un link può trasportare senza frammentazione. GRE (Generic Routing Encapsulation) è un protocollo di tunneling che incapsula un pacchetto interno con un header GRE aggiuntivo; l’header GRE di base è di 4 Bytes, opzioni aggiuntive (Key, Sequence) lo estendono. IPsec/ESP (Encapsulating Security Payload) cifra e autentica i dati, generando ulteriori header (ESP Header, Initialization Vector, Padding, ICV/Authentication‑Tag). Inoltre il NAT‑Traversal (NAT‑T) aggiunge una capsula UDP (UDP‑Header 8 Bytes). Complessivamente questi overhead riducono in modo significativo l’MTU effettiva per il traffico interno.

Typische Overhead‑Komponenten

• Header IP esterno (IPv4: 20 Bytes, IPv6: 40 Bytes)
• UDP (opzionale con NAT‑T): 8 Bytes
• ESP Header + Sequence: 8 Bytes (SPI 4 + Seq 4) + IV (p.es. 16 Bytes con AES) + ICV (p.es. 12–16 Bytes) + Padding
• GRE Header di base: 4 Bytes (più eventualmente 4 Bytes Key, 4 Bytes Seq)

Poiché la dimensione esatta varia in funzione del meccanismo di cifratura (p.es. AES‑GCM vs. AES‑CBC + HMAC), il calcolo approssimativo fornisce solo un’indicazione. In pratica, con GRE su IPsec con NAT‑T possono aggiungersi facilmente 60–100 Bytes — sufficienti a costringere un payload da 1500 Byte a frammentarsi in più parti.

Perché la Path‑MTU‑Discovery (PMTUD) fallisce e quali rischi comporta

Path‑MTU‑Discovery (PMTUD) è un meccanismo in cui un host cerca di determinare la massima dimensione di pacchetto utilizzabile lungo il percorso. I router che incontrano un pacchetto troppo grande e impediscono la frammentazione (DF‑bit = Don’t Fragment) inviano un ICMP Type 3 Code 4 (Fragmentation Needed) in risposta. In pratica si riscontrano frequentemente due problemi:

• ICMP viene bloccato da firewall o filtri, perciò il messaggio Fragmentation‑Needed non raggiunge il mittente e la connessione di fatto si blocca. Questo è comune soprattutto nei tunnel IPsec, perché le risposte ICMP verso l’indirizzo interno non vengono sempre instradate correttamente.
• L’incapsulamento modifica gli indirizzi mittente/destinazione o le porte (nel caso di NAT‑T), perciò i messaggi ICMP non possono essere associati in modo utile.

Il risultato: le connessioni TCP si bloccano durante l’handshake (spesso con TLS/HTTPS), lo streaming UDP si interrompe oppure i pacchetti vengono frammentati aumentando il carico CPU e la perdita di pacchetti.

Rilevamento: welche Prüfungen gehören in die Erstdiagnose?

Proceda in modo sistematico e documenti ogni passaggio. L’obiettivo è individuare il punto in cui l’MTU effettiva diminuisce o gli errori ICMP vengono soppressi.

1) Verifica delle MTU configurate

Controlli l’MTU su tutte le interfacce coinvolte: fisiche, tunnel e interfacce virtuali.

ip link show dev eth0
ip link show dev gre1   # Beispiel für GRE-Interface
ip -4 route get 10.0.0.1   # zeigt u.a. die MTU-Informationen

2) Test PMTUD con ping

Con il flag DF (Don’t Fragment) si verifica quale dimensione può avere un pacchetto non frammentato. La dimensione corretta del payload per IPv4 è tipicamente MTU meno 28 byte (IP + header ICMP).

# Beispiel: Test auf 1472 Bytes Payload ergibt 1500 Gesamt (IPv4: 20 + ICMP: 8)
ping -M do -s 1472 
# langsam verkleinern, bis ping erfolgreich ist

Se il ping fallisce ma valori più piccoli funzionano, avete individuato la soglia. Se non riesce un ping con MTU elevata nonostante una capacità apparente del percorso, di solito manca il messaggio ICMP Fragmentation Needed.

3) Cattura della frammentazione con tcpdump

I pacchetti IPv4 frammentati possono essere rilevati con un semplice filtro BPF. In questo modo trovate pacchetti già frammentati nel traffico live:

tcpdump -n -i eth0 'ip[6:2] & 0x1fff != 0'
# Optional: nur Pakete zu/von einer bestimmten IP
tcpdump -n -i eth0 'host 10.0.0.1 and ip[6:2] & 0x1fff != 0'

Spiegazione: nell’header IPv4 i flag e l’offset di frammentazione si trovano nei byte 6–7; la maschera 0x1fff verifica un offset > 0 (non primo frammento).

4) Verificare se ritorna ICMP Fragmentation

Se PMTUD fallisce, esegua tcpdump su entrambi i lati e cerchi ICMP Type 3 Code 4:

tcpdump -n -i eth0 icmp and 'icmp[0]=3 and icmp[1]=4'
# oder allgemein nach ICMP für Fehlermeldungen
tcpdump -n -i eth0 icmp

Se non si vede alcun ICMP Fragmentation Needed, ma si verifica frammentazione, è probabile che un firewall blocchi ICMP o che i messaggi ICMP non vengano instradati correttamente di ritorno.

Contromisure concrete: cosa aiuta subito e in modo permanente?

Esistono diverse strategie collaudate per evitare problemi di MTU e frammentazione. Scegliete una combinazione adatta all’infrastruttura e documentate le modifiche.

Opzione A: Ridurre la MTU del tunnel (rapido, sicuro)

Impostate la MTU sull’interfaccia del tunnel in modo da tenere conto dell’incapsulamento aggiuntivo. È una soluzione affidabile e sicura, ma influisce sulla dimensione utile del payload.

# Esempio Linux GRE-Interface auf 1400 setzen
ip link set dev gre1 mtu 1400
# Esempio analogo per tunnel IPsec (veth/ifname)

Perché funziona: riducendo la dimensione dei frammenti di invio si evita completamente la frammentazione. Quando fallisce: se le applicazioni inviano datagram UDP molto grandi (p.es. stream video), il limite rimane percepibile.

Opzione B: MSS‑Clamping per TCP (raccomandato per Web/SSH/SMB)

MSS (Maximum Segment Size) è la quantità massima di dati TCP in un segmento. Molti stack TCP rispettano l’MSS durante l’handshake; tramite il clamping i NAT/router adeguano l’MSS nei pacchetti SYN.

# Esempio iptables per MSS-Clamping (Linux-Router/Firewall)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Perché funziona: le nuove connessioni TCP negoziano segmenti più piccoli ed evitano la frammentazione senza modificare la MTU sugli host finali. Quando fallisce: il traffico UDP non viene interessato; connessioni TCP che sovrascrivono l’MSS possono comunque causare problemi.

Opzione C: pianificare consapevolmente NAT‑T / incapsulamento UDP

Se IPsec NAT‑Traversal (UDP/4500) è utilizzato, si aggiungono 8 byte di header UDP. Considerate questi nella MTU del tunnel o evitate l’incapsulamento UDP se non è necessaria la funzione NAT.

Opzione D: aumentare la robustezza di PMTUD

Assicuratevi che tutti i firewall consentano ICMP Type 3 Code 4 (Fragmentation Needed). Se questo non è possibile, usate una combinazione di riduzione della MTU del tunnel e MSS‑Clamping.

GRE su IPsec: considerazioni specifiche

GRE è spesso usato quando, oltre a IPv4, devono essere trasportati altri protocolli (p.es. multicast, IPv6 incapsulato in IPv4) tramite la VPN. Tuttavia, in combinazione con IPsec i rischi legati alla MTU aumentano:

• GRE aggiunge un header aggiuntivo (almeno 4 byte), spesso di più con opzioni.
• IPsec in tunnel mode incapsula ulteriormente; se c’è NAT tra i punti finali, si aggiunge UDP‑NAT‑T.
• L’ICMP interno può essere influenzato da IPsec/strati esterni, il che complica PMTUD.

Raccomandazione: calcolate la somma effettiva degli overhead e riducete la MTU del tunnel in modo conservativo. Esempio di calcolo per IPv4 con NAT‑T, GRE e AES‑GCM (rappresentazione semplificata):

physische MTU: 1500
- äußeres IPv4-Header: 20
- UDP (NAT-T): 8
- ESP-Overhead (IV + ICV + ESP Header): p.es. 28
- GRE-Header: 4
= effektive MTU für innere Pakete: 1500 - 60 = 1440

Impostate la MTU del tunnel su, ad esempio, 1400 per avere un margine per padding/variazioni.

Lista di controllo pratica: procedura passo dopo passo

1. Documentate il percorso e i dispositivi coinvolti (MTU fisiche, firewall, NAT).
2. Eseguite test PMTUD con ping impostando DF e annotate le dimensioni massime dei payload.
3. Avviate tcpdump su entrambe le estremità del tunnel, cercate pacchetti frammentati e ICMP Type 3 Code 4.

Esempi concreti di risoluzione dei problemi

Sintomo: le pagine web non si caricano, SSH non si connette tramite il tunnel

Procedura:

1. Verificare il ping con DF: se non è possibile inviare pacchetti ICMP grandi, probabile problema di PMTUD.
2. Controllare tcpdump sul punto terminale del tunnel: pacchetti frammentati o ICMP mancanti?
3. Impostare MSS‑Clamping e testare; se questo risolve, il problema TCP è risolto. In caso contrario, ridurre la Tunnel‑MTU.

Sintomo: lo streaming UDP si interrompe su determinati flussi

UDP non è influenzato da MSS‑Clamping. Verificare la Tunnel‑MTU, ridurla e controllare se il problema scompare. Se lo streaming invia pacchetti molto grandi, potrebbe essere necessaria una configurazione dell’applicazione affinché utilizzi datagrammi UDP più piccoli.

Strategia di rollback e sicurezza

Le modifiche a MTU e firewall devono essere reversibili e avvenire in finestre di manutenzione chiaramente concordate. Raccomandazioni:

• Prima della modifica: backup della configurazione e un piano di test chiaro con punti di misura (latenza, perdita pacchetti, CPU).
• Eseguire la modifica in modo graduale, prima su un segmento di test o in periodo di bassa attività (off‑peak).
• Attivare il monitoraggio automatico (SNMP/Netflow/allarmi IPS) per rilevare immediatamente regressioni.
• Fallback: ripristinare le vecchie regole MTU/MSS e comunicare in modo documentato ai team interessati.

Quando ha senso modificare l’architettura?

Se riscontrate regolarmente elevati overhead dovuti a IPsec/GRE/NAT e numerosi problemi con applicazioni UDP o multicast, valutare se una riduzione dell’incapsulamento del tunnel (p. es. solo IPsec per proteggere singoli subnet invece di GRE per multicast) o l’adozione di alternative VPN native (p. es. VXLAN con IPsec, soluzioni SD‑WAN moderne) comporti a lungo termine meno oneri operativi. Tuttavia tali modifiche devono rimanere soggette a progetti con fasi di test e piani di migrazione.

Riepilogo e istruzioni operative concrete

I problemi di MTU e frammentazione sono, negli scenari VPN con GRE e IPsec, una causa ricorrente di interruzioni di connessione difficili da spiegare e di degradazioni delle prestazioni. L’ordine pragmatico da seguire in ambiente produttivo è:

1. Individuare (controlli MTU, ping con DF, tcpdump su frammenti e ICMP).
2. Misure rapide (MSS‑Clamping per TCP, riduzione temporanea della Tunnel‑MTU).
3. Configurazione permanente (MTU sul tunnel, regole firewall per ICMP, piano di Rolling‑Plan documentato).

Se si seguono sistematicamente questi passi, la maggior parte dei problemi può essere risolta senza modifiche architetturali profonde. Solo se frammentazione e blocco di ICMP si verificano regolarmente e colpiscono servizi critici, è consigliabile una riarchitettura.

Snippet pratici: comandi importanti a colpo d’occhio

Verificare MTU, impostare Tunnel‑MTU, MSS‑Clamping, filtri tcpdump:

# MTU anzeigen
ip link show dev eth0
ip link show dev gre1

# Tunnel-MTU setzen
ip link set dev gre1 mtu 1400

# MSS-Clamping (Linux Firewall/Router)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Fragmentierte Pakete finden
tcpdump -n -i eth0 'ip[6:2] & 0x1fff != 0'

# ICMP Fragmentation Needed suchen
tcpdump -n -i eth0 icmp and 'icmp[0]=3 and icmp[1]=4'

# PMTUD-Ping (IPv4)
ping -M do -s 1472 

Link di approfondimento e note per i collegamenti interni

Per un troubleshooting più approfondito si consigliano interventi su IPsec‑Troubleshooting con tcpdump/IKE‑Logs, verifica delle regole del firewall e baseline di monitoring. Pianificate collegamenti ai vostri runbook interni: analisi dei log IKE, regole ICMP del firewall, dashboard di monitoraggio per la frammentazione e avvisi su picchi di CPU.

Conclusione

I problemi di MTU e frammentazione sono evitabili se pianificate consapevolmente gli overhead dell’incapsulamento, mantenete intatti i percorsi di segnalazione PMTUD o, in alternativa, adottate MSS‑Clamping e una MTU del tunnel conservativa. Test prudenti, misurazioni riproducibili con tcpdump e ping e modifiche rollabili costituiscono le basi per un esercizio operativo stabile. GRE su IPsec fornisce funzionalità, ma richiede una pianificazione rigorosa della MTU — altrimenti si pagherà con perdita di pacchetti, latenza e maggiori oneri operativi.

Anche il tunneling GRE è rilevante per questo ambito. L’articolo inquadra questi aspetti in modo chiaro e mostra quali elementi contano nella pratica quotidiana.