Newsgroup: it.comp.reti.cisco
Titolo: alcuni dubbi su pix e VPN

spero che qualcuno possa chiarirmi questo dubbio...
se ho capito bene la access-list applicata alla crypto map (a sua volta
applcata ad un'interfaccia) stabilisce non solo quale traffico deve essere
inoltrato tramite il tunnel ipsec ma in qualche modo indica anche una
"route" per quel traffico. E' così?
(Ok, forse il mio modo di esprimere la cosa non è adeguato alla logica cisco
ma a mio modo di vedere a rigore sono due cose separate (1) stabilire quali
pacchetti vanno dentro un tunnel ipsec e (2) verso quale interfaccia
instradare un pacchetto a seconda della destinazione)
capisco che dovrebbe essere una situazione strana ma facciamo conto di avere
configurato una VPN terminata da un ip su interfaccia "outside" con
relativa acl che riguarda tutti i pacchetti provenienti da A e destinati a
B: che succede che inserisco nel pix una route statica per B su "inside"
tramite un gateway visibile da "inside"? un pacchetto poveniente da A
(mettimao tramite un'interfaccia DMZ) e destinato a B andrà sempre a finire
nel tunnel ipsec o sarà instradato tramite "inside"?
altra domanda: per "sospendere" un tunnel ipsec basta togliere
l'associazione con l'interfaccia? (un po' come quando si mandano le
interfacce in shutdown?)
Grazie mille

interfacce in shutdown?)
Se intendi il comando "crypto map xxxxx interface outside"
la risposta è si.
Ciao,
        Tosh.
Grazie mille

 viene richiamata dal nat.
si il nat dovrebbe naturalmente avvenire dopo il routing ma il problema è:
vince il routing dato con un'istruzione "route" o il "routing implicito"
dato dalle acl applicate al tunnel?
Se è vero (e richiedo conferma) che l'acl applicata alla VPN ad un certo
punto seleziona i pacchetti da inoltrare tramite la VPN quando avviene
questo? prima o dopo l'instradamento tramite la tabella di routing
"canonica"?
A naso (non avendo sperimentato alcunché) sarei tentato di dire prima
altrimenti sarebbe ad esempio impossibile (se ho capito bene la cosa) far
passare il traffico di A verso B tramite il tunnel e contemporaneamente il
traffico di X verso B tramite un gateway visto da "inside" (supponiamo che
il pix sia collegato alla rete B sia tramite VPN che tramite un gateway su
"inside").
Che ne dici?
Non capisco poi bene l'affermazione  "e la crypto acl viene richiamata dal
nat". Certo è necessaria una istruzione "nat 0" per le reti che devono
passare nel tunnel (non nattate) ma perché è queste che "richiama" la
crypto acl? non capisco bene la logica...
Scusa la verbosità e grazie mille per le tue risposte!

crypto acl? non capisco bene la logica...
Mi sono espresso male, forse confuso dal fatto che spesso la acl del nat0 e
la crypto acl sono fisicamente la stessa.
Volevo dire che i pacchetti vengono ruotati verso l'esterno, prima
intercettati dal nat e poi intercettati dal motore di routing.
Quando avrò tempo vedrò di cercare qualche info più precisa sull'argomento,
sempre che qualcun altro non abbia la soluzione in tasca e ce la voglia
presentare.
Ciao,
        Tosh.

 interfacce in shutdown?)
si.
un mayhem che e' tardi
-- 
 Lo scetticismo e' l'inizio della fede. OW 
 Cisco  FAQ: 
http://mayhem.oltrelinux.com/icrc
 SPP  wpage: 
http://www.spippolatori.org
 Key on 
pgp.mit.edu
 ID B88FE057

 
e quindi non passa per il tunnel... :-)
Grazie mille!
P.S.
Tosh concordi?

 
non avevo letto questa tua risposta: credo che ci siamo fraintesi :-) questo
era esattamente quello che io pensavo fosse il comportamento corretto e il
comportamento del pix (poi avevo cambiato idea mal interpretando le tue
parole e sviato da una strana e incongruente configurazione che ho trovato
su un pix su cui stavo mettendo le mani).
Ciao

>Tosh concordi?
E chi ci prova a dare torto a Mayhem?
Scherzi a parte, è logico che sia così, le uniche route implicite che
conosco, a memoria, sono quelle delle reti direttamente connesse, che
essendo tali possono permetterselo.
Sarebbe comunque carino se ci fosse un meccanismo per cui il pix (o router)
creasse ed eliminasse le route in funzione del fatto che il tunnel ipsec sia
o meno attivo; purtroppo però è il classico gatto che si morde la coda, in
questo modo il tunnel non si attiverebbe mai, proprio come per le dialer
isdn.
Esiste il meccanismo dei keepalive che però, da quanto ne so io, è usato
solo per selezionare tunnel ipsec alternativi, non per creare o eliminare
dinamicamente una route come quando un'interfaccia "vera" diventa down (un
tunnel ipsec non è visto come un'interfaccia).
A pensarci bene sarebbe interessante avviare una discussione sul perchè i
tunnel ipsec non possono avere una loro interfaccia come ad esempio i tunnel
gre.
Forse la tua domanda era nata da considerazioni come queste.
Ciao,
        Tosh.

 tunnel gre.
ci devo pensare (ho bevuto troppo sangue di giuda per averne voglia
ora).
un mayhem pattinatore



Però anche il gre corrisponde alla tua descrizione ma si comporta
diversamente.
Non so ... il problema vero secondo me è che ipsec è più simile ad una
dialer che ad un tunnel permanente, per via dei lifetime delle sa.
Il fatto che la route si "autoestinguesse" significherebbe irrimediabilmente
che il tunnel non potrebbe più riattivarsi, esattamente come farebbe una
dialer senza il traffico interessante.
Se però si accettasse che tramite il meccanismo già previsto dei keepalive
il tunnel diventasse permanente (salvaguardando ovviamente il meccanismo del
rekeying), allora si potrebbe anche accettare che venga elevato a rango di
interfaccia e come tale possa andare up/down e quindi condizionare la
tabella di routing.
Ci deve però essere qualche pecca nel mio ragionamento, altrimenti sarebbe
già stato applicato :-)
Magari è qualcosa di implicito nello standard.
Ciao,
         Tosh.