Zyxel e Vpn, ci riprovo
Eter@gene@
Mi sono procurato 2 router Zyxel 652H-31 che gestistono anche la vpn, gli ho
configurati con una guida trovata su wintricks, ma niente da fare.
Premetto che i 2 router sono configurati per funzionare con l'adsl (di Alice
in entrambi i casi).
Stessa classe di indirizzi per entrambe le sedi 192.168.1.0 e indirizzi ip
pubblici assegnati (non statici, ma č giusto per fare una prova, li ricavo
al momento)
La prima cosa evidente č questa : se inserisco i parametri della vpn e poi
clicco su "active" nel caso del pc remoto smette di funzionare internet, nel
caso del pc locale il router non da risposta per un po', naviga sempre su
internet, ma non risulta piů accessibile, neppure risponde piů al ping.
Non capisco dove sbaglio, forse proprio il concetto di base che mi manca.
Qualche aiuto ?
Grazie infinite
Jex
Macs
"Eter@gene@" ha scritto:
>
> Stessa classe di indirizzi per entrambe le sedi 192.168.1.0
Tale impostazione e' di per se' gia' una causa di problemi = dovresti
avere semmai 2 subnet distinte & non sovrapposte, e.g.:
==
* Sede 1 = Subnet 192.168.1.0/24
* Sede 2 = Subnet 192.168.2.0/24
==
proprio per evitare problemi di instradamento attivando il tunnel tra i
2 gateway.
Pertanto ti conviene reimpostare in primis l'indirizzamento IP LAN di
una delle 2 sedi -> qualora vi fosse una ragione per cui non potessi
fare una tale operazione, sarebbe utile che fornissi dettagli in merito.
In secondo luogo suggerisco di appoggiarti alle Support Notes ZyXel per
la configurazione VPN gateway-to-gateway, seguendo le indicazioni
relative alla tua situazione (cioe' entrambi i peer con IP Pubblici
dinamici, se non ho letto male) :
==
- http://global.zyxel.com/support/supportnote/p652/app/sg_sg.htm
- http://global.zyxel.com/support/supportnote/p652/app/vpn_dynamic.htm
--
|Ż \/Ż | /Ż\ /Ż__/Ż__|<|> *FAX/Mail Server : +39 - 02700426582 <|
|Ż|\/|Ż|/Ż_Ż\|(__\__ \<|> *Casella Vocale : +39 - 0230312251 <|
|_| |_/_/ \_\___|___/<|> *FAQ ITGF http://plany.fasthosting.it <|
|>- RST - Plany/MACS -<|> *FAQ GCN http://faq.news.nic.it/ ____<|
Eter@gene@
> In secondo luogo suggerisco di appoggiarti alle Support Notes ZyXel per
> la configurazione VPN gateway-to-gateway, seguendo le indicazioni
> relative alla tua situazione (cioe' entrambi i peer con IP Pubblici
Grazie sei stato gentilissimo
Jex
>
Eter@gene@
>
> Tale impostazione e' di per se' gia' una causa di problemi = dovresti
> avere semmai 2 subnet distinte & non sovrapposte, e.g.:
> ==
> * Sede 1 = Subnet 192.168.1.0/24
> * Sede 2 = Subnet 192.168.2.0/24
> ==
Ho provato a seguire il tuo consiglio, ma niente da fare.
Adesso le sedi hanno 2 subnet distinte.
Sul router locale non risultano problemi in fase di configurazione
Su quello Remoto, appena clicco su "Active" dal menů Vpn, smette di
funzionare internet.
Ci sono poi altre 2 opzioni : "Keep alive" e "NAT Traversal" che
attivandole (per prova) non producono effetti collaterali, ma onestamente
non so a cosa servano.
Al momento ho lasciato la sede remota su Keep alive.
Poi non ho chiara un'altra cosa : supponiamo entrambi i router non diano
problemi di sorta, come faccio a vedere che le due sedi sono collegate ??
Grazie ancora
Jex
Macs
"Eter@gene@" ha scritto:
>
> Adesso le sedi hanno 2 subnet distinte.
OK -> questo e' solo il primo passo = ora e' necessario configurare in
modo adeguato entrambi i router, tenendo conto che entrambi sono su
connessioni con IP Pubblico dinamico associato all'interfaccia WAN.
I link che ti avevo indicato nel messaggio precedente contengono proprio
le info dettagliate in merito.
Devi in primis registrare un account free su http://www.dyndns.org/ e
definire 2 Dynamic Dns Host su dominio dyndns.org da associare ai
router, seguendo le indicazioni su :
==
- http://global.zyxel.com/support/supportnote/p652/app/ddns.htm
Questa e' una situazione d'esempio :
Sede 1 (subnet 192.168.1.0/24) :
--------------------------------
- Service Provider = WWW.DynDNS.ORG
- Active = Yes
- Host Name = ethersede1.dyndns.org
- E-mail Address = email indicata per registrarti su www.dyndns.org
- User = username dell'account su www.dyndns.org
- Password = password associata a tale account
- Enable Wildcard = No
Sede 2 (subnet 192.168.2.0/24) :
--------------------------------
- Service Provider = WWW.DynDNS.ORG
- Active = Yes
- Host Name = ethersede2.dyndns.org
- E-mail Address = email indicata per registrarti su www.dyndns.org
- User = username dell'account su www.dyndns.org
- Password = password associata a tale account
- Enable Wildcard = No
Tali associazioni DDNS hostname/IP non sono immediate = di norma sono
richiesti 15/20 minuti per propagazione/aggiornamento DNS, per cui
prima di procedere al setup VPN verifica (tramite ping o lookup DNS) che
i nomi host ethersede1.dyndns.org e ethersede2.dyndns.org siano
associati ai rispettivi IP pubblici delle interfacce WAN dei router.
Una volta OK le associazioni DDNS, puoi procedere a configurare i menu
VPN per entrambi i router, come indicato su :
==
- http://global.zyxel.com/support/supportnote/p652/app/vpn_dynamic.htm
==
nella sezione Prestige dynamic WAN IP v.s. peer side dynamic IP .
Esempio :
************************************************************************
Sede 1 (subnet 192.168.1.0/24 - IP LAN router 192.168.1.1) / VPN - IKE :
------------------------------------------------------------------------
IPSec Setup = Active
Keep Alive = Yes
Name = EtherVPN1
IPSec Key Mode = IKE
Negotiation Mode = Main
Local Address Type = Range
IP Address Start = 192.168.1.2
End / Subnet Mask = 192.168.1.254
Remote Address Type = Range
IP Address Start = 192.168.2.2
End / Subnet Mask = 192.168.2.254
Local ID Type = IP
Content = 0.0.0.0
My IP Address = 0.0.0.0
Peer ID Type = IP
Content = 0.0.0.0
Secure Gateway = ethersede2.dyndns.org
Encapsulation = Tunnel
VPN Protocol = ESP
Pre-shared Key = scegli una chiave alfanumerica non facile (> 8 char)
VPN Setup = DES
Authentication = SHA1
************************************************************************
Sede 1 (subnet 192.168.2.0/24 - IP LAN router 192.168.2.1) / VPN - IKE :
------------------------------------------------------------------------
IPSec Setup = Active
Keep Alive = Yes
Name = EtherVPN2
IPSec Key Mode = IKE
Negotiation Mode = Main
Local Address Type = Range
IP Address Start = 192.168.2.2
End / Subnet Mask = 192.168.2.254
Remote Address Type = Range
IP Address Start = 192.168.1.2
End / Subnet Mask = 192.168.1.254
Local ID Type = IP
Content = 0.0.0.0
My IP Address = 0.0.0.0
Peer ID Type = IP
Content = 0.0.0.0
Secure Gateway = ethersede1.dyndns.org
Encapsulation = Tunnel
VPN Protocol = ESP
Pre-shared Key = stessa chiave PSK del router sede 1
VPN Setup = DES
Authentication = SHA1
************************************************************************
> Ci sono poi altre 2 opzioni : "Keep alive" e "NAT Traversal" che
> attivandole (per prova) non producono effetti collaterali, ma
> onestamente non so a cosa servano.
La prima serve per inviare periodicamente appositi pacchetti TCP Keep
Alive, che mantengano attivo il tunnel anche qualora non vi sia alcuna
attivita' di rete a livello VPN.
La seconda serve per consentire l'avvio di connessioni VPN IPSec su
protocollo ESP (Transport/Tunnel Mode) da peer connessi ad Internet
tramite NAT (della rete del provider e.g. FASTWEB o di un ulteriore
router a monte), quando non e' possibile impostare regole di inoltro
porte/protocolli.
> come faccio a vedere che le due sedi sono collegate ??
Devi verificare in primis nel VPN Summary che le regole VPN siano
attive su entrambi i router -> a quel punto effettua prove di ping tra
gli indirizzi IP LAN dei computer delle 2 sedi, ovviamente in assenza di
filtri/firewall (locali sui computer o a livello di router) che possano
bloccare i pacchetti ICMP -> per ulteriori info puoi fare riferimento
alle sezioni Trobleshooting / Log su :
==
- http://global.zyxel.com/support/supportnote/p652/app/sg_sg.htm
==
oppure al manuale in formato .PDF su http://tinyurl.com/28qnru .
Eter@gene@
"Macs" <maxs...@despammed.com> ha scritto nel messaggio
news:4612AD11...@despammed.com...
> Ciao
Macs,
per prima cosa un grazie grosso come una casa per la tua dedizione alla mia
domanda, davvero una guida dettagliatissima.
Dunque ho seguito passo passo tutti i tuoi consigli, registrato gli ip con
Dyndns ed eseguito le configurazioni.
Dopo aver fatto questo ho notato che dalla sede locale posso solo pingare il
mio Dyndns e non quello della sede remota e viceversa. Credo sia normale.
Appena terminata la configurazione del router remoto, sono anche riuscito a
vedere sotto il menù Vpn \ Monitor i dati della connessione (Name,
Encapsulation, Ip Sec Alghoritm) che evidentemente si era stabilita
correttamente.
A questo punto ho cercato di "capire" se effettivamente le due reti fossero
connesse, non sapendo bene come fare (ho letto solo Dopo dalla guida Zyxel
di provare a fare un ping) ho tentato di prendere un pc remoto con
l'assistenza remota di microsoft, a condividere qualche cartella, ma non ci
sono riuscito.
Insomma, non ho proprio capito come fare a far comunicare le due reti una
volta stabilita la vpn, e questo è un punto....
Il secondo dilemma, più grave, è che dopo qualche altra prova, ma non sui
router, nel menù Monitor è sparita la connessione, e non c'è stato più modo
di ottenerla di nuovo (magari non so Come attivarla....).
Ho notato che l'indirizzo ip della sede locale è variato, ma anche il dyndns
lo ha seguito correttamente aggiornandosi.
Questi in definitiva i risultati delle prove, al momento la connessione non
sembra + funzionare (se mai ha funzionato), ti chiedo ancora uno sforzo....
Grazie davvero
Jex
Eter@gene@
ripetendo la configurazione nel router locale, adesso ri-appare la
connessione nella schermata VPN - Sa Monitor, resta però il fatto che non
riesco a capire se sono effettivamente connesso con l'altra rete o no, i
ping ad esempio non danno risposta.
Saluti
Jex
Eter@gene@
andando a vedere sul Log, alla voce "IKE", sembrerebbe tutto ok, almeno
credo, infatti ci sono due messaggi,
Send:[HASH]
Rule [2] Tunnel built successfully
a seguito gli indirizzi ip pubblici delle due sedi....
Ma ancora non so come farle comunicare.
Saluti
Jex
Macs
"Eter@gene@" ha scritto:
>
> per prima cosa un grazie grosso come una casa per la tua dedizione
> alla mia domanda, davvero una guida dettagliatissima.
Prego ;).
> Dopo aver fatto questo ho notato che dalla sede locale posso solo
> pingare il mio Dyndns e non quello della sede remota e viceversa.
> Credo sia normale.
Dipende = e' normale se siano impostate regole di filtro o firewall per
il traffico ICMP associato all'interfaccia WAN, oppure nelle opzioni
Anti-Probing non siano attive le risposte ping sull'interfaccia WAN.
Cio' che conta in primis e' che comunque le associazioni tra i nomi host
DDNS <-> indirizzi IP siano corrette/aggiornate & che il tunnel VPN
risulti Active/UP nel SA Monitor (27.2 da accesso telnet), anche
effettuando il refresh.
A quel punto conviene verificare che non vi siano blocchi a livello
filtri/firewall per le connessioni in ingresso sull'interfaccia WAN dei
router per i servizi :
==
- IKE = UDP 500
- IPSec ESP Tunnel Mode = IP Protocol 50
> ripetendo la configurazione nel router locale, adesso ri-appare la
> connessione nella schermata VPN - Sa Monitor, resta perň il fatto che
> non riesco a capire se sono effettivamente connesso con l'altra rete
> o no, i ping ad esempio non danno risposta.
Controlla che non vi siano filtri per il traffico ICMP a livello di
router o computer della rete di destinazione -> sarebbe inoltre utile
che verificassi anche il traceroute da un computer di una sede ad uno
dell'altra = serve per capire se effettivamente le connessioni vengano
instradate sulla VPN oppure seguano il routing predefinito su Internet.
Qualora infatti non avvenisse il corretto instradamento lungo la
VPN, vedresti i pacchetti ICMP che transitano su 2/3 hop della rete del
provider prima di 'perdersi'.
Puoi eventualmente fare una prova, impostando temporaneamente dei set
di regole IPPR -> purtroppo nel tuo caso non e' possibile mantenerle in
modo definitivo, dato che entrambi i gateway sono associati ad indirizzi
IP pubblici dinamici & IPPR non consente la definizione di gateway in
formato nome-host (ma solo come indirizzo IP) :/.
Consideriamo quindi le seguenti configurazioni :
==
- LAN 1 = 192.168.1/24 - IP WAN (ZyXel A Sede 1) = A.B.C.D
- LAN 2 = 192.168.2/24 - IP WAN (ZyXel B Sede 2) = E.F.G.H
Puoi usare su ciascun ZyXel il menu 25.1 IP Routing Policy per definire
delle regole alternative di routing (in pratica 3, impostandole per TCP,
UDP e ICMP) -> questa e' p.es. una delle configurazioni base (ICMP) :
************************************************************************
Policy Set Name= LANBICMP
Active= Yes
Criteria:
IP Protocol = 1
Type of Service= Don't Care Packet length= 0
Precedence = Don't Care Len Comp= N/A
Source:
addr start= 0.0.0.0 end= N/A
port start= N/A end= N/A
Destination:
addr start= 192.168.2.2 end= 192.168.1.254
port start= N/A end= N/A
Action= Matched
Gateway addr = E.F.G.H Log= No
Type of Service= No Change
Precedence = No Change
************************************************************************
Alla fine dovresti avere i seguenti set di regole IPPR (3 per ciascun
router) :
==
* ZyXel A Sede 1 = LANBICMP - LANBTCP - LANBUDP
* ZyXel B Sede 2 = LANAICMP - LANATCP - LANAUDP
Di norma uso IPPR proprio per definire gli instradamenti sulla VPN,
anche perche' cosi' posso definire le policy di banda per la VPN ed
altri servizi in virtu' delle regole ToS/QoS -> non l'ho indicato nel
tuo caso, dato che serve almeno un gateway con IP pubblico statico in
modo da definire le regole IPPR almeno sul GW con IP dinamico.
> andando a vedere sul Log, alla voce "IKE", sembrerebbe tutto ok,
> almeno credo, infatti ci sono due messaggi,
>
> Send:[HASH]
> Rule [2] Tunnel built successfully
>
> a seguito gli indirizzi ip pubblici delle due sedi
Qualora non risultino anomalie a livello di traceroute (vedi verifica
citata sopra), lancia una serie di ping estesi (ping -t) tra un computer
della sede 1 ed un altro della sede 2 -> a quel punto verifica il
transito dei pacchetti sia nei log del firewall che in quello IPSec/IKE
(menu 27.3 da accesso telnet).
Macs
"Eter@gene@" ha scritto:
>
> per prima cosa un grazie grosso come una casa per la tua dedizione
> alla mia domanda, davvero una guida dettagliatissima.
Prego ;).
> Dopo aver fatto questo ho notato che dalla sede locale posso solo
> pingare il mio Dyndns e non quello della sede remota e viceversa.
> Credo sia normale.
Dipende = e' normale se siano impostate regole di filtro o firewall per
il traffico ICMP associato all'interfaccia WAN, oppure nelle opzioni
Anti-Probing non siano attive le risposte ping sull'interfaccia WAN.
Cio' che conta in primis e' che comunque le associazioni tra i nomi host
DDNS <-> indirizzi IP siano corrette/aggiornate & che il tunnel VPN
risulti Active/UP nel SA Monitor (27.2 da accesso telnet), anche
effettuando il refresh.
A quel punto conviene verificare che non vi siano blocchi a livello
filtri/firewall per le connessioni in ingresso sull'interfaccia WAN dei
router per i servizi :
==
- IKE = UDP 500
- IPSec ESP Tunnel Mode = IP Protocol 50
> ripetendo la configurazione nel router locale, adesso ri-appare la
> connessione nella schermata VPN - Sa Monitor, resta perň il fatto che
> non riesco a capire se sono effettivamente connesso con l'altra rete
> o no, i ping ad esempio non danno risposta.
Controlla che non vi siano filtri per il traffico ICMP a livello di
router o computer della rete di destinazione -> sarebbe inoltre utile
che verificassi anche il traceroute da un computer di una sede ad uno
dell'altra = serve per capire se effettivamente le connessioni vengano
instradate sulla VPN oppure seguano il routing predefinito su Internet.
Qualora infatti non avvenisse il corretto instradamento lungo la
VPN, vedresti i pacchetti ICMP che transitano su 2/3 hop della rete del
provider prima di 'perdersi'.
Puoi eventualmente fare una prova, impostando temporaneamente dei set
di regole IPPR -> purtroppo nel tuo caso non e' possibile mantenerle in
modo definitivo, dato che entrambi i gateway sono associati ad indirizzi
IP pubblici dinamici & IPPR non consente la definizione di gateway in
formato nome-host (ma solo come indirizzo IP) :/.
Consideriamo quindi le seguenti configurazioni :
==
- LAN 1 = 192.168.1/24 - IP WAN (ZyXel A Sede 1) = A.B.C.D
- LAN 2 = 192.168.2/24 - IP WAN (ZyXel B Sede 2) = E.F.G.H
Puoi usare su ciascun ZyXel il menu 25.1 IP Routing Policy per definire
delle regole alternative di routing (in pratica 3, impostandole per TCP,
UDP e ICMP) -> questa e' p.es. una delle configurazioni base (ICMP) per
il router della sede 1 :
************************************************************************
Policy Set Name= LANBICMP
Active= Yes
Criteria:
IP Protocol = 1
Type of Service= Don't Care Packet length= 0
Precedence = Don't Care Len Comp= N/A
Source:
addr start= 0.0.0.0 end= N/A
port start= N/A end= N/A
Destination:
addr start= 192.168.2.2 end= 192.168.2.254
port start= N/A end= N/A
Action= Matched
Gateway addr = E.F.G.H Log= No
Type of Service= No Change
Precedence = No Change
************************************************************************
Alla fine dovresti avere i seguenti set di regole IPPR (3 per ciascun
router) :
==
* ZyXel A Sede 1 = LANBICMP - LANBTCP - LANBUDP
* ZyXel B Sede 2 = LANAICMP - LANATCP - LANAUDP
Di norma uso IPPR proprio per definire gli instradamenti sulla VPN,
anche perche' cosi' posso definire le policy di banda per la VPN ed
altri servizi in virtu' delle regole ToS/QoS -> non l'ho indicato nel
tuo caso, dato che serve almeno un gateway con IP pubblico statico in
modo da definire le regole IPPR almeno sul GW con IP dinamico.
> andando a vedere sul Log, alla voce "IKE", sembrerebbe tutto ok,
> almeno credo, infatti ci sono due messaggi,
>
> Send:[HASH]
> Rule [2] Tunnel built successfully
>
> a seguito gli indirizzi ip pubblici delle due sedi
Qualora non risultino anomalie a livello di traceroute (vedi verifica
citata sopra), lancia una serie di ping estesi (ping -t) tra un computer
della sede 1 ed un altro della sede 2 -> a quel punto verifica il
transito dei pacchetti sia nei log del firewall che in quello IPSec/IKE
(menu 27.3 da accesso telnet).
--
Eter@gene@
> "Eter@gene@" ha scritto:
>>
>> per prima cosa un grazie grosso come una casa per la tua dedizione
>> alla mia domanda, davvero una guida dettagliatissima.
>
> Prego ;).
Ancora sviluppi, ci sto perdendo la ragione.
Allora,
riepilogando la situazione, la Vpn si attiva, ma non riesco a pingare le
risorse remote, o a vederle cmq.
Per caso ho provato a pingare anche una risorsa locale e ho scoperto che non
funzionava, allora, un bel reset del router, riconfiguro il tutto, e a
questo punto pingo sia in locale che remoto !
Contento come una Pasqua (ci sta proprio tutto), faccio esperimenti con
desktop remoto e varie, tutto benone. Tempo 1h, vado a ricontrollare la vpn,
ma č giů.
Da quel momento, non c'č stato piů modo di rialzare la vpn, addirittura ho
resettato entrambi i router, riconfigurati, provato di tutto, ma adesso non
arrivo piů nemmeno al punto di partenza, buio totale....
Eseguendo dei ping -t sul remoto o viceversa ecco cosa viene fuori dal log :
1.Rule [1] Sending IKE request Send Main Mode request to [87.3.......
2.Send:[SA][VID] 87........
3. !! IKE Negotiation is in process 87......
4.!! IKE Packet Retransmit 87.......
5.!! IKE Packet Retransmit 87.......
e cosě a ripetere fino a quando dura il ping.
A volte appare anche questo messaggio prima dei precedenti
Cannot resolve Secure Gateway Addr for rule [1]
Di seguito a questo, se provo a pingare la sede remota, sia via nome dyndns
che ip ottengo regolare risposta.
Questi i fatti, al momento, come detto, non funziona assolutamente piů
niente.....
Help
Help
Help
grazie
Jex
Macs
"Eter@gene@" ha scritto:
>
> Eseguendo dei ping -t sul remoto o viceversa ecco cosa viene fuori dal
> log :
[...]
> 4.!! IKE Packet Retransmit 87.......
[...]
> Cannot resolve Secure Gateway Addr for rule [1]
Il log ti indica che lo ZyXel non riesce a risalire tramite risoluzione
DNS all'indirizzo IP del Secure Gateway -> non riuscendo quindi ad
instradarvi il pacchetto IKE, comincia di conseguenza la serie delle
ritrasmissioni.
Verifica in primis di star usando effettivamente su entrambi i router
P652H-31 il firmware 3.40(IU.4)C0 = nelle versioni precedenti alla
3.40(IU.4)b2 e' presente un bug relativo alla risoluzione DNS del
Secure Gateway quando viene indicato come nome-host e non come IP.
Cio' comporta dei problemi nelle VPN tra peer dinamici in caso di
variazione dell'IP associato al nome del Secure Gateway.
Qualora tu debba procedere con l'aggiornamento firmware segnati e
salvati le configurazioni prima di procedere (in modo da ripristinarle).
Fatto tutto cio', procedi in questo modo :
==
1. Disabilita in entrambe le regole VPN l'opzione KeepAlive.
2. Reimposta entrambe le regole VPN, definendo gli intervalli non piu'
come Range, bensi' come Subnet = 192.168.1.0/255.255.255.0 per la
sede 1 e 192.168.2.0/255.255.255.0 per la sede 2.
3. Accedi all'interfaccia avanzata CI (Command Interpreter Mode) di uno
dei 2 router & stabilisci la connessione VPN, digitando :
ipsec dial 1
4. Dall'interfaccia CI di entrambi i router imposta l'autoaggiornamento
dei timer per le connessioni VPN, digitando :
ipsec timer chk_my_ip 10
ipsec timer chk_conn 2
ipsec timer update_peer 5
5. Dall'interfaccia CI del router che avvia la connessione VPN verifica
il runtime phase 1/2, digitando :
ipsec show_runtime sa
6. Avvia il ping continuato (senza interruzione) da un computer della
sede del router da cui effettui la connessione VPN verso un computer
della sede remota.
7. Dall'interfaccia CI del router remoto che risponde alla connessione
VPN verifica la ricezione delle richieste, digitando :
ipsec show_runtime spd
Fammi sapere l'esito = se tali impostazioni risolvono i problemi di
disconnessione, potro' indicarti come configurarle adeguatamente su
entrambi i router in modo permanente.
Macs
Macs ha scritto:
>
> Fammi sapere l'esito = se tali impostazioni risolvono i problemi di
> disconnessione, potro' indicarti come configurarle adeguatamente su
> entrambi i router in modo permanente.
Aggiungo una nota = qualora fossero stati impostati temporaneamente [1]
set di regole IPPR nel corso delle prove, andrebbe verificato che gli IP
indicati come Gateway Address fossero quelli assegnati dinamicamente
alle interfacce WAN dei router.
In caso contrario i pacchetti non verrebbero correttamente instradati,
per cui converrebbe disabilitare tali set oppure aggiornarli giusto per
concludere le verifiche.
[1] L'impostazione di regole IPPR nel caso di entrambi i peer dinamici
NON puo essere infatti definitiva, proprio per la variabilita'
degli indirizzi IP dei Secure Gateway.
Eter@gene@
>>
>> Fammi sapere l'esito = se tali impostazioni risolvono i problemi di
>> disconnessione, potro' indicarti come configurarle adeguatamente su
>> entrambi i router in modo permanente.
>
Grazie ancora per la pazienza.
Ho provato scrupolosamente tutto quello che mi hai indicato ma niente da
fare.
Effettivamente credo che il buio totale (ovvero neppure la vpn va su) č nato
dopo l'aggiornamento del firmware, che perň ho controllato essere quello da
te indicato su entrambe le sedi, paradossalmente sembrava andare prima
dell'aggiornamento.....
Il comando ipsec dial 1 mi rende un "Tunnel built failed!"
e qui mi sa che mi fermo.
Poi provo il ping ripetuto e il comando ipsec show_runtime sa esce un
messaggio e questo log (lascio gli ip tanto sono dinamici)
Enter Menu Selection Number: 8
Copyright (c) 1994 - 2003 ZyXEL Communications Corp.
ras> ipsec show_runtime sa
Runtime SA status:
Phase 1 IKE SA:
SA<8075a3c4> Security Gw IP Addr: 87.11.204.244 MyIP Addr: 87.18.205.53
condition: <Larval>(0), state= (1), life_type:SEC, dur:3600, remained:3550
Remote IP: 192.168.1.2/255.255.255.0, ID Type:4, Protocol:0
Local IP: 192.168.0.2/255.255.255.0, ID Type: 4, Protocol: 0
init/resp: INITIATOR, saIndex = 1,phase2_pfs = 0
phase2_num = 0, phase2_zero_counter = 1
my_cookie<0xCD9BF0624490FC0E> his_cookie<0x0000000000000000>
No phase 2 IPSec SA exist
Active SA pair = 0
ras>
spero ci siano ancora speranze.....
Grazie
Jex
Macs
"Eter@gene@" ha scritto:
>
> Grazie ancora per la pazienza.
Prego -> purtroppo lo scenario ZyXel VPN con solo peer dinamici e' il
piu' 'noioso' qualora si voglia instaurare una connessione gateway to
gateway, dato che non si dispone di un responder associato ad un IP
pubblico statico.
Per questo motivo sono possibili diverse configurazioni indicate proprio
da ZyXel per tale situazione, vedasi il confronto Support-Notes tra i
vari siti internazionali ZyXel (Global / Studerus CH / ZyXelTech).
All'utente resta cosi' l'ingrato compito di testare/individuare quella
che funziona meglio per il suo caso :/.
> Effettivamente credo che il buio totale (ovvero neppure la vpn va su)
> č nato dopo l'aggiornamento del firmware, che perň ho controllato
> essere quello da te indicato su entrambe le sedi, paradossalmente
> sembrava andare prima dell'aggiornamento.....
Infatti indicavo l'aggiornamento solo qualora avessi rilevato versioni
firmware precedenti alla 3.40(IU.4)b2 (in virtu' del bug con i secure
gateway indicati come nome-host) -> in ogni caso il riaggiornamento al
medesimo firmware non comporta problemi, a patto ovviamente che siano
presenti ancora le medesime impostazioni di configurazione che avevi in
precedenza.
> Poi provo il ping ripetuto e il comando ipsec show_runtime sa esce un
> messaggio e questo log (lascio gli ip tanto sono dinamici)
[...]
> my_cookie<0xCD9BF0624490FC0E> his_cookie<0x0000000000000000>
>
> No phase 2 IPSec SA exist
Questo indica un problema nel passaggio Phase1/Phase2 lato responder,
visto che lato initiator l'apertura del tunnel pare corretta.
Ripartiamo quindi da zero -> cio' significa in primis :
==
1. Cancellare le regole VPN da entrambi i router
2. Cancellare eventuali set IPPR creati temporaneamente
3. Consentire lato WAN le connessioni in ingresso su UDP 500 (IKE)
4. Consentire lato WAN l'IP Protocol 50 (IPSec ESP Tunnel Mode)
A quel punto si ricreano le regole VPN -> mi basero' sulle subnet LAN
che risultano dal tuo log per riportarti tutte le configurazioni
complete (comprese opzioni Advanced VPN), per cui tu dovrai solo
impostare i reali dati di nomi-host e chiave PSK :
==
* Sede 1 192.168.0.0/24 - GW LAN 192.168.0.1 - WAN ethersede1.dyndns.org
* Sede 2 192.168.1.0/24 - GW LAN 192.168.1.1 - WAN ethersede2.dyndns.org
************************************************************************
Sede 1 (subnet 192.168.0.0/24 - IP LAN router 192.168.0.1) / VPN - IKE :
------------------------------------------------------------------------
IPSec Setup = Active
Keep Alive = NO
Name = EtherVPN1
IPSec Key Mode = IKE
Negotiation Mode = Main
Local Address Type = Subnet
IP Address Start = 192.168.0.0
End / Subnet Mask = 255.255.255.0
Remote Address Type = Subnet
IP Address Start = 192.168.1.0
End / Subnet Mask = 255.255.255.0
Local ID Type = DNS
Content = ethersede1.dyndns.org
My IP Address = 0.0.0.0
Peer ID Type = DNS
Content = ethersede2.dyndns.org
Secure Gateway = ethersede2.dyndns.org
Encapsulation = Tunnel
VPN Protocol = ESP
Pre-shared Key = scegli una chiave alfanumerica non facile (8 caratteri)
VPN Setup = DES
Authentication = SHA1
>> Advanced
-----------
Protocol = 0
Enable Replay = NO
Local Start Port = 0 End 0
RemoteStart Port = 0 End 0
Negotiation Mode = Main
Pre-Shared Key = chiave PSK indicata prima
Encryption = DES
Authentication = MD5
SA Life Time = 28800
Key Group = DH1
Active Protocol = ESP
Encrption = DES
Authentication = SHA1
SA Life Time = 28800
Encapsulation = Tunnel
PFS = None
************************************************************************
Sede 2 (subnet 192.168.1.0/24 - IP LAN router 192.168.1.1) / VPN - IKE :
------------------------------------------------------------------------
IPSec Setup = Active
Keep Alive = NO
Name = EtherVPN2
IPSec Key Mode = IKE
Negotiation Mode = Main
Local Address Type = Subnet
IP Address Start = 192.168.1.0
End / Subnet Mask = 255.255.255.0
Remote Address Type = Subnet
IP Address Start = 192.168.0.0
End / Subnet Mask = 255.255.255.0
Local ID Type = DNS
Content = ethersede2.dyndns.org
My IP Address = 0.0.0.0
Peer ID Type = DNS
Content = ethersede1.dyndns.org
Secure Gateway = ethersede1.dyndns.org
Encapsulation = Tunnel
VPN Protocol = ESP
Pre-shared Key = stessa chiave PSK del router sede 1
VPN Setup = DES
Authentication = SHA1
>> Advanced
-----------
Protocol = 0
Enable Replay = NO
Local Start Port = 0 End 0
RemoteStart Port = 0 End 0
Negotiation Mode = Main
Pre-Shared Key = stessa chiave PSK del router sede 1
Encryption = DES
Authentication = MD5
SA Life Time = 28800
Key Group = DH1
Active Protocol = ESP
Encrption = DES
Authentication = SHA1
SA Life Time = 28800
Encapsulation = Tunnel
PFS = None
************************************************************************
Verifica che le regole siano inserite/memorizzate sui router -> fatto
questo, dall'interfaccia CI di entrambi i router reimposta i timer per
le connessioni VPN, digitando :
ipsec timer chk_my_ip 3600
ipsec timer chk_conn 60
ipsec timer update_peer 60
Infine lancia il ping esteso/continuato da un computer della sede 1
verso uno remoto della sede 2 -> inizia a monitorare lo stato della
connessione VPN dai log e dall'interfaccia CI dopo 5 minuti (mantenendo
sempre il ping in corso).
In assenza di filtri o impostazioni firewall su router/computer che
blocchino ICMP dovresti iniziare a vedere le risposte ai pacchetti
inviati -> sempre ovviamente che Phase1+Phase2 vadano a buon fine.
Nota a margine :
----------------
Qualora - nonostante le nuove configurazioni - avessi ancora problemi
Phase1/Phase2, potresti eventualmente reimpostare in entrambe le regole
VPN il Negotiation Mode ad Aggressive.
Tuttavia, non raccomanderei una tale impostazione per un ambiente di
produzione = in cambio dei vantaggi di snellimento/velocita' della
negoziazione comporta infatti una diminuzione della protezione delle
connessioni transitanti nel tunnel.
Eter@gene@
stavolta è andata !!!
Rileggendo tutti i post da capo, mi sono reso conto che la differenza sta in
questo punto :
>
> Local ID Type = DNS
> Content = ethersede1.dyndns.org
> My IP Address = 0.0.0.0
> Peer ID Type = DNS
> Content = ethersede2.dyndns.org
> Secure Gateway = ethersede2.dyndns.org
> Encapsulation = Tunnel
>
mentre io avevo sempre configurato in questo modo le due sedi
Local ID Type = IP
Content = 0.0.0.0
My IP Address = 0.0.0.0
Peer ID Type = IP
Content = 0.0.0.0
Secure Gateway = ethersede2.dyndns.org
Encapsulation = Tunnel
Infatti torna il motivo per cui il router non trovava il secure gateway in
quanto non poteva risolvere il nome del dyndns da solo, con il settaggio che
mi hai indicato funziona tutto e benone.
Che dire, un grazie grande come una casa per la tua gentilezza disponibilità
e competenza.
Spero che questo thread tormentato possa servire anche ad altri con questi
problemi.
Un saluto
Jex
Macs
"Eter@gene@" ha scritto:
>
> stavolta č andata !!!
Optime ;).
> Rileggendo tutti i post da capo, mi sono reso conto che la differenza
> sta in questo punto
[...]
> mentre io avevo sempre configurato in questo modo le due sedi
Infatti la seconda e' una delle 2 modalita' preferenziali (e nemmeno la
prima) secondo le indicazioni ufficiali ZyXel per le VPN GW-to-GW con
peer dinamici (serie P65x/P66x e ZyWall) -> la prima viene invece
accennata solo nella documentazione Studerus CH (supporto ZyXel per
utenti svizzeri) & limitatamente agli ZyWall.
Non e' indicata ufficialmente in modo esteso, poiche' porta a quattro
le risoluzioni DNS complessive dei peer (2 per ciascuno) -> puo quindi
causare problemi di instaurazione della VPN in caso di rinnovo degli IP
& mancato aggiornamento D-DNS.
Per questa ragione ZyXel indica di ridurre al minimo tali risoluzioni,
restando ad 1 complessiva (secure gateway solo lato peer initiator) o al
massimo a 2 (come nella prima configurazione che ti avevo riportato).
> Che dire, un grazie grande come una casa per la tua gentilezza
> disponibilitŕ e competenza.
> Spero che questo thread tormentato possa servire anche ad altri con
> questi problemi.
Prego ;) -> me lo auguro anch'io, considerando che da ieri sera vi ho
rediretto gia' 2 persone da un topic analogo su it.comp.reti.ip-admin .