VPN problemi sull'IP WAN

[epsilon]

Ho un NAS in ufficio con un IP pubblico. La porta TCP 1723 è sicuramente aperta. Ora se provo a collegarmi in locale sulla VPN con Windows 8 funziona correttamente. Se invece provo da casa con l'indirizzo WAN mi restituisce sempre lo stesso errore

Errore 619: impossibile stabilire una connessione con il computer remoto. La porta utilizzata per la connessione è stata chiusa

Qualche idea? Ma il mio modem/router di casa deve essere configurato per autorizzarmi la connessione sulla porta 1723?

[ninio]

Difficile che tu abbia regole in uscita che bloccano la 1723 però tecnicamente è possibile quindi devi solo verificare che il tuo router/modem di casa permetta la connessione LAN to WAN la porta in questione, l'altra possibilità che tu abbia un firewall software sul PC e vale lo stesso discorso, devi abilitare il servizio/porta dipende dalla tipologia di firewall.
Di default i router hanno come policy il passaggio totale LAN to WAN quindi più probabile la seconda ipotesi.
Chiaramente la prova che hai fatto al lavoro non ha nessuna valenza quindi la porta 1723 potrebbe benissimo essere chiusa sul router in ufficio.

[epsilon]

Sono passato ad OpenVPN che mi sembrava più semplice. Ho aperto lato QNAP la porta UDP/1194 del router ma neanche questa soluzione funziona.

Come dici tu mi sembra strano che abbia delle regole che mi bloccano la connessione in uscita ed inoltre ho disabilitato, per maggiore chiarezza, il firewall di windows 8. Nel caso di OpenVPN l'errore che ottengo è questo

Sat Mar 01 23:40:34 2014 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Sat Mar 01 23:40:34 2014 UDPv4 link local: [undef]
Sat Mar 01 23:40:34 2014 UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Sat Mar 01 23:41:34 2014 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Mar 01 23:41:34 2014 TLS Error: TLS handshake failed
Sat Mar 01 23:41:34 2014 SIGUSR1[soft,tls-error] received, process restarting

Qualche idea dove andare a vedere?

[lele88]

prova a rigenerare il certificato e per sicurezza controllare che nelle impostazioni del client ci sia abilitata la richiesta

che provider hai?

[epsilon]

Ho infostrada.

Cosa intendi per controllare le impostazioni del client per l'abilitazione alla richiesta?

Su un'altro forum segnalavano che è necessario aprire altre porte

TCP/47 GRE, TCP/1723 for PPTP, TCP/1701 for L2TP and TCP-UDP/500 for ISAKMP, CISCO etc

Ti risulta?

[dMajo]

Ho infostrada.

Cosa intendi per controllare le impostazioni del client per l'abilitazione alla richiesta?

Su un'altro forum segnalavano che è necessario aprire altre porte

TCP/47 GRE, TCP/1723 for PPTP, TCP/1701 for L2TP and TCP-UDP/500 for ISAKMP, CISCO etc

Ti risulta?

C'è un po di confusione qua
GRE è un protocollo (n°47) alla pari di TCP (6), UDP(17), ICMP(1, quello del ping) e molti altri. Non confondere le porte con i protocolli.

Le vpn usano diversi protocolli e porte:
PPTP: 6-TCP(1723), 47-GRE
L2TP: 6-TCP(1701) estensione del PPTP spesso usata con IPSec
IPSec: 50-ESP, 51-AH, 17-UDP(500 x IKE), 17-UDP(4500 se NAT-T)
SSL: generalmente 6-TCP(443)
OpenVPN(sslvpn): 17-UDP(1194), 6-TCP(443)

A seconda del router/firewall (soho) potrebbe esser difficile aprire protocolli diversi dai generici TCP/UDP. Verificare in questo caso se c'è un opzione "vpn pass-through" che permette un tunnel attestato internamente di attraversare il router/firewall oppure usare una vpn basata su ssl.

Nel tunnel il traffico viene incapsulato ovvero tutti i protocolli e le loro porte, di tutti gli ip, vengono imbustati nuovamente. La busta esterna, il pacchetto del tunnel appunto, viaggia su un determinato protocollo/porta fra i due end-point, dove viene nuovamente decodificata. Tutto ciò rallenta il traffico per la necessita di codificarlo e decodificarlo ai due lati. I router e/o firewall un po più seri che supportano le funzioni client/server vpn generalmente hanno del hardware dedicato (coprocessori) che gestiscono tale codifica/decodifica oppure sono dotati di una cpu centrale più corazzata.

Ci sarà pure una ragione del perché un router/firewal soho/bo può costare dai 25 ai 350 euro. Mi riferisco naturalmente ai SOHO dai casalinghi a quelli BO (branch office), escludendo ovviamente prodotti enterprise (che non sono integrati, ad ogni apparecchiatura il proprio compito) il cui prezzo minimo parte dai 1000.

[epsilon]

Sei stato chiarissimo. Il mio model/router è un NETGEAR DGND3700v2 e non ha opzione vpn pass-through . Stranamente offre un VPN Wizard per creare un tunnel con un VPN gateway o un VPN client. Volendo provare questa possibilità mi chiede una pre-shared key che non possiedo.

Mi confermi che lato QNAP il router deve semplicemente tenere le porte predisposte aperte e niente altro?

[dMajo]

Ho dato una rapida occhiata al manuale http://www.downloads.netgear.com/files/ ... pt2013.pdf
pag.123-129.

Il router sembra possa esser sia client che server vpn sia in modalità teleworker (accesso remoto utente singolo) che lan-2-lan (vpn statica fra due sedi).
Tuttavia sembra supportare solamente i tunnel IPSec anche se con qualche incongruenza: dice di supportare solamente il "Main Mode" (per lo scambio IKE fase 1) che presuppone due endpoint con ip statici mentre nella configurazione del gateway remoto consente l'ip dinamico che imporrebbe uno scambio IKE di fase 1 in "Agressive Mode".

Prova a configurarlo (con un client IPSec)
BTW: la "pre-shared key" te la devi inventare tu è come la password/passphrase del WPA/2-PSK, deve esser identica per entrambi gli endpoint.

Se preferisci invece usare il server vpn sul nas con openvpn non dovresti aver problemi.
Ovviamente tu hai un ip pubblico sul lato server vpn.

[lele88]

quando avevo provato la openvpn con il nas mi è bastato aprire la udp 1194 ed è andato tutto liscio, altre porte non sono servite

[dMajo]

quando avevo provato la openvpn con il nas mi è bastato aprire la udp 1194 ed è andato tutto liscio, altre porte non sono servite

Vero ma ... OpenVpn (non so quello del qnap, mai usato) ascolta sia sulla 1194 che 443 è infatti un sslvpn. La 443 è particolarmente utile dove non si controlla la rete(router/firewall) es azienda, hotspot, wifi alberghi ... per cui molte porte potrebbero essere chiuse. La 443 invece la troverete sempre aperta altrimenti addio navigazione https.

[epsilon]

Io sono passato ad OpenVPN ma nulla da fare. Ci sto sbattendo la testa. Credo che il problema sia il mio modem/router che tra le altre cose ha una delle interfacce utente peggiori della storia. La porta UDP 1194 è aperta ma non la 443.

Il messaggio è sempre lo stesso:

Wed Mar 05 20:53:48 2014 OpenVPN 2.3.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013
Enter Management Password:
Wed Mar 05 20:53:54 2014 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Mar 05 20:53:54 2014 UDPv4 link local: [undef]
Wed Mar 05 20:53:54 2014 UDPv4 link remote: [AF_INET]x.x.x.x:1194
Wed Mar 05 20:54:54 2014 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Mar 05 20:54:54 2014 TLS Error: TLS handshake failed
Wed Mar 05 20:54:54 2014 SIGUSR1[soft,tls-error] received, process restarting

Qualche idea su dove andare a vedere?

[ninio]

Io sono sempre convinto che tu in ufficio non abbia aperto correttamente la porta


Inviato dal mio iPhone utilizzando Tapatalk

[epsilon]

Anche io ero convinto di questa cosa (non mi fido del mio amministratore di rete) ma ho provato con diversi tool di scan delle porte presenti in rete tra cui questo

https://pentest-tools.com/discovery-pro ... nline-nmap

La riposta è questa

1194/udp open|filtered openvpn

Posso dedurre che è aperta? Oppure filtered implica qualche cosa?

[epsilon]

La faccenda credo che stia diventando chiara. Utilizzando nmap ottengo sempre che la porta 1194/udp è open|filtered. Questa risposta è la stessa sia che il servizio OpenVPN sul QNAP è abilitato sia nel caso in cui non è abilitato. Quindi credo che la porta sia alla fine filtered ovvero chiuda da un firewall.

La documentazione su nmap a proposito di open|filtered è la seguente: Nmap posiziona le porte in questo stato quando non e` in grado di determinare se una porta sia aperta o filtrata. Questo accade in quelle scansioni per le quali una porta aperta non risponde in alcun modo. La mancanza di informazioni puo` significare inoltre che un filtro di pacchetti ha lasciato cadere ("drop") il probe o qualsiasi risposta sia stata generata in seguito a questo. Scansioni che classificano porte in questo stato sono le scansioni IP, UDP, FIN, Null, e Xmas.

[epsilon]

Funziona tutto. Era il mio amministratore di rete che aveva dimenticato di aprire la porta UDP 1194.

Grazie a dMajo ed a ninio.