MTU, MSS clamping e PPPoE: perche' alcuni siti non si aprono

C'e' una categoria di problemi di rete che sfugge alla diagnosi classica: il ping funziona, lo speed test e' perfetto, ma alcuni siti restano in caricamento all'infinito, certe VPN crollano e gli upload si bloccano a meta'. Nove volte su dieci la causa e' un MTU mal configurato su una connessione PPPoE. Vediamo perche' succede e come si risolve.

Cos'e' l'MTU

L'MTU (Maximum Transmission Unit) e' la dimensione massima, in byte, di un pacchetto che puo' viaggiare su un collegamento senza essere frammentato. Su Ethernet lo standard e' 1500 byte. Tutto l'header TCP/IP sta dentro quel limite e per anni nessuno ci ha pensato.

Il problema nasce quando in mezzo c'e' PPPoE.

Perche' PPPoE rompe l'MTU

Molte connessioni FTTH e quasi tutte le FTTC/VDSL usano PPPoE per autenticare il cliente verso l'ISP. PPPoE incapsula i pacchetti Ethernet aggiungendo il proprio header:

• 6 byte di header PPPoE
• 2 byte per il campo PPP protocol

In totale 8 byte di overhead. Risultato: su un collegamento PPPoE l'MTU utile scende da 1500 a 1492 byte. Se il router continua a inviare pacchetti da 1500, questi non passano interi.

Cosa succede con un MTU sbagliato

In teoria esiste la Path MTU Discovery (PMTUD): l'host invia un pacchetto grande con il flag "Don't Fragment", un apparato lungo il percorso risponde con un messaggio ICMP "Fragmentation Needed" e l'host riduce la dimensione. In pratica questo meccanismo si rompe spesso, perche':

• molti firewall bloccano l'ICMP in modo indiscriminato
• l'ICMP "needed" non arriva mai all'host
• l'host continua a inviare pacchetti troppo grandi che vengono silenziosamente scartati

E' il famoso PMTUD black hole. I sintomi sono inconfondibili:

• la connessione TCP si apre (handshake = pacchetti piccoli)
• le prime richieste piccole funzionano
• appena arriva un trasferimento di dati corposo (una pagina pesante, un file, il payload di una VPN) tutto si blocca

Per questo il sito "a meta'" e' il segnale tipico: gli header passano, i dati no.

La soluzione robusta: MSS clamping

Si potrebbe semplicemente abbassare l'MTU dei client, ma e' impraticabile su decine di dispositivi. La soluzione corretta si applica sul router ed e' il TCP MSS clamping.

L'MSS (Maximum Segment Size) e' la dimensione massima del payload TCP, negoziata durante l'handshake. Il clamping fa intervenire il router che, vedendo passare i pacchetti SYN, riscrive il valore di MSS verso il basso forzando entrambi gli estremi a usare segmenti che ci stanno nell'MTU reale.

Il calcolo: MTU 1492 - 20 byte IP - 20 byte TCP = MSS 1452.

La forza del clamping e' che corregge il problema senza dipendere dall'ICMP e senza toccare i client: e' il router a imporre la dimensione giusta a tutti.

Configurazione su MikroTik

Su RouterOS, con interfaccia PPPoE-client, si imposta una regola di mangle:

/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn \
    action=change-mss new-mss=clamp-to-pmtu \
    out-interface=pppoe-out1

L'opzione clamp-to-pmtu lascia che sia il router a calcolare il valore in base all'MTU dell'interfaccia, evitando numeri scritti a mano. In alternativa si puo' forzare new-mss=1452. Va applicata su entrambe le direzioni del traffico verso l'interfaccia PPPoE.

Verificare anche che l'MTU dell'interfaccia pppoe-out sia coerente (1480 o 1492 a seconda della negoziazione LCP con l'ISP).

Come diagnosticarlo

Test rapido da qualunque PC, con ping a dimensione fissa e flag Don't Fragment:

# Linux/macOS - payload 1464 = 1492 totali
ping -M do -s 1464 8.8.8.8

# Windows
ping -f -l 1464 8.8.8.8

• Se passa: l'MTU regge fino a quel valore.
• Se risponde "Packet needs to be fragmented": il payload e' troppo grande, si scende a step di 10 byte finche' non passa. Il primo valore che passa + 28 (header) e' l'MTU reale del percorso.

Questo permette di capire se il problema e' a 1500, 1492 o piu' in basso (alcuni tunnel o VLAN aggiungono ulteriore overhead).

Quando l'MTU scende ancora di piu'

PPPoE non e' l'unico caso. Ogni livello di incapsulamento toglie byte:

• VPN (WireGuard ~60 byte, OpenVPN di piu', IPsec variabile)
• tunnel GRE/L2TP
• VLAN QinQ (doppio tag)

Quando si sommano piu' incapsulamenti, l'MTU utile puo' scendere ben sotto i 1400. In questi scenari il clamping va calcolato sull'MTU effettivo del tunnel piu' interno, non su quello fisico.

In sintesi

Un MTU sbagliato non causa una rete che non funziona, ma una rete che funziona "quasi": ed e' molto piu' difficile da diagnosticare. La regola operativa e' una sola: ovunque ci sia PPPoE o un tunnel, attivare il TCP MSS clamping sul router di bordo. E' una riga di configurazione che elimina una intera classe di problemi intermittenti.