ASA VPN IPSec: MTU issue or CFG error?! [Solved: BUG!!!]

[rinux]

Ciao,
il tunnel IPSec sale, è attivo ma funziona solo se i pacchetti +/- sotto i 100 bytes... non appena i pacchetti superano quella dimensione non passano più; ora mentre scrivo non ricordo se il problema è presente in tutti e due i versi (sia per i pacchetti in arrivo all'ASA che quelli in uscita) comunque sta di fatto che si presenta questo strano comportamento della VPN che tra l'altro non viene evidenziato dal ping (ping -f non dice che è necessario frammentare, è muto superata quella dimensione)...

La particolarità è che l'ASA sta dietro una linea HDSL di FastWeb con IP statico nattato dal Carrier; ovvero sull'interfaccia vs internet ho un'ip privato comunicatomi da FastWeb.

NB: se con un PC all'interno della rete attivo dov'è installato l'ASA attivo un tunnel IPSec verso un'altra destinazione non riscontro problemi... ...il problema c'è solo per le connessioni VPN dall'esterno verso quell'apparato

73 de Arturo

[rinux]

ma funziona solo se i pacchetti +/- sotto i 100 bytes

Catturando il traffico con Wireshark sull'interfaccia virtuale del PC su cui è attiva la VPN riscontro che se i pacchetti sono complessivamente sotto 166 bytes tutto funziona (i ping vanno e tornano), a 166 bytes invece non tornano...

14 (L2) + 20 (IP) + 8 (ICMP) + 124 (DATI) = 166 byes:

ping -l 124 ip.ip.ip.ip va in timeout

Non ho catturato il traffico sul ASA, mi sono limitato a controllare il traffico sul server pingato ed ho potuto riscontrare che risponde correttamente anche quando la risposta non arriva a destinazione!

Codice: Seleziona tutto

440 IP (tos 0x0, ttl 128, id 18392, offset 0, flags [none], proto ICMP (1), length 152)
              vpn001 > linux: ICMP echo request, id 1024, seq 1024, length 132

450 IP (tos 0x0, ttl 64, id 8124, offset 0, flags [none], proto ICMP (1), length 152)
              linux > vpn001: ICMP echo reply, id 1024, seq 1024, length 132

NB: il problema non si presenta con l'ICMP ma in modo generico con qualunque protocollo, per esempio la connessione SSH si blocca nella fase iniziale di scambio delle chiavi....

73
Arturo

[zot]

Visto che un ping normale funziona(ICMP standard ha un totale di 84 byte) direi che il tunnel VPN e' funzionante.
Proverei a giocare conl 'MTU della WAN dell'ASA ,non risolvendo, chiamerei FW dicendogli di sisemare l'MTU del loro router.
Chiamando l'assistenza alla fine ho sempre risolto...certo,dipende da chi ti capita...ma se lo guidi un po' vedrai che risolvi...digli di collegarsi al router mentre tu fai passare traffico su una connessione VPN.
Nel conteggio del pacchetto inviato dal ping non capisco a cosa ti riferisci con "L2" .

[rinux]

Proverei a giocare conl 'MTU della WAN dell'ASA

Ma tutto il resto funziona, ovvero senza tunnel o via SSL (anyconnect) non riscontro alcun problema...

Nel conteggio del pacchetto inviato dal ping non capisco a cosa ti riferisci con "L2" .

Mi riferisco al numero di bytes del Layer2 ethernet.

Aggiornamento: in attesa di coinvolgere il supporto telefonico di FW , ho testato diverse 'modalità' di funzionamento del client VPN attivando il tunnel con IPSec over TCP, IPSEC over UDP e No Transport Tunnelling ottenendo rispettivamente una dimensione massima sul ping di 152, 123 e 115 bytes ...oltre non tornano indietro le reply che vedo uscire.

Vedo un pò di luce , forse sto uscendo dal tunnel ...guardando il traffico sulla wan vedo che il problema è interno all'ASA : In pratica quando il ping funziona (sotto il valore limite) vedo due pacchetti ESP per ogni ping, in entrata ed uscita dall'ASA... quando il ping non funziona vedo solo il pacchetto in entrata.... segue che deve essere qualche maledetta impostazione sull'ASA.... (sulla inside tutto ok, request e reply passano regolarmente)!

Codice: Seleziona tutto

ping 'piccolo':
22	3.748396	x.x.x.x	192.168.y.y	ESP	ESP (SPI=0x7106d9e3) <- ping request
23	3.748884	192.168.y.y	x.x.x.x	ESP	ESP (SPI=0x05d0db4a) <- ping reply

ping 'grande':
27	2.981950	x.x.x.x	192.168.y.y	ESP	ESP(SPI=0x7106d9e3) <- ping request
manca quello del ping reply!

Devo trovare quale debug può tornare utile per evidenziare cosa non piace all'ASA

73
Arturo

[zot]

Guarda che ti stai rispondendo da solo.....MTU interfaccia ASA...a sto punto ti chiedo pure dove termina il tunnel ...sull'interfaccia WAN dell'ASA???
Perchè da come si comportano i pacchetti echo reply che non vedi ritornare sull'ASA ho il dubbio che possa terminare sull'interfaccia LAN....
Per quanto riguarda la lunghezza dei pacchetti devi tenere conto che fino a quando non viene decapsulato l'IPSEC (interfaccia WAN o altra appunto),devi aggiungerci ,prendendo come esempio una IPSEC client con ESP,l'header ,il trailer e l'auth di ESP stesso.
Il livello L2 ethernet non passa su internet,questo viene ricostruito sull'interfaccia del Gateway su cui termina la VPN
Questo per cercare di capire se il problema è prima o dopo il decapsulamento dell' IPSEC.
Ripeto,io cambierei l'MTU delle interfacce dell'ASA che funzioni tutto il resto,potrebbe non voler dire niente.

[rinux]

Ciao,

MTU interfaccia ASA...

Non ti seguo... l'MTU è settato a 1500 sulle varie interfacce (vlan)... dove dovrei cambiare/impostare l'MTU?

Ok, stabilito che non dipende dalla connessione di FastWeb ovvero ho lo stesso problema su una connessione con IP pubblico sulla vlan outside; i due apparati hanno in comune la versione del fw...

Codice: Seleziona tutto

Cisco Adaptive Security Appliance Software Version 8.0(4) 
Device Manager Version 6.1(3)

Compiled on Thu 07-Aug-08 20:53 by builders
System image file is "disk0:/asa804-k8.bin"
Config file at boot was "startup-config"

Hardware:   ASA5505, 256 MB RAM, CPU Geode 500 MHz
Internal ATA Compact Flash, 128MB
BIOS Flash Firmware Hub @ 0xffe00000, 1024KB

Encryption hardware device : Cisco ASA-5505 on-board accelerator (revision 0x0)
                             Boot microcode   : CN1000-MC-BOOT-2.00 
                             SSL/IKE microcode: CNLite-MC-SSLm-PLUS-2.03
                             IPSec microcode  : CNlite-MC-IPSECm-MAIN-2.05

Licensed features for this platform:
Maximum Physical Interfaces  : 8         
VLANs                        : 20, DMZ Unrestricted
Inside Hosts                 : Unlimited 
Failover                     : Active/Standby
VPN-DES                      : Enabled   
VPN-3DES-AES                 : Enabled   
VPN Peers                    : 25        
WebVPN Peers                 : 2         
Dual ISPs                    : Enabled   
VLAN Trunk Ports             : 8         
AnyConnect for Mobile        : Disabled  
AnyConnect for Linksys phone : Disabled  
Advanced Endpoint Assessment : Disabled  
UC Proxy Sessions            : 2         

This platform has an ASA 5505 Security Plus license.

Ho fatto un parallelo con un'altro ASA per verificare differenze notevoli nella configurazione ma non trovo nulla di particolare ; resta questo maledetto problema solo sull'IPSec (i tunnel via anyConnect funzionano una meraviglia e dallo stesso client IPSec riesco a lavorare correttamente con altri tunnel terminati su ASA o su routers).

Provo a fare una ricerca in giro per vedere se c'è qualche problema simile.

73
Arturo

[rinux]

...ovvero ho lo stesso problema su una connessione con IP pubblico sulla vlan outside; i due apparati hanno in comune la versione del fw...

Bingo,
la dritta l'ho avuta sul supportforums di Cisco....

This sounds very much like the following bug:

CSCsu26649 Large packets dropped with ip-comp enable configured

Can you confirm that you have "ip-comp enable" in your vpn config? If so, disable that and you should be ok.

Better yet, upgrade to 8.0(5).

Grazie a tutti,
problema archiviato... in attesa di fissare il bug con l'aggiornamento del FW ho disabilitato la compressione ed il tunnel funziona

73
Arturo

[zot]

Scoperto l'arcano....grazie di aver postato la soluzione....a sto punto ti chiedo che FW hai su...

[zot]

Opps...non avevo letto

Codice: Seleziona tutto

asa804-k8.bin

[rinux]

a sto punto ti chiedo che FW hai su...

Non sono andato a leggere nel dettaglio cosa riporta la segnalazione di BUG indicata ma sta di fatto che sulla versione 8.0(2) ovvero due rilasci prima il problema non si presentava... scommetto, visto il tipo di bug, che è uscito e sparito con quella maledetta 8.0(4) ...mi ha portato via un casino di tempo anche perchè sono stato sviato dal fatto che il problema si è presentato su una connessione 'atipica' e non ho pensato subito a fare una prova altrove !!!

Ma come dice il saggio... tutto è bene ciò che finisce bene.

73
Arturo