Newsgroup: it.comp.reti.cisco
Titolo: problema tunnel GRE + IPSEC + tunnel GRE e PMTU (probabile causa)

Salve a tutti,
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?

 qualche suggerimento?
vedi sopra,
spero di essere stato di aiuto...
ciao

 
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!