Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

VPN: ci sto perdendo la testa

382 views
Skip to first unread message

Skywalker Senior

unread,
May 24, 2019, 1:53:00 PM5/24/19
to
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?

angelo

unread,
May 25, 2019, 4:52:21 AM5/25/19
to
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

Mirko Borsari

unread,
May 25, 2019, 6:18:40 AM5/25/19
to
Il Fri, 24 May 2019 19:53:12 +0200, Skywalker Senior ha scritto:

> 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.

aprile tutte verso il firewall...

> 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.

con le VPN c'è da aspettarsi di tutto, ma se il ping va...
non è che il firewall configurato sui pc/server dall'altra parte? Magari banalmente permette il traffico solo dalla loro LAN.
Il viceversa funziona? Se fai un teamviewer e da la ti colleghi qui?

> 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

Valerio Vanni

unread,
May 26, 2019, 12:04:49 PM5/26/19
to
On Sat, 25 May 2019 12:18:38 +0200, Mirko Borsari <ne...@bsi-net.it>
wrote:

>> 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.
>
>aprile tutte verso il firewall...

Se il tunnel va su, non dovrebbe aver bisogno di altre porte.
Il problema qui è in area LAN-to-VPN VPN-to-LAN.

>> 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.
>
>con le VPN c'è da aspettarsi di tutto, ma se il ping va...
>non è che il firewall configurato sui pc/server dall'altra parte? Magari banalmente permette il traffico solo dalla loro LAN.
>Il viceversa funziona? Se fai un teamviewer e da la ti colleghi qui?

Potrebbe essere.

Sui due firewall che stabiliscono il tunnel dovrebbe guardare il
registro, dovrebbe uscire fuori qualche "accesso negato".

Potrebbe anche esserci qualche blocco specifico su 139/445 nei
firewall perimetrali, su alcuni Zyxel l'ho visto.
Puoi anche mettere "tutto aperto" nel firewall, ma nella
configurazione dell'interfaccia (LAN - VPN - WLAN) etc c'è una voce
apposita chiamata "blocca traffico netbios". Da lui, però non va
nemmeno l'http.


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

Skywalker Senior

unread,
May 26, 2019, 3:05:44 PM5/26/19
to
angelo scriveva il 25/05/2019 :

>
> 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

No, non li raggiungo neanche indicando l'IP

MasterPiece

unread,
May 29, 2019, 5:44:41 AM5/29/19
to
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.

Skywalker Senior

unread,
May 30, 2019, 6:19:23 AM5/30/19
to
Mirko Borsari ha pensato forte :
> Il Fri, 24 May 2019 19:53:12 +0200, Skywalker Senior ha scritto:
>
>> 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.
>
> aprile tutte verso il firewall...

Quel merdoso router ha un limite di 10 porte apribili, ma, al di là di
questo, una volta stabilito un tunnel VPN, tutto il traffico non
dovrebbe essere incapsulato lì dentro, a prescindere dal protocollo?
Comunque le porte più comuni (80, 443, 25, ecc... sono già aperte verso
il FW interno)

>
>> 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.
>
> con le VPN c'è da aspettarsi di tutto, ma se il ping va...
> non è che il firewall configurato sui pc/server dall'altra parte? Magari
> banalmente permette il traffico solo dalla loro LAN. Il viceversa funziona?

Il problema me lo danno tutti i servizi. Per esempio se, banalmente,
dalla Rete A digito l'IP del firewall A, mi si apre la maschera di
login. Se dalla rete B digito lo stesso IP, il browser dice che non è
raggiungibile (ma il ping risponde). Questo avviene in entrambe le
direzioni. Tenete conto che, nella sede italiana, il mio firewall NON è
dietro NAT, quindi mi aspetterei che, se fosse colpa del modem Vodafone
dall'altra parte, almeno da là a qua, le cose funzionassero.

> Se fai un teamviewer e da la ti colleghi qui?

Perché teamviewer?

>
>> Su entrambi i firewall ho inserito una regola NAT che consente TUTTO il
>
> 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!

Skywalker Senior

unread,
May 30, 2019, 8:34:15 AM5/30/19
to
Dopo dura riflessione, MasterPiece ha scritto :
> On 24/05/2019 19:53, Skywalker Senior wrote:
>> 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?
>
> Hai provato a fare un trace e vedere dove si ferma,

Il trace, come il ping, parte e torna tranquillamente se interrogo un
ip dell'altra rete.
Se, invece, interrogo un nome-host, ovviamente non parte nemmeno,
perché non riesce a risolvere l'indirizzo (neanche se aggiungo l'ip del
DNS remoto come secondario nella config di rete)

> 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?
> Sennò 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.

Il FW sta in mezzo tra la LAN ed il router Vodafone... non sono
alternativi

Skywalker Senior

unread,
May 30, 2019, 10:10:53 AM5/30/19
to
Skywalker Senior ha detto questo venerdì :
> 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!

Mirko Borsari

unread,
Jun 1, 2019, 6:11:40 PM6/1/19
to
Il Thu, 30 May 2019 12:19:21 +0200, Skywalker Senior ha scritto:


>> aprile tutte verso il firewall...
>
> Quel merdoso router ha un limite di 10 porte apribili, ma, al di là di
> questo, una volta stabilito un tunnel VPN, tutto il traffico non
> dovrebbe essere incapsulato lì dentro, a prescindere dal protocollo?

era per semplificare la gestione indipendentemente dalla vpn

> Il problema me lo danno tutti i servizi. Per esempio se, banalmente,
> dalla Rete A digito l'IP del firewall A, mi si apre la maschera di
> login. Se dalla rete B digito lo stesso IP, il browser dice che non è
> raggiungibile (ma il ping risponde). Questo avviene in entrambe le
> direzioni. Tenete conto che, nella sede italiana, il mio firewall NON è
> dietro NAT, quindi mi aspetterei che, se fosse colpa del modem Vodafone
> dall'altra parte, almeno da là a qua, le cose funzionassero.

non è detto... NAT traversal configurato?
>
>> Se fai un teamviewer e da la ti colleghi qui?
>
> Perché teamviewer?

perchè se in VPN la non arrivi, con un TV ti colleghi su un PC e fai
tutte le prove del caso anche da la verso qui...


>>> Su entrambi i firewall ho inserito una regola NAT che consente TUTTO il
>>
>> 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!

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...

Lorenz

unread,
Jun 2, 2019, 5:11:12 AM6/2/19
to
Il 02/06/2019, Mirko Borsari ha detto :
Ma non ha gia' risolto? :-)

Skywalker Senior

unread,
Jun 2, 2019, 9:19:32 AM6/2/19
to
Lorenz ha detto questo domenica :
Si, avrà perso la risposta... no problem

Skywalker Senior

unread,
Jun 3, 2019, 6:11:58 PM6/3/19
to
Skywalker Senior ha usato la sua tastiera per scrivere :

>
> 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

ObiWan

unread,
Jun 6, 2019, 12:03:21 PM6/6/19
to
:: On Thu, 30 May 2019 14:34:31 +0200
:: (it.comp.reti.locali)
:: <qcoik4$hat$1...@gioia.aioe.org>
:: Skywalker Senior <s...@spammatuamamma.com> wrote:

> Se, invece, interrogo un nome-host, ovviamente non parte nemmeno,
> perché non riesce a risolvere l'indirizzo (neanche se aggiungo l'ip
> 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 :)


Skywalker Senior

unread,
Jun 6, 2019, 12:21:11 PM6/6/19
to
ObiWan scriveva il 06/06/2019 :

>
> 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ì

ObiWan

unread,
Jun 7, 2019, 2:54:48 AM6/7/19
to
:: On Thu, 06 Jun 2019 18:21:27 +0200
:: (it.comp.reti.locali)
:: <qdbehk$e8q$1...@gioia.aioe.org>
:: Skywalker Senior <s...@spammatuamamma.com> wrote:

> ObiWan scriveva il 06/06/2019 :
>
> >
> > spero di essere stato chiaro :)

> Il problema era un altro e l'ho risolto

Lo so, ho letto il resto del thread

> 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




0 new messages