Newsgroup: it.comp.reti.locali
Titolo: VPN: ci sto perdendo la testa

Ho messo in piedi una VPN IPSec Site-to-Site tra due sedi di un cliente 
(una è in germania). Dal lato "italiano" ho un Mikrotik su cui arriva 
direttamente l'ip pubblico, dall'altra ho un Dell SonicWall nattato 
dietro un router Vodafone. Quest'ultimo NON mi permette di mettere il 
firewall in DMZ (router Vodafone PlusBox tedesco), quindi mi sono 
limitato ad aprire le porte UDP 500 e 4500.
Il tunnel si apre e apparentemente funziona, perché riesco a pingare 
qualsiasi apparato da una rete all'altra. Peccato che tutto il resto 
(navigare nell'altra rete, raggiungere una condivisione, aprire una 
pagine intranet) non me lo faccia fare.
Su entrambi i firewall ho inserito una regola NAT che consente TUTTO il 
traffico da VPN a LAN e viceversa, quindi non so più cosa fare.
I log non riportano alcun messaggio che mi aiuti.
Qualche suggerimento?

Il 24/05/19 19:53, Skywalker Senior ha scritto:

Non sara' un problema di risoluzione dei nomi per cui i PC sono 
raggiungibili per indirizzo IP (infatti rispondono al ping) ma non per 
hostname?
 
angelo

 Su entrambi i firewall ho inserito una regola NAT che consente TUTTO il 
 
regola NAT non credo... avrai creato una regola di firewall.
 
 
 
-- 
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

regola NAT non credo... avrai creato una regola di firewall.
 
Vorrei capire anch'io che regola ha creato...
 
 
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

 angelo
 
No, non li raggiungo neanche indicando l'IP


Hai provato a fare un trace e vedere dove si ferma, non potrebbe essere 
un problema di routing, tu raggiungi un host sulla rete lan remota ma 
lui non sa che per raggiungere la rete lan di partenza deve passare per 
il FW e quindi la VPN? Senò butterà tutto il traffico sul modem internet 
vodafone.
Cioè, tutti i client delle Lan remote sanno che per raggiungere l'altra 
rete devono passare per il FW e non per il modem internet che magari è 
il default.

 regola NAT non credo... avrai creato una regola di firewall.
 
Pardon, errore dettato dalla fretta di scrivere... si, era una policy 
sul firewall
Mi si fa notare che quello che potrebbe mancare è una route che indichi 
alle macchine della sede A che, se vogliono raggiungere un IP della 
sede B, il traffico deve passare dalla VPN (e viceversa), il che, 
comunque, non spiega perché i ping rispondono!

 devono passare per il FW e non per il modem internet che magari è il default.
 
Il FW sta in mezzo tra la LAN ed il router Vodafone... non sono 
alternativi

 Ho messo in piedi una VPN IPSec Site-to-Site tra due sedi 
 
Il problema era proprio dovuto ad un mancato routing degli IP 
"esterni", solo sul Mikrotik della sede locale (evidentmente sul 
SonicWall tale regola era stata creata dal VPN wizard iniziale).
Una volta aggiunta una route che indicasse che tutto il traffico 
diretto agli IP dell'altra sede devesse essere inviato alla porta WAN 
(cosa che davo per scontato), ha cominciato a rispondere tutto 
correttamente: condivisioni, pagine intranet, servizi vari...
Resta il mistero del perché, senza tale regola, il ping venisse 
instradato correttamente, mentre tutti gli altri servizi, no!
 
Grazie a tutti per le imbeccate!

 comunque, non spiega perché i ping rispondono!
 
infatti... il routing direi che è a posto. Ammesso che la VPN sia OK
(e il fatto che si instauri non la rende automaticamente OK) direi che
hai qualcosa in mezzo che filtra...
Vai di wireshark... analizzi un po' di punti e intanto capisci cosa
arriva e cosa no...


Il 02/06/2019, Mirko Borsari ha detto :

Ma non ha gia' risolto? :-)

Lorenz ha detto questo domenica :

Si, avrà perso la risposta... no problem

 Grazie a tutti per le imbeccate!
 
Comunque morire che uno, dico UNO, dei millemila siti, tutorial, video, 
che ho spulciato istruzione per istruzione, abbia fatto cenno a quella 
route.
Molti evidentemente lo danno per scontato, molti altri si limitano ad 
instaurare il tunnel, fa niente se poi la connessione è funzionante o 
meno

 del DNS remoto come secondario nella config di rete)
 
Non basta l'IP, ti serve il nome del dominio :) in breve, devi
assicurarti di utilizzare un FQDN (diverso) su entrambe le reti, ad
esempio
 
retea.local
 
reteb.local
 
a quel punto, nei DNS delle due reti imposterai delle regole di forward
condizionale, ossia
 
DNS rete A:
 
reteb.local -> DNS rete B
 
DNS rete B:
 
retea.local -> DNS rete A
 
a questo punto, provando, dalla rete A, a lanciare un "ping" verso un
host della rete B (es. "ping pippo.reteb.local") la richiesta DNS verrà
inviata al DNS della rete A, questo, avendo una regola di inoltro per
il dominio "reteb.local", inoltrerà la richiesta al DNS della rete B e
ritornerà quindi l'indirizzo desiderato :)
 
Per impostare il suffisso (retea.local o reteb.local), se stai usando
DHCP ti basterà valorizzare l'opzione 15 (domain name) del DHCP usando
il valore appropriato per ciascuna rete
 
Volendo poi evitare di dover digitare il nome FQDN, ossia completo di
dominio (es. pippo.reteb.local) potresti considerare l'idea di
aggiungere il dominio di rete remoto alla lista di ricerca, in tal
caso, per fare un esempio, la lista dei suffissi di ricerca sulla rete
A sarà
 
retea.local
reteb.local
 
c'è però da considerare che, se su entrambe le reti fossero presenti
host con lo stesso nome, la risoluzione non FQDN non funzionerà, a meno
di non specificare il nome FQDN dell'host desiderato, per capirci, se
avessimo
 
pippo.retea.local
pippo.reteb.local
 
e, da rete A, con l'elenco di ricerca impostato come visto sopra,
lanciassimo un "ping pippo", il ping verrebbe indirizzato all'host
pippo.retea.local
 
spero di essere stato chiaro :)
 
 

 spero di essere stato chiaro :)
 
Il problema era un altro e l'ho risolto, ma questa cosa del dominio me 
la segno e proverò a farla.
Per il momento, dato che mi serve solo che dalla sede A si raggiungano 
solo determinate macchine della sede B (i server, nello specifico), ho 
aggiunto una nuova zona di ricerca diretta nel DNS del DC della sede A.
Questo, ovviamente, comporta che per raggiungere tali macchine si debba 
specificare l'intero FQDN, ma per ora va bene così

 ma questa cosa del dominio me la segno e proverò a farla.
 
niente di che serve semplicemente a permettere la risoluzione tra le
due reti; considera che potrebbe essere utile anche impostare una
regola di forward per le zone reverse