Newsgroup: it.tlc.gestori.fastweb
Titolo: vpn con fastweb

DA POCHI GIORNI HO SOTTOSCRITTO UN ABBONAMENTO INTERNET CON FASTWEB E
HO VISTO CHE NON RIESCO A COLLEGARMI IN VPN CON IL PC DELL
UFFICIO(RETE NON FASTWEB).
SAPETE SE CE QUALCHE LIMITAZIONE PER VIA DEGLI INDIRIZZI IP PRIVATI ?
CON TELECOM RIUSCIVO BENE...POTETE FORNIRMI UNA SOLUZIONE TECNICA AL
PROBLEMA ?
GRAZIE IN ANTICIPO

 PROBLEMA ?
Ci sono soluzioni OpenVPN che parrebbero andare, ma richiedono
configurazione da ambo i lati del tunnel, e il successo non e' garantito.

 GRAZIE IN ANTICIPO
io utilizzo pcanywhere senza problemi..
da casa(fastweb) verso lavoro (alice bussiness)

5 Maggio ha usato la sua tastiera per scrivere :
(alice bussiness)
business


Che tipo di collegamento VPN sarebbe? PPTP, IPSEC, OpenSSL o che
altro?
Ciao

SAPETE SE CE QUALCHE LIMITAZIONE PER VIA DEGLI INDIRIZZI IP PRIVATI ?
E' il protocollo VPN che usi tu che è proprietario, bacato e non
supporta il NAT-Trasversal.
OpenVPN è libero e sicuro, e funziona anche con Fastweb.
-- 
NON DARE ASCOLTO a "Cane Rabbioso" e "Marc Serafino": 
http://tinyurl.com/y7em3h
 e 
http://tinyurl.com/y2kfsu
Prove che "Cane Rabbioso" è coglione e quaqquaraquà: 
http://tinyurl.com/y93nok
 e 
http://tinyurl.com/yxln6t
Prova che "Marc Serafino" è coglione: 
http://tinyurl.com/y737fn
Prova che "Marc Serafino" è quaqquaraquà: 
http://tinyurl.com/2carc6
 e 
http://tinyurl.com/ynt4pj
Prova che avere Telecom mette a rischio di truffe: 
http://tinyurl.com/y2zl5l
Io ho killato Marc Serafino: fallo anche tu! Recupererai tutto il tempo perso a leggere le sue cazzate :D


Dipende dal tipo di VPN.
Da noi usiamo una VPN di tipo IPSEC (implementato con OpenSWAN sotto Linux) 
e "TheGreenBow" come client e la VPN fra casa mia (fastweb) e l'ufficio 
funziona benissimo.

 wrote in message 
news:37ce54d4-9aae-47c4...@t1g2000pra.googlegroups.com...

Io ho sempre chiuso con successo le VPN con i router Cisco su reti esterne 
(client VPN installato sul mio pc in rete fastweb).
D. 

 connettivita' Internet. Dovevi pensarci prima di abbonarti.
E' cosa nota che dici inesattezze grandi come Giove.

 
Ma le risposte a questa discussione Marc non le ha lette? Bah..... altra 
figuraccia, come al solito!
-- 
"Fastweb, anche comparato alle offerte analoghe, e' un tutto compreso ad 
alte prestazioni semplicemente imbattibile sotto tutti i punti di vista."

 figuraccia, come al solito!
E di grazie dove sarebbe l'inesattezza? E quindi dove starebbe la
figuraccia? Piuttosto tu lo sai qual e' lo standard de facto delle VPN in
ambito Windows? E come mai se e' cosi' possibile e semplice il nostro amico
non e' riuscito a connettersi? E se Fastweb e' come tutti gli altri
gestori, perche' le VPN con gli altri gestori funzionano senza dover per
forza utilizzare OpenVPN (dove possibile) e spendere tempo per configurarlo
_anche_ lato server, dove molte volte un tele lavoratore non puo' chiedere
configurazioni particolari al proprio datore di lavoro?

 
E di grazia come hai fatto? Che protocollo hai utilizzato? Hai attivato
l'IP pubblico? Il server stavo in Internet o nella rete locale di Fastweb?

 Fastweb?
a serafi', e svegliati ! ma che sei, rimbecillito ? il NAT crea problemi 
a raggiungere i PC **dentro** la rete fastweb, ma non hanno mai creato 
**alcun** problema a raggiungere, da dentro, VPN esterne.
Sono anni che telelavoro con una certa frequenza, pur essendo dentro la 
rete FW, e con l'access point della VPN all'estero...

 **alcun** problema a raggiungere, da dentro, VPN esterne.
Non che sia un esperto in configurazioni di VPN ad ogni modo io uso senza 
problemi una VPN Cisco con trasparent tunneling abilitato (che poi dovrebbe 
essere null'altro che il Nat-Traversal) che č poi l'opzione standard per 
utilizzare la vpn nei casi in cui non si piů mettere le mani sulla 
configurazione del con cui viene fatto il NAT.
Dibert, il Nat crea problemi solo a raggiungere un PC dentro la rete ma 
questo fa si che in alcuni casi in fase di negoziazione la risposta 
dell'apparato remoto non ritorni correttamente al pc che fa richiesta. Di 
fatto se non erro le VPN IPSEC come quella di Microsoft non sono in grado di 
instaurare una connessione se c'č di mezzo un NAT.


cmq garzie mia vevi risposto in molti .-)


GRAZIE PER LA DRITTA


è SU IPSEC,SAI AIUTARMI ?


e su ipsec...

 wrote in message

mi dici la tua soluzione ?

 è SU IPSEC,SAI AIUTARMI ?
Come ti ho gia' detto IPSEC non va con Fastweb. Solo OpenVPN. Peccato che
IPSEC sia di fatto lo standard.

 instaurare una connessione se c'è di mezzo un NAT.
potresti dirmi la tua soluzione con VPN Cisco con trasparent tunneling
abilitato?

 GRAZIE PER LA DRITTA
prego
ti posso assicurare che anche un altro programma funziona perfettamente 
(openVLC(?) ) ma ora non ricordo il nome preciso
te lo farò sapere

(openVLC(?) )
VNC


vnc serve per andare in remoto e lo usavo gia ma prima devo fare la
connessione punto punto col firewall aziendale....
ecco peche mi serve la vpn


Prova a dare un'occhiata a questo articolo: 
http://tinyurl.com/24c6l6

 IPSEC sia di fatto lo standard.
prova a pensare quale protocollo utilizzi ogni volta che scrivi https:// sul 
tuo browser...
Cmq indipendentemente dal protocollo e' la direzione della vpn che conta. 
Con client interno e server esterno puoi usare quello che vuoi, mentre con 
client esterno e server interno non c'e' nessun modo di instaurare la VPN, 
con nessun protocollo.
Tutti i meccanismi piu' meno tarocchi prevedono che sempre che dall'interno 
qualcuno apra una sessione verso un server esterno, che poi fara' da 
proxy/ponte/mediation/quellochetipare. Ma se qualcuno dall'interno non 
prende l'iniziativa non c'e' niente da fare.
Ciao
Marco 

 Cmq indipendentemente dal protocollo e' la direzione della vpn che conta. 
Non è del tutto vero: se così fosse non ci vorrebbe ipsec + nat-t
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 che IPSEC sia di fatto lo standard.
Seeeee, mio nonno non va con fastweb! Cavoli, ma continui proprio a spararle 
grosse.
Io uso IPSEC e funziona benissimo. Per la precisione il server è una Linux 
Fedora con OpenSWAN e il client (sotto Windows) è "The Green Bow".
Il server è sotto Fastweb (con IP statico e pubblico) mentre i client usano 
diversi provider (Infostrada, Telecom e anche Fastweb).

 Il server č sotto Fastweb (con IP statico e pubblico)
Appunto. Io parlavo di connessione _residenziale_ dove il client e' Fastweb
e il seever una qualsiasi cosa con IP pubblico. Nel tuo caso entrambi hanno
IP pubblico.
Ora chi e' che le spara grosse? tu che non hai capito o io?

 Ora chi e' che le spara grosse? tu che non hai capito o io?
Qui non è questione di non capire. Tu hai capito benissimo è solo che ti fa 
comodo continuare a ripetere fino all'ossesso "con fastweb questo non va, 
quest'altro non è come lo vorrei io, blablabla".
Fastweb ha diversi difetti e fa schifo sotto diversi punti di vista, ma 
IPSEC verso l'esterno funziona.

 Non č del tutto vero: se cosě fosse non ci vorrebbe ipsec + nat-t
si, pero' con il nat-t risolvi il problema se la direzione e' quella 
"giusta".  Mentre se la direzione e' "sbagliata" non c'e' niente da fare: 
anche il server deve partecipare aprendo una connessione verso qualche 
sistema esterno.
Ciao
Marco 

 IPSEC verso l'esterno funziona.
ma anche NO! Funziona _e non sempre_ IPSEC + NAT-T! Che e' una bella
differenza con una configurazione semplice di IPSEC tra due punti che come
dovrebbe essere sono proiettati su Internet con IP pubblico.

 Non farmi ridere.
Ok, finiamola qui.
Allora sarò io che ho configurato in qualche arcano modo un server IPSEC 
"magico".
Ma che strano proprio in questo momento io sono il client (sotto fastweb con 
ip privato del tipo 192.168.x.x dietro a un mio router e quindi dietro a DUE 
NAT, il mio e quello di fastweb) e la VPN IPSEC con il server in azienda 
funziona benissimo.

 azienda funziona benissimo.
perche' sei nella direzione giusta...e' il contrario che non va (server in 
fastweb e client in internet). Vai al post "hamaci e openvpn"...ho provato a 
scrivere due righe a proposito.
Ciao
Marco 

 - Mostra testo tra virgolette -
grazie

 instaurare una connessione se c'è di mezzo un NAT.
conosci qualcosa di Microsoft che funziona senza problemi ?

 (server in fastweb e client in internet).
Ma qui si stava parlando proprio di una persona che aveva (o ha ancora) un 
problema con la sua VPN di cui lui fa da client e il server è fuori.
E ovviamente la testa dura (sai bene a chi mi riferisco) è subito saltato su 
dicendo che "blablabla fastweb schifo blablabla, le vpn non funzionano, 
ecc...".

 ecc...".
Infatti non funzionano o non funzionano senza problemi come con qualsiasi
altro gestore che fornisce vera Internet. O sbaglio?



Questa e' la solita banalita' di quello che si sente fico a dire che i
prodotti Microsoft sono inferiori, quando sono almeno otto anni che
Microsoft fa ottimi sistemi operativi. Mah.

Marc Serafino ha scritto:

Chiariamo che le vpn basate su pptp e protocollo GRE non funzionano 
correttamente non tanto per la questione del nat di fastweb , ma 
quantomeno dalla volontà di fastweb di bloccare esplicitamente pptp e la 
sua negoziazione sugli ip nat assegnati ai residential.
Tanto che attivando ippd funzionano senza problemi
Altre soluzioni openvpn,Cisco e altre ancora , nat o non nat funzionano 
non essendo soggette a questo blocco VOLUTO.
e PUTROPPO FASTWEB è in buona compagnia da qualche tempo poichè anche 
altri fornitori non "implementano" gre (come amano usare dire loro al 
posto di boicottano che sta male..)
Evidentemente perchè il servizio di vpn è a listino ..a parte.
Se non altro l'altro fornitore di cui parlo che effettua un blocco 
simile ha onestamente dichiarato sin dall'inizio della limitazione e 
offre una soluzione ad un costo onesto per ovviare.
Contrariamente a qua dove si continua a negare l'esistenza del problema 
sino alla sua scoperta.
Come stiamo con la disdetta ? Qua per ora nessuna news

 rete FW, e con l'access point della VPN all'estero...
Sono anche anni che è nota l'impossibilità di utilizzare pptp liscio 
come documentato sin dalle prime faq di ITGF , come per esattezza di 
cronaca è nota la possibilità di utilizzare le soluzioni openvpn,cisco o 
di altri fornitori cosi' anche le ultime versioni vpn win2003 server-based.
Cio' non toglie , sino a prova contraria che fastweb blocca pptp sulle 
connessioni residential volutamente per fini commerciali che non hanno 
nulla a che vedere con il fatto di essere dietro nat.

dibert ha scritto:

La loro soluzione al problema basata su windows2003 server e NAT-T ad 
esempio.
Non amo microsoft ma qui non hanno colpa proprio

 posto di boicottano che sta male..)
Premesso che anche Microsoft si e' decisa comunque a "deprecare" in modo
esplicito (seppur soft) l'uso di PPTP/GRE per realizzare scenari VPN, la
mancata implementazione di GRE passthrough ha comunque anche un
fondamento tecnico (senza trascurare ovviamente la componente di logica
commerciale, visto che parliamo di provider e non di onlus).
Implementare GRE Passthrough attraverso sistemi di gestione NAT/PAT lato
provider comporta infatti la predisposizione tecnica di apposite misure
mirate ad evitare rischi di sicurezza nelle comunicazioni tramite
tunnel GRE/mGRE con endpoint "esterni" ai sistemi di NAT/PAT.  
Non e' infatti casuale che, onde evitare precisi rischi (e.g. bypass ACL
del provider tramite appositi pacchetti GRE spoofed), qualora vi sia
l'esigenza di consentire traffico GRE utenze attraverso interfacce di
NAT/PAT sia decisamente raccomandata l'adozione di precise misure di
protezione e.g.:
==
- Antispoofing per gli endpoint del tunnel GRE/mGRE (RFC-2827/ACL/RPF)
- IPSec over GRE
==
evitando di consentire il GRE passthrough "libero".
L'adozione di tali misure puo richiedere quindi, a seconda dei casi,
o aggiustamenti di configurazione sugli apparati esistenti oppure reali
aggiornamenti SW (ved. Advisory Cisco IOS / vulnerabilita' GRE).
Logico quindi che un provider faccia bene i suoi conti prima di 
sostenere gli interventi richiesti per consentire un adeguato livello di
protezione sul traffico GRE/mGRE in transito su interfacce NAT/PAT,
tenendo conto della relativa entita' di tale traffico in rapporto a
numero/tipologia delle utenze = non hanno senso ne' l'implementazione di
GRE passthrough con un livello inadeguato di protezione (ved. rischi di
sicurezza) ne' quella in modo ottimale per soddisfare "quattro gatti"
sul totale del parco utenze (ved. costi), ed ecco perche' per un
provider puo risultare piu' comodo/conveniente di base non implementarlo
affatto nelle offerte che prevedano NAT/PAT sui suoi apparati.
Cio' vale tanto qualora siano presenti a listino offerte/soluzioni che
consentano di effettuare traffico GRE all'esterno senza problemi (ved.
offerte business public subnet per FW e It.Net/Wind o residenziale/SOHO
IPPD per FW) quanto in loro assenza = il GRE passthrough per le utenze
residenziali/SOHO FW non c'era infatti nemmeno prima dell'introduzione 
di IPPD ad Ottobre 2002 -> ovvio poi che in seguito FW non si adoperasse
per consentire il GRE passtrough in architettura base hidden/dynamic
NAT M-1 ;). 
-- 
|Ż \/Ż | /Ż\ /Ż__/Ż__|<|> *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/
 ____<|

 evitando di consentire il GRE passthrough "libero".
Wind (che è il nostro fornitore delle HDSL destinate convogliare le 
utenze hyperlan) blocca difatti GRE passtrhrough sugli ip statici 
assegnati agli utenti collegati in ppoe.
Risolve pero' il problema fornendo, a richiesta e a pagamento, una 
subnet di 8 ip statici abilitati allo scopo.
Nota curiosa è che se si rimane all'interno della rete wind ovvero si 
collega un endpoint attestato su wind-infostrada, funziona tutto anche 
con gli ip degli utenti consumer.
Altresi' mi risulta che le utenze consumer classiche adsl infostrada con 
classico ip dinamico , non abbiano questo blocco.
Piu' che problemi di security io la vedo sotto un altro aspetto :)