Newsgroup: it.comp.reti.locali
Titolo: VPN L2TP Zyxel dietro NAT

Ciao a tutti
 
Sui router Zyxel (USG) ho sempre configurato senza problemi la VPN SSL 
da usarsi col suo client SecuExtender, e non ho avuto problemi.
Ora ho necessità di configurare una L2TP/IpSec da un paio di clienti: 
dal primo, che ha il router affacciato direttamente su IP pubblico, è 
andato tutto liscio, mentre dall'altro, che è dietro NAT (ma con ip WAN 
configurato in DMZ sul modem del gestore) non c'è verso di farla 
andare. SSL sì, L2TP no.
Qualcuno di voi è riuscito nell'impresa su uno di questi apparati?


prova ad abilitare il nat traversal.
ovviamente do per scontato che tutte le porte passino correttamente...
 
-- 
MirkoB.   
ne...@bsi-net.it
 
Motoretta BMW R1200R Lightgrey
 
L'indirizzo ema@il non è da considerarsi pubblico,
ma utilizzabile solo per temi inerenti il NG corrente

 ovviamente do per scontato che tutte le porte passino correttamente...
 
Le porte passano, perché sul log dello Zyxel vedo l'evento per la porta 
1701, solo che, nonostante sia attiva la regola "dall'esterno verso 
l'IP WAN per i servizi indicati (tra cui la suddetta porta), allow", è 
un evento di blocco.
Ho provato ad abilitare il NAT traversal us tutte le regole coinvolte, 
ma senza risultato


sono diversi anni che per fortuna non metto mano su zywall quindi
potrei dire anche una cagata, ma perchè hai una regola "esterno to
wan"? non dovresti avere qualcosa del tipo "vpn to lan"? o al limite
entrambe...


entrambe...
 
Su quello ha ragione, la regola dall'esterno alla wan ci vuole.
 
 
Poi, una volta aperto il tunnel, entrano in gioco la regole vpn-to-lan
e lan-to-vpn.
 
Questo tunnel viene stabilito?
 
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

 entrambe...
 
Ci sono anche quelle, create automaticamente dal wizard che configura 
la VPN. La regola che ho indicato, l'ho aggiunta io per vedere se 
intercettava quel traffico

 Ah, stà gioventù moderna....
 
Ho solo indicato l'errore che viene fuori. Ovviamente sono aperte anche 
la 500 e la 4500 (come ho detto, il WAN dello Zyxel è messo in DMZ sul 
modem, quindi riceve tutto il traffico). 500 e 4500 sono inserite nel 
gruppo dei servizi abilitati a passare

 UDP 500, UDP 4500 ce le siamo dimenticate?
 
ma non solo :)
 
 
IKE  500/UDP
L2TP 1701/UDP
ESP  protocollo 50
NAT-T 4500/UDP
 
 
 



per chiarire
 
rule 5000 {
    action accept
    description "ipsec ike"
    destination {
        port 500
    }
    protocol udp
}
rule 5010 {
    action accept
    description "ipsec l2tp"
    destination {
        port 1701
    }
    ipsec {
        match-ipsec
    }
    protocol udp
}
rule 5020 {
    action accept
    description "ipsec nat-t"
    destination {
        port 4500
    }
    protocol udp
}
rule 5030 {
    action accept
    description "ipsec esp"
    protocol esp
}
 
 
nella regola 5030 "esp" corrisponde (ovviamente) a 50
 
 

ObiWan ci ha detto :

Tutte queste policy vengono create in automatico, infatti con la stessa 
configurazione, non nattata, funziona perfettamente.
Se non ricordo male dovrei aver abilitato sul modem anche l'inoltro di 
tutti i protocolli (GRE, ESP, ecc...) ma faccio una verifica

 E che apparato stà "nattando"? E chi è il fornitore del traffico? 
 
Purtroppo, un classico Technicolor TIM

Scriveva Skywalker Senior sabato, 12/11/2022:

p.s. La VPN SSL, sempre configurata tramite wizard, invece funziona 
perfettamente anche dietro lo stesso NAT, e non ho dovuto aggiungere 
nulla

 ;-)
 
Ti diverti a farmi sudare, eh?

 (leggiti l'altro mio post)
 
Per quanto ne so, la VPN SSL passa sulla porta 443 TCP

 interessa. 
 
Sono tutt'orecchi

 decente costa una frazione e hai già dentro sia L2TP che openvpn.
 
Ora che mi dici così, mi torna in mente una configurazione, fatta 
qualche mese fa da un altro cliente, su linea FWA sempre di TIM, e 
sempre con uno Zyxel. Al momento di testare la linea, ho collegato il 
mio PC, ho ottenuto un IP via DHCP e ho verificato che tutto 
funzionasse. Poi ho contattato il tecnico di riferimento e ho chiesto 
di aprire tutte le porte verso l'IP che avrei assegnato al firewall, 
proprio in previsione di mettere in piedi una VPN. Il tecnico mi ha 
"suggerito" di assegnare alla WAN direttamente l'IP pubblico, 
assicurandomi che avrebbe funzionato, cosa che effettivamente è 
avvenuta. Mi ha detto, testuali parole, "è così per tutti" (non so se 
si riferisse solo agli apparati TIM Business o a tutto in generale). 
Non ho avuto modo di provare la cosa da altri clienti. Chiaramente non 
sono cose che si possano provare "da remoto"

 Si fanno, si fanno... ;-) 
 
Sì, se hai confidenza col mezzo... sennò si rischia che un'impostazione 
sbagliata interrompa la connessione, e poi tocca correre dal cliente

 Ma anche no 2 la vendetta.
 
Ammiro la sicurezza, data sicuramente dall'esperienza.
Io che metto mano a questi apparati solo di tanto in tanto, preferisco 
andare coi piedi di piombo. A meno che non ci sia un "dispositivo di 
sicurezza" preferisco non rischiare di impostare una regola che possa, 
per esempio, bloccare il traffico internet, facendomi perdere la 
connessione. Su alcuni vecchi firewall d-link (lo so, stai ridendo), 
ogni volta che si applicava una modifica, ti veniva chiesto di 
confermarla entro 1 minuto in una videata successiva. Ovviamente, se si 
perdeva la connessione, non potendo accedere a tale pagina entro il 
timeout, la modifica veniva annullata e tutto tornava come prima.

 Tennnologia che c'è basta applicarla.
 
Abbi pazienza, ma non stiamo parlando di grandi aziende, con linee 
ridondate o di backup (o anche solo una linea secondaria su LTE), ma di 
aziendine piccole per le quali se proponi una spesa di 500€ che non 
prevedevano, storcono il naso.
Poi si possono fare tutte le considerazioni del mondo sull'opportunità 
che tali aziente debbano o meno sopravvivere in un mercato globale, ma 
intanto la realtà è questa.
Però stiamo esulando dall'argomento e si va OT


 
Concordo in toto con quanto scrivi, e vorrei essere sempre nella 
posizione di "consigliere" del cliente. Purtroppo questo non sempre 
avviene

 materialmente andare davanti ad un PC e seguire istruzioni telefoniche
 
E' quello il punto. Non deve *MAI* esserci un unico POF. In questo caso,
un'unica linea. Uno straccio di modem/router/chiavetta, vecchio, da
pochi euro, magari di seconda mano e con sopra ancora gli adesivi dei
Simpson e delle Barbie che ci hanno lasciato i figli del precedente
proprietario, con una SIM da cinque euro al mese, che punta a un
DynDNS... ormai è il minimo sindacale perfino in una casa privata.
 
E lo sai già anche tu, che sopra hai nominato la "linea secondaria su
LTE" :-P
 
******************************************************************
 
Però quello a cui sta puntando quella volpe di Allen è qualcos'altro,
l'ha de... ops, scritto esplicitamente :-)
 
E, se devo essere sincero e onesto, visto che non mi sono mai trovato,
almeno negli ultimi venti anni, in una situazione dove ci fosse una
connessione non ridondata... lo ammetto, non sono sicuro di dove voglia
andare a parare. Ho solo idea che quando lo dirà mi toccherà darmi
l'ennesima botta in testa da solo dicendo "ma come ho fatto a non
pensarci" :-(
 
Voglio dire, mi vengono in mente sistemi di ripristino automatico della
configurazione precedente in caso di perdita della connettività, o roba
del genere, ma ho come l'idea che lui abbia in mente un'alra cosa che mi
sfugge.
 
Bye, G.

 DynDNS... 
 
una sim da 5eur, immagino che al 99% siano nattate... a che serve il
dyndns?


 siamo nel 2022... cribbio...
 
Boh, dopo due settimane di corsi per markettari a cui non
sono potuto sfuggire, il mio mononeurone č definitivamente flippato :-(
 
[Odio quella roba... io spiritualmente sono un operativo, non
un propalatore di buzzword >:-( ]
 
L'unoca cosa che mi viene in mente č che se lo configuri correttamente
prima di creare casini si puň accedere dall'esterno al router,
ma sono piuttosto sicuro che tu non intendessi questo... o sě?
 
Bye, G.
 
 
----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html
 

 ma sono piuttosto sicuro che tu non intendessi questo... o sì?
 
scommettiamo che non ti darà mai la soluzione all'enigma?
 
perchè voglio vedere senza nessuna connettività come fai a
rientrare... 
qualche annetto fa mettevo un pc con un modem pronto a rispondere :-)


 qualche annetto fa mettevo un pc con un modem pronto a rispondere :-)
 
Ah, mi consola il fatto di non essere l'unico a non aver capito quale 
potesse essere questa soluzione, che non sia, per l'appunto, aver 
predisposto una seconda linea di emergenza.

Nel suo scritto precedente, Skywalker Senior ha sostenuto :

Riprendo questa discussione, seppur vetusta, per indicare la 
risoluzione del problema.
La colpa non era del firewall Zyxel, ma di Windows.
 
In pratica bisogna aggiungere al registro la seguente vocina:
 
In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
 
Bisogna aggiungere il seguente valore DWORD
 
"AssumeUDPEncapsulationContextOnSendRule"
 
con valore 2
 
 
Senza questo parametro, Windows non si connette alla VPN L2TP se questa 
è dietro un NAT (mentre ci riesce perfettamente se il server/firewall è 
esposto direttamente).
Ci ho perso due giorni, perché ad un certo punto su un pc ero riuscito 
ad aprire il tunnel (poi non raggiungevo la rete remota, ma questa è 
un'altra faccenda, che spiego più sotto). Nel fare altre prove, su un 
altro PC, non ero più ruiscito neanche a collegarmi, finché non mi sono 
accorto che, mentre sul primo PC avevo inserito quella voce in registro 
(tempo addietro, per VPN L2TP create da server Windows), nel secondo 
no.
 
p.s. non raggiungevo la rete remota perché, al contrario di come facevo 
di solito sulle VPN PPTP, in questo caso bisogna configurare la VPN 
anche come gateway predefinito