www.zeroshell.net

[atavachron]

Salve, siccome mi sono seccato ad utilizzare ottomila aggeggi diversi per fare ognuno una cosa differente, come avevo già evidenziato in un altro post, in ZeroShell manca una cosa che per tutti i sistemisti del mondo si da per scontato: VPN LAN-to-LAN in IPSEC. Uno standard punto e basta.
Sicuro di fare cosa gradita a qualcuno, con l’augurio che qualcuno migliori quanto fatto; per ultimo invito Fulvio ad implementare nei menu quest’altra feature prossimamente.

Scenario in cui ZeroShell non è direttamente esposto, ma dietro a dei router.

LanSedeA/24
|
| ETH00 IpPrivatoLanSedeA
ZeroShell
| ETH01 IpPrivato2SedeA
|
| IpPrivato1SedeA
Router Adsl
| IpPubblicoSedeA
|
Internet
|
| IpPubblicoSedeB
Router Adsl
| IpPrivato1SedeB
|
| ETH01 IpPrivato2SedeB
ZeroShell
| ETH00 IpPrivatoLanSedeB
|
LanSedeB/24

Questo non è un trattato, e non risponde a domande tipo “Perché esisto?�. Tralascio dunque tutta la trafila su come si entra in ssh su ZS, perchè /Database?? “FULVIOOOOOOOOO!!� o ancora che cos’e’ IKE, phase1 e phase2 o SHA1, no meglio 3DES etc.etc… protocollo IP 50 e 51, porte 500 udp e 4500udp etc.etc.etc. Ma cercherò comunque di non essere noioso.
Ricordo inoltre che IPSEC Passthrough = IPSec NAT-T = NAT Traversal; dunque in queste condizioni il lato esterno del tunnel non è l’indirizzo pubblico ma quello esposto verso il router: e cioè rispettivamente (IpPrivato2SedeA) e (IpPrivato2SedeB).

Abbiamo già catalogato tutti gli indirizzi e le classi dello schema sopra riportato?

Bene possiamo partire.

Sede A

Creare una directory in /Database/etc/racoon

Creare un file pskey.conf contenente la chiave condivisa PSK, con la sintassi

IpPubblicoSedeB : chiavecondivisadaconservareenondivulgaretantoprimaopoilabucanocomunque

Creare un file racoon.conf contenente la seguente configurazione

path pre_shared_key "/Database/etc/racoon/pskey.conf";
listen {
isakmp IpPrivato2SedeA [500];
isakmp_natt IpPrivato2SedeA [4500];
}

remote IpPubblicoSedeB {
exchange_mode aggressive,main;
my_identifier address IpPrivato2SedeA;
initial_contact off;
nat_traversal on;
proposal {
encryption_algorithm 3des;
hash_algorithm md5;
authentication_method pre_shared_key;
dh_group 2;
}
}

sainfo address LanSedeA/24 any address LanSedeB/24 any
{
pfs_group 2;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
lifetime time 28800 sec;
}

Bene ora creiamo l’ultimo file sempre in /Database/etc/racoon/setkey.conf

flush;
spdflush;
spdadd LanSedeB/24 LanSedeA/24 any -P in ipsec esp/tunnel/IpPubblicoSedeB -IpPrivato2SedeA/require;
spdadd LanSedeA/24 LanSedeB/24 any -P out ipsec esp/tunnel/IpPrivato2SedeA-IpPubblicoSedeB/require;

E per ultimo aggiungiamo in Startup/Cron sezione PostBoot:

# Startup Script
setkey -f /Database/etc/racoon/setkey.conf
route add -net LanSedeB/24 gw IpPrivatoLanSedeA
racoon -f /Database/etc/racoon/racoon.conf


Sede B

Creare una directory in /Database/etc/racoon

Creare un file pskey.conf contenente la chiave condivisa PSK, con la sintassi:

IpPubblicoSedeA : chiavecondivisadaconservareenondivulgaretantoprimaopoilabucanocomunque

Creare un file racoon.conf contenente la seguente configurazione:

path pre_shared_key "/Database/etc/racoon/pskey.conf";
listen {
isakmp IpPrivato2SedeB [500];
isakmp_natt IpPrivato2SedeB [4500];
}

remote IpPubblicoSedeA {
exchange_mode aggressive,main;
my_identifier address IpPrivato2SedeB;
initial_contact off;
nat_traversal on;
proposal {
encryption_algorithm 3des;
hash_algorithm md5;
authentication_method pre_shared_key;
dh_group 2;
}
}

sainfo address LanSedeB/24 any address LanSedeA/24 any
{
pfs_group 2;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
lifetime time 28800 sec;
}

Bene ora creiamo l’ultimo file sempre in /Database/etc/racoon/setkey.conf

flush;
spdflush;
spdadd LanSedeA/24 LanSedeB/24 any -P in ipsec esp/tunnel/IpPubblicoSedeA -IpPrivato2SedeB/require;
spdadd LanSedeB/24 LanSedeA/24 any -P out ipsec esp/tunnel/IpPrivato2SedeB-IpPubblicoSedeA/require;

E per ultimo aggiungiamo in Startup/Cron sezione PostBoot:

# Startup Script
setkey -f /Database/etc/racoon/setkey.conf
route add -net LanSedeA/24 gw IpPrivatoLanSedeB
racoon -f /Database/etc/racoon/racoon.conf

Riavviamo ZS in tutte e due le sedi…..et voitla non funziona un tubo ;-)...scherzo.. provate a pingare agli estremi del tunnel, molto probabilmente funzionerà.

Osservazioni:
- Assicurarsi di aprire le porte dei router udp 500 e udp 4500, virtual server, source nat, IPSEC Passthrough, chiamatelo come volete ma quelle due porte devono puntare su l’ip esterno di ZeroShell .
- Assicurarsi che il file /Database/etc/racoon/pskey.conf abbia i permessi 600 dunque un bel chmod 600 /Database/etc/racoon/pskey.conf, perché altrimenti il demone racoon inizia a fare casini.
- Invece di riavviare potete lanciare manualmente i comandi che avete copiato in Startup/Cron/PostBoot ed aggiungere il� –F� al demone racoon –F –f /Database/etc/racoon/racoon.conf cosi’ partirà non in versione demone e dunque vi mostrera’ tutto quello che fa. Se aggiungete pure una “–d� vi fa vedere piu’ roba… debug.
- Ultima osservazione: se avete copiato l’intero documento con un editor decente ed avete raccolto tutti i dati detti all’inizio facendo un bel trova e sostituisci in tutto il documento per ogni parametro, vi troverete le configurazioni pronte all’uso !!! wow!!!
- Ultimissima osservazione e domanda che qualcuno si sarà fatto: Perche’ non utilizzavi OpenVPN che ti sbrigavi prima??? Risposta… perché al posto di uno dei due ZeroShell ho un Cisco, ed ho provato pure a sostituire sulla SEDE B il Cisco con IpCop sia la 1.4.21 che con la “BETA2�, e tutto ha funzionato a dovere. Deduco dunque che Fulvio sulla prossima release sistemerà la parte di integrazione di L2TP e farà in modo che i parametri di collegamento possano avvenire agilmente su interfaccia WEB… altrimenti che ZeroShell e’ ???

Adesso passiamo alla spiegazione estremamente concisa e lasciata intenzionalmente alla fine:
Il file /Database/etc/racoon/pskey.conf contiene le Pre shared key o PSK cioe’ il riferimento IPPubblico : chiavecondivisa rispettivamente per le sedi con cui ci si deve collegare.
Il file /Database/etc/racoon/racoon.conf contiene le direttive IKE per il collegamento ed in particolare:
listen = direttiva per mettere in ascolto il demone solo su un ip specifico, senza questa direttiva si metterebbe in ascolto su tutte le interfacce che troverebbe nel sistema.
Isakmp e isakmp_natt sono le porte standard con cui il demone lavora, ma anche qualsiasi sistema IPSEC di questo pianeta !!!
Remote ippubblico = direttiva che specifica la fase1 di IKE che contiene l’indirizzo a cui ci vogliamo collegare ed i parametri della fase1 con la specifica nat_traversal che ci permette di attraversare un router/firewall.
my_identifier = Ho utilizzato “address� perché in possesso di IP pubblici statici, ma si potrebbe utilizzare “fdqn� per gli IP dinamici registrati a qualche servizio tipo dyndns.org.
Proposal = parametri di interscambio chiavi e tipo di algoritmo condiviso. Ovviamente esistono molti tipi di algoritmi anche piu’ solidi, ma quelli utilizzati sono di gran lunga i piu’ compatibili che io abbia provato.
sainfo = parametri fase2 IKE e relativi algoritmi condivisi di interscambio o compressione pacchetto.
Il file /Database/etc/racoon/setkey.conf contiene le policy di ingresso ed uscita del tunnel; in poche parole se non gli diciamo quale traffico incanalare nel tunnel come fa a sapere quale pacchetti deve incanalare e quali no?

Infine chiedo umilmente di migliorare e di testare, aggiungere, eliminare, criticare o imprecare pubblicamente su questo piccolo contributo.

Vista l’ora vado a dormire.
_________________
Munnu ha statu, je munnu resta.

[lupinnicola]

Complimenti per il lavora effettuato nel caso


192.168.100.0/24
|
| ETH00 192.168.100.100
ZeroShell
| ETH01 xx.xx.xx.x1
|
| xx.xx.xx.xx
Router Adsl
|
|
Internet
|
|
Router Adsl
| yy.yy.yy.yy
|
| ETH0yy.yy.yy.y1
ZeroShell
| ETH00 192.168.170.100
|
192.168.170.0/24

Solitamente si punta l'indirizzo ip pubblico dell'altro gateway come avviene la configurazione?

[atavachron]

[marte]

Ciao atavachron,
prima di tutto, complimenti!! ho trovato il tuo post molto utile e
interessante, inoltre forse è la mia unica ancora di salvezza.. ti spiego: devo unire con vpn (Lan-to-Lan) due reti distanti.

Una esiste già ed è ben consolidata; è configurata con un firewall Monowall
con configurazione complessa: 4 schede di rete, DMZ, MPLS di terzi integrate e
chi più ne ha più ne metta.. insomma è intoccabile!

L'altra, non esiste. E' da creare ex novo..il problema è che non posso attivare contratti xdsl, perchè la location dell'ufficio è temporanea! e qui nasce l'idea di Zeroshell.. utilizzarlo sia come firewall, gateway, dhcp etc, ma soprattutto come router HSDPA! Non ho potuto utilizzare OpenVpn xchè non supportato da Monowall e quindi sto provando ad utilizzare IpSec in Zeroshell..

Questa è la situazione:

LanSedeA/24
|
| ETH00 IpPrivatoLanSedeA
ZeroShell (Router UMTS/HSDPA)
| ModemUSB IpPubblicoSedeA (IP con DynDns.org)
|
Internet
|
| IpPubblicoSedeB
Router Adsl di Fastweb
| IpPrivato1SedeB
|
| ETH01 IpPrivato2SedeB
Monowall
| ETH00 IpPrivatoLanSedeB
|
LanSedeB/24

La domanda è:

Come riporto la tua configurazione nella mia particolare situazione???

Come configuro il file racoon.conf ?? alla voce my_identifier(LanSedeA)devo usare la sintassi FDQN ed inserire il mio dominio appositamente creato con dyndns.org??

E soprattutto.. come si configura il file setkey.conf? avendo un indirizzo
pubblico-Statico da una parte ed un dominio FDQN dall'altra?

buona giornata e grazie mille..

[atavachron]

Risposta.
Prima di tutto, la configurazione l'ho creata circa sei mesi fa, presso un mio cliente, dunque ci vado a "memoria", in quanto non ho in questo momento i mezzi per simularne un'altra !!!

Secondo di tutto, ti consiglio di farti le prove con gli IP e poi man mano sostituiscili in fqdn. Se non vuoi fare uso, nel breve termine, di anfetamine per affrontare lo stress !!!

Terzo di tutto, non ti preoccupare, alla fine funzionerà !!!

Dunque, cerco di darti delle dritte.


racoon.conf
-----------------------------
Credo che per quanto riguarda il il lato rete statica sede/B devi utilizzare nella fase 1, e dunque in remote xxx la direttiva
peers_identifier fqdn "host.dominio";
che specifica come si dovrebbe presentare il remoto.
Ma questo è un problema di monowall che dovrebbe avere le carte in regola per crearla opportunamente !!!

Mentre nel lato sede/A dinamico devi mettere sempre nella stessa direttiva remote yyy
my_identifier fqdn host.dominio;
come ti presenti all'altro capo.

e credo che la cosa dovrebbe andare.


setkey.conf
------------------------------------
sempre nello stesso modo, sostituisci IpPubblicoSedeB con host.dominio

Per ultimo ricordati il file pskey.txt, devi dichiarare l'host.dominio e la relativa chiave.... ma questo è un problema di m0n0wall.

Facci sapere.
Mi dispiace, per ora, non poterti aiutare più di tanto, ma come ti dicevo prima non posso simularle.
_________________
Munnu ha statu, je munnu resta.

[marte]

Ti ringrazio x la risposta... davvero gentilissimo!!!

Mi metto subito al lavoro .. vi farò sapere al più presto...

Sarebbe bello postare la soluzione come esempio di configurazione TIPO.. su Google non ho trovato altre impostazioni di questo genere..

Buona giornata.

[cyberman]

Anche io ringrazio "atavachron" per le istruzioni che ho trovato molto utili.

Nelle istruzioni c'è un errore/distrazione.
Nel file pskey.conf l'IP e la password NON vanno separate da ":" ma soltanto da uno spazio.

Inoltre ho trovato utilissimo il comando "man racoon.com" che mostra il significato di ogni comando inseribile nel file di configurazione.

Io sono nella situazione di un router cisco e uno ZS tutti e due con IP pubblici sulle rispettive interfaccie esterne ETH01.

Il mio problema è che la VPN si attiva correttamente ma il traffico da ZS verso la LAN remota NON passa.

Passa invece il traffico dalla LAN remota verso la LAN dietro ZS.

PERO' !!!!
Se disabilito il NAT sull'interfaccia esterna di ZS allora tutto funziona perfettamente ma ovviamente la LAN dietro ZS non naviga.

C'è qualcuno che mi può dare una mano ?

[cyberman]

Mi rispondo da solo:
Ho risolto aggiungendo questa regola di routing.
Praticamente in uscita dalla LAN locale è necessario ACCTTARE i pacchetti destinati alla rete remota prima che vengano nattati dal firewall.

iptables -t nat -I POSTROUTING -o ETH01 -d ipreteremota/24 -j ACCEPT

[picov]

Sperando di evitare agli altri le svariate ore che ho perso per diagnosticare il problema di collegamento di questo tipo di VPN, vi riporto una precisazione importante.
C'è un errore nel formato del file con le chiavi precondivise che viene indicato nel post: