On Wed, Mar 12, 2008 at 10:06 PM, Gori Pinto <[EMAIL PROTECTED]> wrote: > Mi sembra di aver capito che il tuo client sta sull'inside di un ASA e > che cerchi di passare da questo ASA per collegarti ad un PIX in VPN > ... se si allora leggi il resto ... altrimenti ignoralo :D
esatto, la situazione e' questa [...] > Mi sembra evidente da questo log che il tuo client sta cercando di > comunicare con il PIX senza il NAT traversal ossia senza > l'encapsulazione in UDP/4500 (protocol 50 è appunto ESP). > Il NAT traversal è abilitato di default sui dispositivi cisco perchè > nella quasi totalità dei casi i client stanno dietro nat in una rete > privata. (appunto il nat che fa l'ASA di cui parli) ok, e fin qui direi che siamo d'accordo > Sembra però che in questo caso il nat traversal sia disabilitato o che > la negoziazione fallisca durante lo scambio IKE, non so se si può > disabilitare sul client VPN, molto probabilmente lo si può > disabilatare sul pix. > Ti consiglio di verificare se è disabilitato in uno dei due casi e > inoltre di vedere nei log del pix (usa il comando debug crypto isakmp) > perchè il nat detection fallisce. Ora non ricordo l'output del debug sul pix remoto in questione (deb crypto engine, isakmp e ipsec), ma non ho notato errori particolari. La cosa strana e' che da quell'asa la connessione con il client vpn non funziona verso nessuno dei pix/asa (remoti) che gestisco, e sono parecchi, mentre da dietro qualsiasi altro pix/asa sopra citato, tutto funziona senza problemi. Volevo evitare di essere di fronte al classico problema "stupido", talmente evidente che a volte uno rischia di non accorgersene :) Se a vedere la configurazione mi dite che e' tutto ok, penso che provero' a fare un bel wr erase e riconfiguro il tutto passo passo. Intanto grazie per l'interessamento. Ciao Marco -- bizza http://www.rm-rf.eu/ _______________________________________________ Cug mailing list http://www.areanetworking.it/index_docs.php [email protected] http://ml.areanetworking.it/mailman/listinfo/cug
