Newsgroup: it.comp.reti.cisco
Titolo: X Mayhem, Fabio Sardone e chiunque mi puo' aiutare!

Ciao a tutti...mi spiace inondare il news group con le mie richieste di
aiuto ma tant'e'...ho bisogno! ;-)
Ero alle prese con una vpn dinamica verso un router Cisco 827.
Il problema era far convivere la VPN punto punto che gia' avevo
(funzionante) e la vpn dinamica.
Alla fine ci sono riuscito con aiuti vostri e doc della cisco...
In pratica ora s iriesce ad effettuare il collegamento...fase 1 e fase 2
hanno successo...la connessione si stabilisce con la loro brava password.
Poi pero' l'accesso alla lan a cui mi collego non esiste!
Non riesco a pingare nessuna macchina della lan-...nemmeno il router stesso
(!).
Temo sia un problema di access list e leggendo i vecchi messaggi, mayhem
suggeriva un
access-list # permit ip host X host Y
dicendo checio' che proviene da Y e diretto a X DEVE essere crittato
altriemnti viene droppato.
Bene...ma io non conosco Y (e' dinamico) e soprattutto...non dovrei creare
la acl simile a quelal creata per i ltunnel ipsec della punto punto?
Infatti per il tunnel avevo:
access-list 120 permit esp host IP_PUB_ROUTER_REMOTO host
IP_PUB_ROUTER_LOCALE
access-list 120 permit udp host IP_PUB_ROUTER_REMOTO eq isakmp host
IP_PUB_ROUTER_LOCALE eq isakmp
access-list 120 permit ip any host IP_PUB_ROUTER_LOCALE
speculare poi sull'altro router...
quindi la domanda...come faccio ad accettare/mandare pacchetti alla macchina
che si collega dinamicamente col client cisco vpn?
Devo creare una nuova acl? la devo applicare alla Dialer0 o direttamente
nella "crypto isakmp client configuration group NOME" dove ho anche chiave e
parametri vari?
Non so piu' che fare....ormai sono giorni che ci provo...
PS: magari dipende tutto da quel maledetto address respond che quando viene
salvato nello startup-config mi blocca la vpn puntopunto? ma a questo ci
pensero' dopo! Mi basterebbe pingare le macchine sulla lan...temo i
llicenziamento se non mi muovo sob! ;-)
Grazie a chiunque puo' darmi una dritta!
Ciao ciao

 llicenziamento se non mi muovo sob! ;-)
Se sei un lavoratore a contratto beh .....
Se sei un dipendente, il datore di lavoro dovrebbe formarti se ti impiega in
aree o con competenze per cui non eri stato assunto. Licenziato cosi' e' senza
giusta causa.
-- 
   __|__  Fabio Sardone|  
____(0)_____           | 
http://www.geocities.com/f_sardone/pictures.html
  O  o  O              | Change dot in . and remove .invalid

 giusta causa.
Veramente mi ha appena detto che se non riesco lui chiama un tecnico...cosa
che ha minacciatpo anche due mesi fa senza poi chiamarlo!
PS il mio collega che c'era tempo fa era dipendente pure lei...ma e' stata
licenziata...le ditte con meno di 15 dipendenti...
PS2 Ovviamente chi ha in mano le "informazioni" puo' avere la legge dalla
propria parte...e i lcapo sta pagando una buona uscita mica da ridere per
questo licenziamento...ma temo molto ceh potrebbero fare lo stesso con me...
Forse con le 4 statiche me la cavo! ;-)
Speriamo...col periodo di crisi non lo vedo bene di licenziamento...che vita
difficile! ;-(
PS Brillantissima l'idea temporanea: ho nattato 4 porte...facendo le
statiche ho dato i servizi richiesti al cliente!
E che non rompano le scatole finche non tiro su la vpn dinamica! ;-)
Pare andare! ;-) Ha problemi solo con ftp...ma gli ho detto di lanciarlo da
dentro una sessione telnet...
Che belal cosa i router cisco pero'...a saperli usare  mi sa che fanno anche
il caffe!

Grazie al consiglio di Fabio ho risolto, non sapevo che prima processa il
NAT e poi il crypto.
Il vpnclient si autenticava e si prendeva il suo bell'ip dato dal router,
però non pingava niente.
Provando dal router a tracerutare l'ip del client, si vedeva che il
pacchetto moriva al primo hop di telecom, quindi si deduce che nell'header
il destinatario era rimasto 192.168.4.10 (ip del vpnclient) e quindi non era
stato processato dalla critto ma dalla nat che l'aveva sparato fuori.
Una ritoccata al nat e ora funziona
!
ip local pool vpnpool 192.168.4.10 192.168.4.20
ip nat inside source list 102 interface Dialer1 overload
!
!
access-list 102 deny ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255
access-list 102 permit ip 192.168.1.0 0.0.0.255 any
access-list 102 deny ip any any
Ora non so se l'acl 102 con permit e deny misti è elegante o meno, cmq
chiusa con un deny any any non permetto che anche il majale venga nattato
fuori (perchè ho cominciato l'acl con un deny per cui chiunque non matchi
viene di default permittato, almeno cosi avevo letto)....ma non ho trovatto
un comado tipo " ! " di negazione..ma sul cisco esiste? che ne so,
access-list 102 permit ip 192.168.1.0 0.0.0.255 !192.168.4.0 0.0.0.255 ???
Considera che non ho definito una loopback, e nemmeno una acl associata a
qualche crypto sonasegaio....configurazioen liscia ma per ora va.
Rimane il problema del vpnclient in dialup + sk di rete per la lan: quando
la vpn è su, non posso accedere alla lan...indagherò
"Fabio Sardone" <fsar...@btinternetdotcom.invalid> ha scritto nel messaggio
news:behmdg$6bq$1...@apollo.home.sardone.org...


 la vpn è su, non posso accedere alla lan...indagherò
e' normale: di default se tu sei in vpn con me non puoi parlare con 
nessun altro. questo per la mia sicurezza: non voglio che qualcuno usi 
te come gw per entrare nella mia rete.
per risolvere abilita il "local lan access" sul vpn client o guarda lo 
split tunnel sul router.
un mayhem con l'ora sbagliata
-- 
  Diplomazia: dire bravo cagnetto fino a che non trovi il bastone.
  Cisco  FAQ: 
http://mayhem.oltrelinux.com/icrc
  SPP  wpage: 
http://www.spippolatori.com
  Key on 
pgp.mit.edu
 ID C7393613

 split tunnel sul router.
Sul vpnclient l'accesso alla lan è flaggato ma ignorato, ho letto da qualche
parte sul sito cisco (az è quasi al livello di quelllo di microsoft, si fa
prima a cercarci dentro usando google) che anche il router deve abilitare
l'accesso alla lan del client.
Ora non so se lo split tunnel (che hai accennato) sul server è responsabile
dell'abilitazione all'accesso allan del vpnclient....cmq, seguendo il tuo
spunto ho aggiunto una acl al client configuration group
crypto isakmp client configuration group vpngroup
key *****
pool vpnpool
acl 150    <----Specify split tunneling inclusion access-list number
access-list 150 permit ip retedelclient any
Mi pare di aver capito che con acl 150 specifico quale rete NON deve far
parte del tunnel ipsec, però ecco, se non metto nessuna acl allora dal
vpnclient vedo la rete 0.0.0.0 con la chievetta davanti, immagino che tutti
i pacchetti quindi passino dal tunnel, se metto acl 150 mi trovo nel client
la rete specificata senza chiavetta, difatti riesco dal client a pingare la
lan del client e anche internet (Local LAN access cmq rimane disabled dalle
info del vpnclient).
Però visto che la rete crittata rimane solo quella dell'ip pubblico del
router/32, non posso pingare le altre interfacce (già letta sta cosa
nell'ng)
Un'altra nota:
senza acl nel client configuration group mi ritrovo automaticamente 2 nuove
crypto map:
Crypto Map "miomap" 11 ipsec-isakmp
        Peer = IP_PUB_DEL_CLIENT
        Extended IP access list
            access-list  permit ip host IP_PUB_DEL_ROUTER host 192.168.4.12
(IP locale del peer preso dal vpnpool)
            dynamic (created from dynamic map miodynamic/10)
Crypto Map "miomap" 12 ipsec-isakmp
        Peer = IP_PUB_DEL_CLIENT
        Extended IP access list
            access-list  permit ip any host 192.168.4.12
Se invece associo acl 150 al crypto isakmp client configuration group
vpngroup, queste 2 accesslist dinamiche mi scompaiono.
Non posso rimetterle a mano perchè dovrei creare delle crypto map non
dynamiche.
Non è che puoi darci qualche altro spunto? Esiste qualche raggiro?
Grazie del tempo
Gere

 acl 150    <----Specify split tunneling inclusion access-list number
confermo anch'io!
Ho provato questa acl e in effetti qualche miglioramento c'e'!
In pratica il client ora riesce a pingare i pc della lan (sia l'ip interno
del router sia altri pc della lan) ma non e' vero il viceversa.
Il router infatti non riesce ancora a pingare il client.
Nel vpn client, tra l'altro, si nota come i dati in uscita siano presenti (i
pacchetti nelle statistiche "vanno")...mentre quelli in entrata sono fermi
inesorabilmente a zero! Evidentemente e' il router che non riesce a mandare
pacchetti sul canale giusto o con la crypto map giusta.
Sto dando un'occhiata ai vari crypto ipsec.....isakmp ecc ecc...
Appena scopro qualcosa di nuovo faccio un fischio.
Pensavo di modificare i comandi di routing ma ho solo due righe:
(1) ip route 0.0.0.0 0.0.0.0 Dialer1
(2) ip route 172.16.2.0 255.255.255.0 Tunnel0
La (2) mi serve per il tunnel ipsec...e quindi _deve_ esserci...
La (1) se non ho capito male mi dice che tutto cio' che NON va sul tunnel
ipsec lo butto su internet...quindi non so nemmeno come modificarla...dovrei
aggiungere un
ip route 192.168.1.0 255.255.255.0 Dialer1....ma mi pare compresa nella (1)
percio' totalmente inutile!
Mah...continuo nel mio dolore...
PS Ho modificato anche dialer0 a dialer1...ma non e' cambiato nulla
purtroppo...