Newsgroup: it.comp.os.linux.sys
Titolo: IPSEC e autenticazione di un "road warrior"

Buongiorno... sono ormai due settimane che mi rompo la testa con
IPSEC... ormai ho letto tutta la documentazione, ho cercato su google,
sui forum, sui gruppi... niente.
Il fatto. In azienda dove lavoro c'è un secure gateway linux debian con
freeswan che permette a dei "roadwarrior" di collegarsi con un tunnel
vpn. Detto tunnel, se eseguito dal vpnclient di un fottuto Wincaz,
funziona correttamente.
E adesso arrivo io, che per esigenze di reperibilità potrei aver bisogno
da casa di intervenire rapidamente su un server della LAN aziendale,
ovviamente passando - per ragioni di sicurezza - dal tunnel VPN (non
esistono accessi che non siano crittografati, alla rete aziendale).
Perciò, sul mio linux di casa, prendo la mia brava documentazione,
scarico il supporto ipsec per il kernel 2.4.17 che uso, patcho il
kernel, lo ricompilo (il supporto è regolarmente presente), prendo il
pacchetto di freeswan, lo compilo e lo installo.
Tutto procede bene. Ora viene la configurazione. Leggo tutta la
documentazione che posso, creo i file /etc/ipsec.secret dentro il quale
imposto la chiave pubblica (uguale a quella del server) e genero la
mia chiave segreta.
Poi creo il file /etc/ipsec.conf , come da manuali e suggerimenti vari:
config setup
        interfaces=%defaultroute
        klipsdebug=none
        plutodebug=none
        plutoload=%search
        plutostart=%search
        plutowait=no
        overridemtu=1430
conn %default
        keyingtries=3
conn tcr
        auto=add
        type=tunnel
        authby=secret
        pfs=yes
        disablearrivalcheck=no
        ######## Left: Server (TCR) #########
        leftsubnet=
10.0.2.0/24
        left=62.110.145.226
        leftnexthop=62.110.145.225
        leftid=@tcr
 
 leftid=@tcr
        ######## Right: ME (the RoadWarrior) #########
        right=%defaultroute
        rightid=@ulibarra
Ed ora la prova...
[root@ulibarra /etc]# ipsec setup start
ipsec_setup: Starting FreeS/WAN IPsec 1.98b...
ipsec_setup: Using /lib/modules/2.4.17/kernel/net/ipsec/ipsec.o
ipsec_setup: WARNING: ppp0 has route filtering turned on, KLIPS may not work
ipsec_setup:  (/proc/sys/net/ipv4/conf/ppp0/rp_filter = `1', should be 0)
[root@ulibarra /etc]# ipsec auto --up tcr
104 "tcr" #1: STATE_MAIN_I1: initiate
106 "tcr" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "tcr" #1: STATE_MAIN_I3: sent MI3, expecting MR3
010 "tcr" #1: STATE_MAIN_I3: retransmission; will wait 20s for response
003 "tcr" #1: discarding duplicate packet; already STATE_MAIN_I3
010 "tcr" #1: STATE_MAIN_I3: retransmission; will wait 40s for response
003 "tcr" #1: discarding duplicate packet; already STATE_MAIN_I3
031 "tcr" #1: max number of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication failure: no acceptable response to our first encrypted message
000 "tcr" #1: starting keying attempt 2 of at most 3, but releasing whack
Ora, il problema del filtering è ininfluente, ho provato a forzare a 0
rp_filter come indicato e a fare un ipsec setup restart e poi riattivare
la connessione, ma niente. Sempre quell'errore.
Colmo dei colmi, in azienda ho poi guardato i log dell'ipsec locale, e
ho visto che anche lui si ferma allo STATE_MAIN_I3, dicendo però
"expecting MI3".
E quindi qui c'è qualcosa di strano: riassumendo ciò che succede:
mio roadwarrior                 server azienda
--------------------------------------------------------
manda MI2, aspetta MR2          riceve MI2, risponde MR2
manda MI3, aspetta MR3          aspetta MI3 .... aspetta ... aspetta...
Domanda: qualcuno ha qualche fottutissima idea del perché il mio
roadwarrior mandi MI3 aspettando la risposta MR3, mentre il server resta
in attesa di MI3 come se non gli fosse arrivato????
Ho cercato sulla rete, ma nessuno sembra avere avuto questo problema al
mondo!!! Le sottoreti impostate come leftsubnet, leftnexthop et similia
sono corrette perché ho guardato l'ipsec.conf del server...
Un suggerimento, grazie!
-- 
Massimo Bacilieri AKA Crononauta 
mailto:
ulib...@libero.it
 ; ICQ:4005815

e la shared secret?
quella l'hai messa in ipsec.secrets?
hai verificato rightid e leftid?
hai messo klipsdebig e plutodebug su all?
hai compilato freeswan standard o quello con le estensioni di altri
protocolli?
Consiglio: non usare redhat.
Non usare il 2.4.17
Usa debian, 2.4.19, freeswan 1.99 di debian che pure essendo unstable lo uso
da quando è uscito e va da dio.
Ciao.
Max

 gli rpm del kernel patchato?
Semplice! per pura esperienza...
ho una trentina di VPN attive tutte con freeswan...
quelle con debian sono molto + manutenibili e affidabili.
Non si chiantano mai.
Max

 da quando è uscito e va da dio.
Cosa cambia debian o altro? Ho un kernel ufficiale (pacchetto tar.gz),
il compilatore gcc 2.95 (ricompilato dai tar.gz anche questo), freeswan
1.99 compilato dai tar.gz... parlare di "distribuzione" in questo caso
non vedo cosa c'entri, io di fatto non ho *nessuna* distribuzione! :-)
Adesso ti so dire con la nuova compilazione cosa succede. Grazie
dell'interessamento!


 ha scritto nel messaggio
news:slrnaug6o1.v...@ulibarra.homelinux.org...


 keyingtries=0
Questo serve per fare in modo che continui a provare all'infinito, io
invece preferisco che dopo 3 tentativi comunque lasci perdere.
Comunque ho fatto un po' di varie prove, ottengo diversi risultati (nel
senso che si blocca magari su MI1...) cambiando i parametri di
leftsubnet, left e leftnexthop, visto che di mezzo ci sono alcuni
gateway e router.
Però quella che dovrebbe funzionare è la stessa impostazione che si
trova nel left del server... che è quella che ho impostato... mahh!
