problema tunnel GRE + IPSEC + tunnel GRE e PMTU (probabile causa)
Lemon
sto avendo il seguente problema su una VPN site to site: facendo
controlli con icmp il tunnel non perde un pacchetto ma sembra che, a
momenti alterni, le connessioni TCP vadano in timeout (questo sempre
senza che rilevi alcun errore sulle varie interfacce coinvolte nella VPN
né senza rilevare alcuna perdita di pacchetti). Ho provato anche facendo
ping con paccheti > 1500 bytes ma il risultato è lo stesso (perdita
pacchetti un po' più alta ma sotto lo 0,1 per mille...)
Sopra al tunnel ipsec tra i due pix c'è un tunnel GRE (non criptato) tra
due Cisco 2600, ovvero
Codice:
Cisco 2600 ----- PIX515 ==== IPSEC ===== PIX515 ------- Cisco 2600
| |
------------------ Tunnel GRE -------------------
Tunnel 0 10.254.1.1 Tunnel0 10.254.1.2
In realtà (tralasciato per diffocoltà di rappresentazione) tra i due pix
ci sono altri due Cisco 2600 che incapsulano il traffico in un ulteriore
tunnel GRE.
Sulle due interfacce tunnel "esterne" è attivo un processo EIGRP che
sembra funzionare perfettamente (la soluzione sembra aver funzionato
bene per mesi).
Lo so è complicato (perlomeno l'ultimo tunnel GRE si potrebbe
risparmiare) ma fa funzionato per mesi senza problemi. Poi ultimamente
questi problemi di timout nelle connessioni TCP.
Uno dei primi indiziati è stato il PMTU Discovery e i segmenti TCP /
pacchetti IP che cercano di scoprire l'MTU massimo mandando pacchetti
con il DF settato e aspettando l'ICMP unreacheble and DF set di ritorno
nel caso la dimensione non vada bene.
Solo che: mi sembra che icmp passi tra tutte le interfacce tra cui
questo dovrebbe avvenire:
1) le interfacce dei pix raggiungono con icmp i rispettivi endpoint dei
tunnel
2) tutta la rete raggiunge gli IP delle interfacce tunnel
3) tutta la rete raggiunge gli IP dei router coinvolti
4) i router esterni (quelli non raffigurati) raggiungono tramite icmp le
interfacce del pix
(non mi sembra ci sia altro no?)
Ho provato a far scendere l'mtu delle due interfacce tunnel esterne (e
anche le ethernet...) fino a 1200 bytes per tagliare la testa al toro e
tenere conto oltre che dell'incapsulamento GRE anche dell'incapsulamento
IPSEC del pix (ESP ecc.) e dell'ulteriore incapsulamento GRE ma il
problema non cambia.
Facendo del debug ogni tanto vedo degli apparati che tentano comunque di
mandare del pacchetti di 1500, a volte ricevono dei messaggi ICMP che
chiedono la frammentazione, a volte no, comunque mi sembra che non
frammentino mai...
qualche suggerimento?
Martin Claudio
> Uno dei primi indiziati è stato il PMTU Discovery e i segmenti TCP /
> pacchetti IP che cercano di scoprire l'MTU massimo mandando pacchetti
> con il DF settato e aspettando l'ICMP unreacheble and DF set di ritorno
> nel caso la dimensione non vada bene.
credo sia questo, ho avuto un problema analogo
>
> Solo che: mi sembra che icmp passi tra tutte le interfacce tra cui
> questo dovrebbe avvenire:
> 1) le interfacce dei pix raggiungono con icmp i rispettivi endpoint dei
> tunnel
hai provato con dei ping estesi per vedere se con 1500 byte di ping
passi attraverso i tunnel con il DF ??
>
> Ho provato a far scendere l'mtu delle due interfacce tunnel esterne (e
> anche le ethernet...) fino a 1200 bytes per tagliare la testa al toro e
> tenere conto oltre che dell'incapsulamento GRE anche dell'incapsulamento
> IPSEC del pix (ESP ecc.) e dell'ulteriore incapsulamento GRE ma il
> problema non cambia.
in realta non dovresti diminuire l'mtu ma aumentarlo...
in pratica mettiano che una interfaccia ethernet genera un pacchetto ip
di dimensione 1500 byte, questo arriva al tunnel ipsec che aggiungendo
le informazioni per il criptaggio ne crea uno di 1560, ovviamente se il
pacchetto iniziale ha il DF... a questo punto non riesce ad inviarlo in
quanto l'MTU dell'interfaccia e settato a 1500...
hai tre possibilità:
- aumenti l'MTU dell'interfaccia su cui hai l'ipsec
- utilizzi il comando crypto ipsec df-bit clear...
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087ae1.html
- utilizzi il comando "ip tcp adjust mss" sulle ethernet che ricevono i
pacchetti in ingresso
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml
personalmente preferisco la seconda possiblità, funziona benone...
>
> Facendo del debug ogni tanto vedo degli apparati che tentano comunque di
> mandare del pacchetti di 1500, a volte ricevono dei messaggi ICMP che
> chiedono la frammentazione, a volte no, comunque mi sembra che non
> frammentino mai...
>
> qualche suggerimento?
vedi sopra,
spero di essere stato di aiuto...
ciao
Lemon
>
> in realta non dovresti diminuire l'mtu ma aumentarlo...
> in pratica mettiano che una interfaccia ethernet genera un pacchetto ip
> di dimensione 1500 byte, questo arriva al tunnel ipsec che aggiungendo
> le informazioni per il criptaggio ne crea uno di 1560, ovviamente se il
> pacchetto iniziale ha il DF... a questo punto non riesce ad inviarlo in
> quanto l'MTU dell'interfaccia e settato a 1500...
si e no, nel senso che ovviamente dato l'incremento del payload dovuto
ai vari incapsulamenti sarebbe meglio avere una MTU più grande, ma se
non è possibile è meglio specificare fin dall'inizio una MTU che sommata
agli header aggiuntivi degli incapsulamenti dia l'MTU reale che si può
utilizzare nel link a MTU più bassa.
> hai tre possibilità:
> - aumenti l'MTU dell'interfaccia su cui hai l'ipsec
> - utilizzi il comando crypto ipsec df-bit clear...
>
si conoscevo tutte queste opzioni ma non mi era possibile utilzzare
perché il router in questione era un 2500 con IOS 12.0 (tutte queste
opzioni sono disponibili a partire da varie sottoversioni della 12.2).
Invece sentite qual'era il problema che secondo me è un caso molto
interessante.
Sulla rete dietro ai tunnel c'erano 3 macchine infette da vari virus che
effettuavano dei net/port scan su reti remote, in maniera continua e
veloce. Non avendo quella rete accesso a Internet i pacchetti venivano
bloccati sul router del primo tunnel che gli mandava un ICMP Network
Unreachable. Lo stesso tipo di messaggio ICMP è utilizzato (con un
diverso tipo di "opzione") per segnalare l'irraggiungibilità causa MTU
insufficiente su una interfaccia da PMTUD (Path Maximum Transfer Unit
Discovery) il sistema IP per segnalare l'MTU da utilizzare agli endpoint
di una comunicazione.
(In breve per chi non ne è a conoscenza: gli endpoint di una
comunicazione TCP mandano sempre pacchetti IP con il bit DF (Don't
Fragment) settato, in questo modo i router non possono frammentare il
pacchetto se devono farlo passare su un link che ha una MTU troppo
bassa, in questo caso il router segnala con un messaggio ICMP
unreachable, opzione "packet too big DF set, fragmentation needed" e la
nuova MTU consigliata l'host da cui è arrivato il pacchetto. A questo
punto l'host sa che deve ricomporre il suo pacchetto utilizzando una
nuova MTU)
Il punto è che i router Cisco per prevenire possibilità di attacchi (o
meglio che un router Cisco sia utilizzato per un attacco da
malintenzionati) impediscono di default al router di mandare più di 2
messaggi ICMP unreachable (di qualsiasi tipo) al secondo. Le macchine
con i virus saturavano quindi il numero di messaggi ICMP che il router
poteva mandare impendendo il corretto funzionamento di PMTUD.
In versioni ancora più recenti dell'IOS è possibile utilizzare una
apposita opzione che permette di alzare a piacimento il limite al
secondo di messaggi "ICMP network unreacheable" che un router può mandare.
Tutto ciò secondo me fa pensare a come alcune configurazioni di default
per la sicurezza possono diventare una minaccia ben peggiore di quelle
che vorrebbero evitare, basta rendersi conto con questa configurazione
dei due messaggi ICMP unreachable al secondo quanto è facile tagliare
fuori un'intera rete dietro a un tunnel...
grazie mille della risposta comunque!