Newsgroup: it.comp.reti.cisco
Titolo: VPN+MTU=Mal di testa

Premetto che non ne capisco granchč..
Ho messo su una VPN tra  le interfacce ATM0.1 di un 1721 e una Fast0/0 
di un 2621... le chiavi si scambiano, la vpn va su e il ping tra le 
due reti funge, ma la condivisione (windows) no!.
Dopo due giorni di tentativi butto via tutto e creo un Tunnel GRE.
Orrore! Manco quello andava!!! a forza di tentoni č partito grazie ad 
un <ip mtu 1500> sulla t1 del 2621...
Allora provo ad applicare la vpn tentando stavolta di incapsularla nel 
GRE e ottengo...  uno schiaffone morale! Stessa solfa, le sa vanno a 
posto, il ping pinga, ma di condivisione files non se ne parla.
Sul sito cisco non sono riuscito a cavare un ragno dal buco, forse 
anche perchč dopo tutti questi tentativi i miei poveri neuroni erano 
scappati all'estero..
Grazie anticipatamente per qualunqe suggerimento, soprattutto dal 
neurone fuggito in giamaica.   :-P
Maurizio


Prova a generare dei ping di dimensioni attorno ai 1500 bytes con e senza 
flag df attivato e vedi cosa succede.
ping x.x.x.x -l 1500 -f
Ciao,
        Tosh. 

 reti funge, ma la condivisione (windows) no!.
prova con una cosa simile a questa (su entrambi i lati chiaramente):
access-list no-df permit ip lanlocale wildlocale lanremota wildremota
route-map clear-df permit 10
 match ip address no-df
 set ip df 0
e nelle "inside" 
ip policy route-map clear-df
questo setta a 0 il bit DF quindi il pacchetto viene frammentato e non
droppato.
un mayhem e le magie della posta elettronica
-- 
A condom is the glass slipper for our generation. You slip one on when
you meet a stranger. You "dance" all night, and then you throw it away.
The condom, I mean, not the stranger.
http://www.recursiva.org
 - Key on 
pgp.mit.edu
 ID B88FE057

 e nelle "inside" 
questo mi farebbe supporre la eth_retelocale in in....
Brutta cosa l'ignoranza...studierň.
Grazie ancora.
Maurizio

 pacchetti che matchano la acl. Ma su quale interfaccia va applicata?
le ethernet attaccate alla lan.
un mayhem che vorrebbe ascoltare un po' di musica


 un mayhem che vorrebbe ascoltare un po' di musica
mmm.. spiega un secondino (scusa eh)
Da quello che so io (anche da casi di NON funzionamento rimessi in piedi 
in qualche modo) nell'IPSEC se un pacchetto viene frammentato (dopo 
essere stato criptato) non viene più correttamente ricostruito alla fine 
del tunnel e quindi, de facto, non perviene a destinazione.
Da quello che dici il comando dice al router di frammentare e non droppare.
Uh? ma se frammenta è comunque il destinatario che droppa perchè non 
riesce a ricostruire..
Mi sa che ho qualcosa di poco chiaro in proposito...

Ahi! Ho cantato vittoria troppo presto.   :-(
Infatti la condivisione windows funge (spero), ma i servizi terminal 
(dietro al 2621 c'è un win2003) e l'ultravnc mica tanto... anzi per 
niente.
E invece se rimonto il tunnel GRE o passo dalla 1723 nattata funziona 
ogni cosa, quindi l'inghippo è ancora una volta nell'ipsec e nei 
pacchettoni troppo grassocci che a quanto pare non gradiscono la 
frammentazione e crittatura.
Ma allora perchè clearando il df la condivisione è partita? 
Sembrarebbe che i pacchettoni vengano rimontati e correttamente 
decrittati. E allora perchè i pacchetti dei servizi terminal non 
seguono la stessa sorte? Che hanno? I brufoli?
Inoltre un 
    	ping mioserver -l 45000 -t
va come un razzo.  (Dubbio : ma l'ICMP viene criptato?)
Ora potrei anche risolvere (probabilmente) abbassando l'mtu size sulla 
direttamente sul 2003, ma la soluzione non mi piace. Se il problema è 
nell'ipsec anche la soluzione dovrebbe trovarsi lì...
Come mi sento scarso! Mi fa rabbia stà cosa.
E il neurone 'fumato' dalla Giamaica si sposta all'India... di tornare 
a casa per ora non se ne parla!
Ciao a tutti
Maurizio


Questo mi sembra un problema piuttosto vecchio, i pacchetti ipsec sono visti 
dalla rete come pacchetti ip normalissimi, quindi possono essere frammentati 
come tutti gli altri, il problema è semmai di prestazioni dei router.
Ad ogni buon conto ios di default copia il bit df del pacchetto originale 
nel pacchetto ipsec e lo frammenta solo dopo averlo crittato e solo se il 
bit df è a 0.
Per ottenere la frammentazione prima occorre abilitarla esplicitamente 
mediante l'apposito comando, posto che sia disponibile nella particolare 
release:
crypto ipsec fragmentation before-encryption
Ciao,
         Tosh.


Togli ogni comando che cancella il bit df e prova a mandare dei ping di 
varie dimensioni con il flag -f attivo, cosě dovresti vedere qual'č la 
dimensione massima dei pacchetti che possono circolare sulla tua rete 
(ricordati di aggiungere 8 byte di header icmp).
A questo punto puoi provare ad utilizzare il comando "ip tcp adjust-mss 
xxxx" sulle interfacce interne dei due router (se disponibile nelle tue 
release) o diminuire l'mtu sulle interfacce esterne.
Un'altra cosa, controlla che non siano bloccati gli icmp dall'esterno, 
altrimenti i client dotati della funzione di discovery dell'mtu non potranno 
utilizzarla.
Ciao,
         Tosh.

 riesce a ricostruire..
no, non e' il nostro caso.
tu hai un pacchetto di 1500, lo devi incapsulare ipsec, quindi aggiungi
degli header che renderebbero il pacchetto superiore all'mtu.
allora prendi il pacchetto, lo rompi in 2 parti e aggiungi l'header ipsec
ai due frammenti. il riassemblamento viene effettuato dopo la
decriptazione.
e' chiaro che se il pacchetto ha df=1 non puo' essere frammentato e viene
scartato.
un mayhem che spera di aver chiarito


 un mayhem che spera di aver chiarito
Sì. Chiaro. QUindi la frammentazione viene effettuata PRIMA della 
criptazione.
Perfetto ora mi torna. Grazie ad entrambi

 Perfetto ora mi torna. Grazie ad entrambi
Secondo questo documento e secondo quanto ho sempre saputo non č cosě:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080115533.html
Ciao,
         Tosh. 

 
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080115533.html
minchia ... hai ragione :)))
When a packet is nearly the size of the maximum transmission unit (MTU) of
the outbound link of the encrypting router, and it is encapsulated with
IPSec headers, it is likely to exceed the MTU of the outbound link. This
causes packet fragmentation after encryption, which makes the decrypting
router reassemble in the process path.
ora spiegami perche' allora settare df=0 fa funzionare le comunicazioni
che usano grossi pacchetti attraverso un link criptato ...
e nel caso di gre? usano lo stesso meccanismo
un mayhem che non ha tempo di cercare ora ... ma se non lo spieghi tu lo
farà...



Ecco... proprio quando credevo di avere, finalmente, capito... :)


Non farmi sentire maestro proprio oggi che mi sono fatto mezza bottiglia di 
vino, un paio di amari ed un fumogeno cubano che mi stanno ancora facendo 
girare l'ufficio attorno :-)
La risposta è tra le righe dello stesso documento, per chi ha il tempo di 
leggerlo bene.....
Pare che ios, in mancanza di istruzioni contrarie, tenda a costruire un 
pacchetto incapsulato per ogni pacchetto in chiaro, ricopiando pure tutti i 
flag del pacchetto originale in quello nuovo, questo a quanto ne so io vale 
per tutti i sistemi di tunneling.
E' così che un pacchetto ip con il df settato si trasforma in un pacchetto 
ipsec o gre con il df settato, ma più grande e ovviamente con un nuovo 
header ip, cosa che produce gli effetti che conosciamo.
Quella di frammentare prima di incapsulare è una conquista abbastanza 
recente, probabilmente non riuscivano a farla andare d'accordo con qualche 
altra funzionalità, forse il cef che viene citato nello stesso documento.
Adesso che ho detto tutto quello che so sull'argomento mi sa che debbo 
provare a fermare queste pareti che mi girano attorno :-)
Ciao,
         Tosh. 



I miei router sembrerebbero, di default, frammentare e poi criptare.  
Un crypto ipsec fragmentation before-encryption
non viene riportato dallo sh ru, come per tutte le impostazioni di 
default.
Invece
crypto ipsec fragmentation after-encryption
viene mostrato nello sh ru.
Maurizio


Qui si entra del campo delle complicate strategie e dei lunghi tempi di 
testing delle funzionalità di cisco.
E' piuttosto normale che le nuove funzionalità vengano introdotte come 
opzionali, magari solo in alcune release, e poi diventino parte dei comandi 
di default, visibili o meno nella config.
Uno degli esempi più famosi è "ip directed-broadcast" che prima della 12.0 
era il default e non compariva nemmeno nelle config, poi il default è 
diventato "no ip directed-broadcast" visibile in config, alla fine è sparito 
dalla config e ricompare solo se lo attivi, esattamente l'opposto dei 
primordi, ma nel frattempo ha subito un passaggio intermedio.
Il fatto che un comando compaia nello sh run è una scelta strategica di 
cisco, quelli che compaiono nelle config di fabbrica sono comunque dei 
default, ma non tutti i default possono comparire nello sh run, altrimenti 
le configurazioni dei router diventerebbero chilometriche ed illeggibili.
Ciao,
        Tosh. 

 
Allora : 1472 in IPSEC e sempre 1472 sulla 3050 nattata. (1723 non 
c'entrava nulla, è un lapsus)
Il che mi fa pensare che il problema non sia l'mtu ma qualcos'altro, 
forse relativo all'indirizzo ip che esce dall'ipsec e ai criteri di 
protezione di windows 2003 o qualcosa altro di storto.
In effetti qualunque ulteriore tentativo fatto sull'mtu ha avuto esito 
negativo.
(Mi ricordava tanto un problema avuto con gli XP che non andavano in 
Vpn col 2000 server, ma il problema si verificava solo in 
configurazione XP->827->Internet->827->2000Srv, e risolto grazie al 
supporto MS)
Fatto stà che utilizzando l'IPSEC all'interno del tunnel GRE tutto 
sembrerebbe essere andato a posto...
Segue la mia config attuale sul 2621, col nat ancora da scremare e le 
acl di sicurezza da configurare.
Grazie a tutti per la gentilezza.
Maurizio
P.S. Mi potreste dire quale news server usate per it.comp.reti.cisco? 
lo leggerei volentieri ma interbusiness tiene solo un migliaio di 
posts...
P.P.S   (x Tosh) W il fumogeno toscano!!!
!
! Last configuration change at 19:16:00 METDST Thu May 19 2005 by 
****************
! NVRAM config last updated at 19:17:39 METDST Thu May 19 2005 by 
****************
!
version 12.3
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname ****************
!
boot-start-marker
boot-end-marker
!
no logging buffered
enable secret 5 $1$sBfA$cp0YCsmBav8ksZW6D0ffU/
!
username **************** privilege 15 password 7 *******************
clock timezone MET -2
clock summer-time METDST recurring last Sun Mar 2:00 last Sun Oct 2:00
no aaa new-model
ip subnet-zero
no ip source-route
ip cef
!
!
no ip domain lookup
!
no ip bootp server
ip audit po max-events 100
!
!
!
!
!
!
!
!
!
!
!
!
!
! 
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
crypto isakmp key ********** address ************
!
!
crypto ipsec transform-set myTrSet esp-aes esp-sha-hmac comp-lzs 
crypto ipsec df-bit clear
!
crypto map myvpn 10 ipsec-isakmp 
 set peer **************
 set transform-set myTrSet 
 match address 101
!
!
!
!
interface Null0
 no ip unreachables
!
interface Tunnel4
 description ** Tunnel verso XXXXX **
 ip unnumbered FastEthernet0/1
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1500
 tunnel source FastEthernet0/1
 tunnel destination *****************
 tunnel key ***********
 tunnel checksum
 crypto map myvpn
!
interface FastEthernet0/0
 description connected to EthernetLAN
 ip address 192.168.100.254 255.255.255.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat inside
 no ip mroute-cache
 duplex auto
 speed auto
 no cdp enable
 hold-queue 100 out
!
interface FastEthernet0/1
 description connected to Internet
 ip address ************ 255.255.255.240
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 no ip route-cache cef
 no ip route-cache
 duplex auto
 speed auto
 crypto map myvpn
!
ip nat translation timeout 3600
ip nat translation tcp-timeout 3600
ip nat translation udp-timeout 1200
ip nat translation finrst-timeout 300
ip nat translation syn-timeout 120
ip nat translation dns-timeout 300
ip nat translation icmp-timeout 120
ip nat translation max-entries 4096
ip nat inside source route-map noNat interface FastEthernet0/1 
overload
ip nat inside source static tcp 192.168.100.1 80 **************** 80 
extendable
ip nat inside source static tcp 192.168.100.1 3050 **************** 
3050 extendable
ip nat inside source static tcp 192.168.100.1 110 **************** 110 
extendable
ip nat inside source static tcp 192.168.100.1 25 **************** 25 
extendable
ip nat inside source static tcp 192.168.100.1 21 **************** 21 
extendable
ip nat inside source static tcp 192.168.100.1 48300 **************** 
48300 extendable
ip nat inside source static tcp 192.168.100.1 48301 **************** 
48301 extendable
ip nat inside source static tcp 192.168.100.1 48302 **************** 
48302 extendable
ip nat inside source static tcp 192.168.100.1 48303 **************** 
48303 extendable
ip nat inside source static tcp 192.168.100.1 48304 **************** 
48304 extendable
ip nat inside source static tcp 192.168.100.1 48305 **************** 
48305 extendable
ip nat inside source static tcp 192.168.100.1 48306 **************** 
48306 extendable
ip nat inside source static tcp 192.168.100.1 48307 **************** 
48307 extendable
ip nat inside source static tcp 192.168.100.1 48308 **************** 
48308 extendable
ip nat inside source static tcp 192.168.100.1 48309 **************** 
48309 extendable
ip nat inside source static tcp 192.168.100.1 48310 **************** 
48310 extendable
ip nat inside source static tcp 192.168.100.1 48311 **************** 
48311 extendable
ip nat inside source static tcp 192.168.100.1 48312 **************** 
48312 extendable
ip nat inside source static tcp 192.168.100.1 48313 **************** 
48313 extendable
ip nat inside source static tcp 192.168.100.1 48314 **************** 
48314 extendable
ip nat inside source static tcp 192.168.100.1 48315 **************** 
48315 extendable
ip nat inside source static tcp 192.168.100.1 48316 **************** 
48316 extendable
ip nat inside source static tcp 192.168.100.1 48317 **************** 
48317 extendable
ip nat inside source static tcp 192.168.100.1 48318 **************** 
48318 extendable
ip nat inside source static tcp 192.168.100.1 48319 **************** 
48319 extendable
ip nat inside source static tcp 192.168.100.1 48320 **************** 
48320 extendable
ip nat inside source static tcp 192.168.100.1 48321 **************** 
48321 extendable
ip nat inside source static tcp 192.168.100.1 48322 **************** 
48322 extendable
ip nat inside source static tcp 192.168.100.1 48323 **************** 
48323 extendable
ip nat inside source static tcp 192.168.100.1 48324 **************** 
48324 extendable
ip nat inside source static tcp 192.168.100.1 48325 **************** 
48325 extendable
ip nat inside source static tcp 192.168.100.1 48326 **************** 
48326 extendable
ip nat inside source static tcp 192.168.100.1 48327 **************** 
48327 extendable
ip nat inside source static tcp 192.168.100.1 48328 **************** 
48328 extendable
ip nat inside source static tcp 192.168.100.1 48329 **************** 
48329 extendable
ip nat inside source static tcp 192.168.100.1 48330 **************** 
48330 extendable
no ip http server
no ip http secure-server
ip classless
ip route 0.0.0.0 0.0.0.0 FastEthernet0/1
ip route 192.168.0.0 255.255.255.0 Tunnel4
!
!
access-list 23 permit ****************
access-list 23 permit *************** 0.0.0.15
access-list 101 remark vpn pattern
access-list 101 permit ip 192.168.100.0 0.0.0.255 192.168.0.0 
0.0.0.255
access-list 102 remark NAT con esclusione IPsec
access-list 102 deny   ip 192.168.100.0 0.0.0.255 192.168.0.0 
0.0.0.255
access-list 102 permit ip 192.168.100.0 0.0.0.255 any
access-list 108 remark NAT temporaneo senza IPsec
access-list 108 permit ip 192.168.100.0 0.0.0.255 any
!
route-map noNat permit 10
 match ip address 108
!
snmp-server community ******* RO
!
!
!
!
!
line con 0
 login local
line aux 0
line vty 0 4
 access-class 23 in
 login local
!
ntp clock-period 17179377
ntp server **************
!
end


O non lo avevi detto o nessuno ha colto il fatto che c'era di mezzo il nat, 
quindi il tuo problema era (anche) questo:
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080094634.shtml
In pratica i pacchetti provenienti dal tuo server e che matchavano una 
static venivano nattati sempre e comunque, spiazzando di fatto il motore 
ipsec del router.
Per aggirare il problema occorre far uscire i pacchetti da tunnelizzare 
attraverso un'interfaccia non dichiarata come nat outside, come una loopback 
o nel tuo caso il tunnel gre.
Morale, ricordarsi sempre di postare le config complete.
Ciao,
        Tosh. 

 
Letto. Compreso solo in parte.
Hem. Scus. Non lo avevo detto perchè credevo che la ACL 102 evitasse 
da sola il NAT dei pacchetti destinati all'altro peer.
->its source address is changed to 200.1.1.25 before it is checked 
->against the crypto map, and it does not match any permit statement 
->of ACL 101 and cannot be encrypted
Da quanto leggo dovrebbe voler dire senza gre o loopback i pacchetti 
post-nat non matchano la acl e quindi non subiscono l'encryption. Ma 
se non matchano allora non dovrebbero nemmeno essere inviati all'altro 
peer.
Avrei capito se non avesse funzionato del tutto.
Ma come potevo avere un funzionamento parziale ?!
Oppure in qualche modo vengono inviati lo stesso all'altro peer e 
l'altro router li accetta anche se privi di criptatura ?? 
Questo sarebbe pure peggio, si potrebbero inviare pacchetti spoofati 
non crittati e l'altro peer li accetterebbe lo stesso come buoni...
Per quanto riguarda la config, avevo paura di  commettere l'errore che 
poi *HO COMMESSO*, e che mi ha costretto a cambiare le password 
stamani. Sgrunt.
Lo sapevo che ci cascavo. Come col sale nel caffè dopo che mia moglie 
ha cambiato i barattoli. Stamani c'ho rifatto.
Ciao


La risposta potrebbe essere nel fatto che tu non hai configurato uno static 
nat, ma degli static pat, per cui tutte le porte non elencate nei tuoi 
comandi static non rientrano in questo problema.
Ciao,
        Tosh. 

 un nuovo header ip, cosa che produce gli effetti che conosciamo.
avevo letto la tua risposta in fretta e non avevo capito nulla
promettendomi di rileggerla oggi con attenzione.
nel frattempo stanotte ci ho pensato e sono giunto esattamente alla stessa
conclusione, che sembra essere l'unica in grado di spiegare la cosa :)
un mayhem nell'errore per anni :(



Pensavo di essere un caso da psicanalisi, ma vedo con piacere che non sono 
l'unico ad elaborare geometrie euclidee la notte......se non altro so di 
essere in buona compagnia :-)
Nello specifico, sono quelle cose nelle quali ti imbatti se devi affrontare 
pesantemente il problema o se ti casca l'occhio su un documento che ne 
parla, poi la mente si apre e tutto sembra talmente logico da farti sentire 
una scimmia per non averci pensato prima....pratica quotidiana.
Chi conosce tutte le funzionalità ed i meccanismi interni dei comandi di ios 
(o di *x o di qualunque altra brodaglia informatica) scagli la prima pietra.
Ciao,
        Tosh.