Newsgroup: it.tlc.gestori.fastweb
Titolo: ci spostiamo qua (NAT)

Qua in maniera pacata,ma anche accesa, discuteremo di cosa va e non va.
Solo una cosa : niente insulti e offese ne tra i pro e i contro.
Ognuno esprima la sua opinione esperienza con onestà.
Il primo argomento ovvero IPSEC è stato già discusso e sono date 
risposte esaudienti in particor modo dal solito macs.
Troverete i due post nella mitica discussione della vista web e doppino 
degradato.
Ipsec in maniera tradizionale quindi è bloccato dal nat fastweb e sono 
steti spiegati i motivi tecnici,la necessità del suo impiego e PURE le 
soluzioni per eventualmente usarlo anche se a caro prezzo (sostituzione 
di tutta l'architettura client/server.
Ogni volta che qualcuno troverà una apllicaziome non funzionante o 
menomata dal nat fastweb, per cortesia si accodi qua.
E se la fa funzionare dia spiegazioni


Hai dimenticato di dire che l'eventuale e non irrisolvibile situazione
non impatta sulle connessioni di tipo
aziendale in cui, invece, l'IPSEC é pienamente compatibile, leggere
offerta FAST.COMPANY dal sito FW.
Poi, se vuoi iniziare una nuova discussione, pacata e onesta, devi
partire da questo:
************************
Macs scrive:
Sistemi FW su rete MAN non possono ovviamente usare IPSec 'liscio' in
AH
o ESP Mode con endpoint/gateway esterni alla rete FW in virtu'
proprio
dell'architettura di rete FW.
Tuttavia, qualora tutti i sistemi coinvolti in un determinato
scenario
IPSec soddisfino le condizioni di interoperabilita'/compatibilita'
previste per IPSec in NAT-Traversal :
==
- 
http://tools.ietf.org/wg/ipsec/draft-ietf-ipsec-nat-reqts/
- 
http://tools.ietf.org/wg/ipsec/draft-ietf-ipsec-nat-t-ike/
- 
http://tools.ietf.org/wg/ipsec/draft-ietf-ipsec-udp-encaps/
==
e' possibile aggirare la limitazione dell'architettura Hidden/Dynamic
NAT M-1 della rete FW.
Questo ovviamente significa che le relative impostazioni di supporto
IPSec NAT-T debbano essere fatte su tutti i sistemi (e non solo lato
sistema su rete MAN FW) -> e' inoltre necessaria una maggiore
attenzione
nella configurazione di connessioni basate su IPSec NAT-T per ridurre
il
rischio di attacchi man-on-the-middle.
***********************************************
....quel tuttavia lì sopra non ti autorizza ad affermare che NON E'
POSSIBILE, né tantomeno a
portare l'acqua al tuo mulino con l'affermazione del tutto gratuita:
"le soluzioni per eventualmente usarlo anche se a caro prezzo
(sostituzione di tutta l'architettura client/server)" nons ei certo tu
che devi consigliare ciò che é giusto o sbagliato, un privato fa come
gli pare, se sceglie FW ha già valutato pro e contro, qui si discute
non si consiglia e non si parteggia.
Se affermi che il buon macs é la FONTE, allora devi essere corretto
fino in fondo e accettare, una volta
x tutte, che ciò che dici in ASSOLUTO é errato.
Io, al contrario tuo, invece affermo che:
Ipsec su fastweb funziona, ovviamente non nella forma standard visto
che siamo dietro ad un nat,
ma, nat-t o ipsec-over-udp o ipsec-over-tcp funzionano tutti.
Ora vorrei che mi smentiste su quanto ho affermato e contestualmente
argomentaste.
Direi che se siamo tutti d'accordo di affidare al buon macs
l'arbitrato sulla discussione
chiedendogli di validare o meno la bontà delle dichiarazioni dei
singoli post.
In definitiva mi chiedo: cosa non si può fare con fastweb che gli
altri provider con visibilità pubblica riescono a fare?
E' una domanda semplice, chiara, mi piacerebbe leggere solo risposte
inerenti ed esaustive.
Credo di essere stato pacato, ora mi aspetto una risposta commisurata.

 
E' impossibile aprire un servizio e accedervi da un qualsiasi host 
remoto con la stessa semplicità con la quale lo si fa con un provider 
che da ip pubblico.
Per esempio, non puoi aspettarti di utilizzare vnc con il server in 
ascolto, ma devi 'ripiegare' sulla soluzione inversa (server che si 
collega al client) o affidarti a servizi esterni, come logmein.
Non puoi aprire un ftp o un webserver accessibile al mondo, ma ti tocca 
utilizzare soluzioni vpn come hamachi (servizio di terzi) o openvpn (ma 
serve che il client sia noto o è necessario un account su un dns 
dinamico e comunque si ha bisogno di diritti amministrativi per 
l'installazione di tali pacchetti sul client).
Gaming online non saprei.
P2P: non che ci siano problemi in fastweb (anzi...), ma i trasferimenti 
da e verso esterni con i comuni protocolli emule/bittorrent, risentono 
della mancata collegabilità.

Ciao,
************************
Macs scrive:
Sistemi FW su rete MAN non possono ovviamente usare IPSec 'liscio' in
AH
o ESP Mode con endpoint/gateway esterni alla rete FW in virtu'
proprio
dell'architettura di rete FW.
********************
bisogna chiarire prima di tutto la direzione del tunnel IPSec. Non funziona 
da Internet verso Fastweb, ma funziona da Fw verso internet e all'interno di 
Fastweb.
Quello che Macs definisce "liscio" e' probabilemente la versione in 
transport mode che e' quella utilizzata nella configurazione client/server. 
AH non funziona perche' protegge anche l'header del pacchetto, mentre ESP 
funziona perche' non la protegge.
Entrambi funzionano invece in tunnel mode.
Tutte queste modalita' sono standard.
Per essere esaustivo :-)
ftp://ftp.isi.edu/in-notes/rfc2401.txt
ftp://ftp.isi.edu/in-notes/rfc2402.txt
ftp://ftp.isi.edu/in-notes/rfc2406.txt
*************
Io, al contrario tuo, invece affermo che:
Ipsec su fastweb funziona, ovviamente non nella forma standard visto
***********
funziona eccome nella sua forma standard, visto che lo standard ha previsto 
che il client possa stare dierto un NAT
*************
In definitiva mi chiedo: cosa non si può fare con fastweb che gli
altri provider con visibilità pubblica riescono a fare?
E' una domanda semplice, chiara, mi piacerebbe leggere solo risposte
inerenti ed esaustive.
Credo di essere stato pacato, ora mi aspetto una risposta commisurata.
*************
non puoi fare tutte quelle cose che prevedono una connessione proveniente da 
Internet verso un utente Fastweb. Deve essere sempre l'utente fastweb ad 
aprire la connessione verso l'esterno.
Ciao
Marco 

 che il client possa stare dierto un NAT
Dentro fastweb è appurato difatti che funzioni tutto regolarmente.
Tra client fasteb e server esterno invece non ho capito come hai 
aggirato il problema del blocco del protocollo di autenticazione che 
viene bloccato.Perchè analizzando il traffico di rete appariva un chiaro 
blocco di protocollo (non di porta) usando il nat convenzionale 
dell'utenza residenziale.
Ad esempio utilizzando una vpn/tunnel basata su l2tp senza ipsec , si 
riesce a stabilire il collegamento (seppur con prestazioni ridicole in 
termini di stabilità). Con ipsec NO, non 'era verso.
Attivando ippd (ip pubblico fastweb a pagamento) con la stessa 
configurazione invece la connessione avveniva senza problemi senza problemi.
Segnale  che è sul sistema di nattaggio o ultimo router pubblico comune 
che avviene un blocco.
Pertanto : non toccando il lato server, quale configurazione hai 
utilizzato affinchè l'autenticazione avesse successo ?
Due mesi fa circa,non ricordo chi, mi chiese se ancora fosse presente 
tale impedimento in quanto qualcuno appunto segnalava la fattibilità.
Dalle prove che ho rifatto invece, il problema è sempre lo stesso.
Stiamo parlando di novembre 2006

 della mancata collegabilità.
Aggiungo una altra cosa che mi sovviene in questo momento e che non 
riguarda di sicuro una minoranza ma una maggioranza di gente che 
vorrebbe telefonare tramite internet per risparmiare :
Non è possibile sottoscrivere MOLTI servizi di telefonia voip *erogati 
da fornitori italiani*.
Ovvero qualsiasi servizio ip-to-ip che funziona col principio di 
chiamare direttamente un numero. (quindi evitiamo di dire skype funziona 
benissimo o cose del genere)
E anche se io mi comprassi un telefono voip, non potrei mai ricevere 
chiamate da un qualasiasi apparecchio simile installato su internet (al 
massimo solo da utenti dela man fastweb).
Negli stessi siti dei fornitori c'è chiaramente indicato che i loro 
servizi sono attivabili su qulasiasi adsl eccetto quella di fastweb

 ha scritto nel messaggio 
news:45nwh.2650$wO2...@tornado.fastwebnet.it...

Non si può accendere il pc da remoto tramite WOL
S 

 
NI... in realtà questa operazione è stata portata a termine con successo 
con procedure contorte,complesse e al di fuori di una ristretta cerchia 
di utenza.
Quindi ecco il NI : il problema esiste ma non è insormontabile,il gioco 
non vale la candela per cui ..

> Non si può accendere il pc da remoto tramite WOL
c'è una soluzione poco ortodossa per farlo se hai un numero telefonico 
fastweb, una volta che ne hai attivato uno,li accendi tuttti in wol.
E' cmq il solito sporco ripiego quindi il problema da te esposto esiste

 Stiamo parlando di novembre 2006
Quel qualcuno era un'utenza Fibra MAN Milano, che mi aveva segnalato
in realta' di essere riuscito ad effettuare una connessione PPTP
base/standard (crittografia MPPE) dal suo sistema Windows XP SP2 su
connessione residenziale FW.
Tuttavia, le varie verifiche eseguite prima da te e successivamente dal
sottoscritto nella prima settimana di Dicembre avevano nuovamente
confermato che tale tipologia di accesso protetto non era effettuabile
a livello globale di MAN FW, in virtu' sempre del blocco a livello di
PPTP/GRE passthrough.
Inoltre l'utente che aveva fatto tale segnalazione non ha mai risposto
alle mie email dove gli chiedevo di fornire ulteriori dettagli ;).
-- 
|¯ \/¯ | /¯\ /¯__/¯__|<|> *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/
 ____<|

 da fornitori italiani*.
Da connessioni MAN FW (Residenziali/SOHO e PMI senza opzioni Address)
funzionano senza problemi servizi VoIP su protocollo SIP in modalita'
NAT traversal, appoggiandosi a STUN Server oppure a X-Tunnel, sia
utilizzando client SIP software che adattatori HW per il collegamento di
apparecchi telefonici o terminali VoIP.
La maggioranza degli operatori VoIP consumer offre linee su protocollo
SIP con supporto STUN e, qualora non indichi propri STUN Server, e'
possibile appoggiarsi a STUN server pubblici e.g. 
stun.softjoys.com
 o
altri indicati su :
==
- 
http://www.voip-info.org/wiki-STUN
I problemi reali si hanno semmai con servizi VoIP su protocollo H.323 
(e.g. Parla.it). In tal caso per effettuare/ricevere chiamate H.323 da
un sistema su connessione MAN FW senza IP Pubblico associato (IPPD per
utenze Residenziali/SOHO - Opzione Address per utenze PMI) e' necessario
l'appoggio ad un sistema su IP Pubblico con funzioni di H.323 Gatekeeper
Proxy per la gestione delle chiamate in uscita/ingresso.
Se non si dispone della possibilita' di realizzare autonomamente un
tale sistema - usando 
p.es
. GnuGK 
http://www.gnugk.org/
 - e' necessario
ricorrere a tali servizi offerti da provider terzi (generalmente a
pagamento) sempre che non sia incluso nell'offerta dell'operatore VoIP
H.323 scelto.
Esistono anche sistemi/appliance proprietari come quelli IXC, che
consentono di effettuare traffico VoIP H.323 con sistemi dietro NAT
non modificabile dall'utente -> ulteriori info sull'interoperabilita'
VoIP in scenari NAT sono comunque disponibili su :
==
- 
http://www.voip-info.org/wiki/view/NAT+and+VOIP
 
-- 
|Ż \/Ż | /Ż\ /Ż__/Ż__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|Ż|\/|Ż|/Ż_Ż\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|


 
Non lo sapevo, non si smette mai di imparare
Di fatto questo in pratica rende la limitazione da me descritta 
circoscritta praticamente ad una bassa percentuale di fornitori voip e 
non MOLTI come ho precedentemnte affermato .
0 a 1 :)

>
Siamo qui apposta : ognuno espone le proprie limitazioni e chi risponde 
le conferma e/o le smentisce.
Risposte molto esaustive come vedi ne arrivano e i primi argomenti messi 
in evidenza, addirittura fanno emergere scenari ai piu' (me compreso) 
sconosciuti che, pur segnalando i limiti di un sistema nattato non 
modificabile dall'utente, comunicano che cosa bisogna fare ed usare e 
quando invece arrendersi.
Al momento pare che i programmi "irriducibili" al NAT siano praticamente 
tutti quelli sviluppati prima di due anni fa circa,
Lo scopo da raggiungere è confermare le VERE limitazioni e SMENTIRE 
quelle inesistenti.
Comunque il ricorso a "in ogni caso bisogna ricorrere ad un appoggio 
esterno,ad un server esterno,ad un servizio fornito da un amico o terze 
parti" la considero sempre una limitazione a prescindere che poi renda 
funzionante l'applicativo : ok il fine giustifica i mezzi, la tua 
applicazione finalmente funzionerà ; pero' queste cose DEVONO essere 
rese note a TUTTI in modo che al momento della scelta del fornitore adsl 
a cui abbonarsi, possa fare la la loro scelta.
Non sto facendo,a differenza di altri, nessuna crociata contro fastweb , 
vorrei solo mettere in evidenza la diversità.
L'unco astio diciamo personale è con la gestione commerciale e il 
trattamento della vecchia clientela,ma questo è OT e non è un parametro 
valutativo di scelta per un nuovo cliente quindi lo tengo ben fuori da 
questa discussione.
COME CI MANCANO DELLE CERTE FAQ AGGIORNATE :)  (è una bonaria battuta e 
non una frecciatina sia chiaro, quello che è stato fatto a suo tempo è 
già molto di piu' del non avere in mano il nulla a maggior ragione in 
quanto realizzato volontariamente e con passione).
Penso che non ci sia persona che non abbia apprezzato tale lavoro e 
anche altri meno noti putroppo non aggiornati anche loro.


Ho anche provato attivando l'IP pubblico da remoto e poi mandando il
pacchetto a tale IP ma finora non sono riuscito a farlo funzionare.
Non si tratta di una limitazione da poco.
Il metodo che suggerisci via telefono fastweb è una specie di wake on
ring?
S

 questa discussione.
Non è un parametro perchè se ne fregano, non perchè non possano
considerarlo. Non dico andarsi a vedere l'assetto socetario ma comunque
valutare il prodotto e le politiche aziendali. Ho come l'impressione che
l'unico parametro degli utenti fastweb sia solo il taglio di banda e se
così fosse non si può non affermare che il livello della clientela è
piuttosto basso. Decretando tra l'altro il successo di un pasticcio
informatico come la rete fastweb. Come non essere scettici?
-- 
X

 
Esatto, bruttissima ma possibile

 0 a 1 :)
Trip cambia poco la sostanza. Non e' che l'utente medio deve essere
obbligato a fare tutto questo casino per fare una telefonata con Parla.it.
E se probabilmente sapesse tutto cio' eviterebbe come la peste di abbonarsi
a Fastweb residenziale, visto che e' l'UNICO provider in Italia che si
ostina a NON vendere Interent, ne' telefonia, ma spacciandola per tale.

 ring?
Decisamente WOR, che puo essere anche effettuato non necessariamente 
impegnando la linea fonia FW = e' infatti possibile usare a tal scopo un
adattatore ATA VoIP configurato 
p.es
. con i parametri SIP + Stun del
servizio FreeNumber di Messagenet (servizio gratuito per la sola
ricezione).
In questo modo si evitano accensioni indesiderate in seguito a chiamate
in ingresso sulla linea fonia FW.


 utilizzato affinchè l'autenticazione avesse successo ?
l'importante e' utilizzare ESP come protocollo e non AH se utilizzi il 
Transport mode. AH infatti autentica anche l'header del protocollo IP, 
mentre ESP autentica solo il payload. Quindi, visto che il NAT modifica 
l'header, se usi AH il server  esterno rifiutera' sempre tutti i pacchetti.
Nei vari clients l'opzione ESP di solito e' indicata come "enable NAT" o 
qualcosa di simile.
Altra possibilita' e' utilizzare la modalita' tunnel con TCP come 
protocollo di trasporto e non UDP. Se usi TCP il NAT router e' in grado 
di comprendere la sessione e quindi puo' permettere i pacchetti di 
ritorno con maggiore probabilita' di successo.
Ovviamente per funzionare tutto quanto e' necessario che il server 
supporti le varie modalita' di autenticazione. Cioe' se l'IT manager ha 
deciso che il protocollo di auth e' solo AH in transport mode, allora 
non c'e' niente da fare.
Ciao
Marco
Ciao
Marco

 non c'e' niente da fare.
Il manager it sarebbe disposto ANCHE a modificare la cosa semprechè il 
sistema in uso windows 2000 server lo supporti.
Se occorre unn upgrade a 2003 server, allora non ci sarà nulla da fare 
almeno per 6 mesi ....

 wrote in message 
news:kFKxh.10972$wO2....@tornado.fastwebnet.it...

non so se w2k o supporti, ma se supporta IPSec, AH e ESP sono proprio la 
base. Al limite usa un client ad hoc o un sistema di VPN esterno.
Ciao
Marco 

 - 
http://www.voip-info.org/wiki-STUN
Questo è SIP ma loro dichiarano incompatibile con fastweb
http://www.ehiweb.it/telefonia/faq.php


"Se sono cliente Fastweb, posso attivare i servizi VoIP?
No, Fastweb utilizza un sistema di trasmissione dati incompatibile con i 
nostri servizi."
Come volevasi dimostrare: il VOIP di Fastweb e la configurazione di rete 
sono del tutto proprietari - e anche per questo la qualita' del servizio 
telefonico e' nettamente piu' scadente di quella di un normale provider 
VOIP, come tutti gli utenti Fastweb sprovvisti di paraorecchi sanno bene.

 Questo č SIP ma loro dichiarano incompatibile con fastweb
Non sono sinceri ;).
Da connessioni MAN FW (Residenziali/SOHO e PMI senza opzioni Address)
funzionano senza problemi servizi VoIP su protocollo SIP in modalita'
NAT traversal, appoggiandosi a STUN Server oppure a X-Tunnel, sia
utilizzando client SIP software che adattatori HW per il collegamento di
apparecchi telefonici o terminali VoIP.
La nota di ehiweb e' fuorviante, visto che semmai avrebbero dovuto
scrivere che alcuni ATA HW da loro forniti NON supportano l'appoggio a
server STUN (ed infatti non prevedono la configurazione in tal senso).
Utilizzando invece client SW o ATA HW con supporto STUN & appoggiandosi
ad uno dei server pubblici STUN indicati su :
==
- 
http://www.voip-info.org/wiki-STUN
==
NON vi sono affatto problemi su linee FW MAN con i loro parametri SIP
(vedasi 
p.es
. test con VivaVox Free e client SIP con supporto STUN).


 Non sono sinceri ;).
E direi forse stupidi visto che alle condizioni da te descritte e' 
possibile.
Ma magari anche no :
Probabilmente non vogliono rogne della serie "problematiche extra" e 
fatti i calcoli i potenziali clienti fastweb sarebbero una percentuale 
minima = non vogliamo rogne

Trip65 ha scritto:

Inoltre una ultima nota che ho letto alla fine che recita piu' o meno :
Il vari software Voip lavoreranno bene ma la qualita' non sara' mai 
paragonabile e quella ottenuta con l'adattatore da noi fornito di X marca.
E manca quel famoso supporto.
Quindi questioni commerciali

 Se sono cliente Fastweb, posso attivare i servizi VoIP?
Forse ho capito male, ma io uso tranquillamente Skype per telefonare.

 server STUN (ed infatti non prevedono la configurazione in tal senso).
Se e' cosi' perche' mai dovrebbero privarsi della clientela Fastweb, che
inizia ad essere numericamente rilevante? Evidentemente e' perche' LORO
SANNO che avrebbero problemi con le configurazioni non standard di Fastweb
e preferiscono stargli alla larga.

 marca.
Dipende dai sistemi SIP SW/HW usati & dalle relative impostazioni = pure
questa nota e' scritta IMHO in modo fuorviante, visto che non tiene
conto delle differenze tra i vari client SIP (ved. impostazione lato 
utente dei codec in modo fisso e/o con definizione dell'ordine di
scelta/uso) tanto a livello commerciale quanto *free*.


 e preferiscono stargli alla larga.
Secondo me per questo :
1) Appunto configurazioni piu' complesse e clientela problematica da 
stare alla larga e cmq poca in quanto hanno già il voip fastweb
2) Partnership con l'azienda che fornisce gli adattatori da loro 
proposti i quali NON consentono tali configurazioni. E ovviamente si
spinge in quel senso : convincere il piu' possibile tutti ad usare il 
materiale da loro commercializzato.
Un'altra azienda del tutto simile invece non entra volutamente 
sull'argomento clienti fastweb limitandosi indicare che il loro servizio 
per funzionare necessita l'apertura di qualche porta.
Ma se scrivi una email al loro supporto spiegando la tua situazione di 
cliente fastweb, indicano piu' o meno le soluzioni proposte da Macs . 
Tuttavia ovviamente ti invitano a prendere in considerazione di disporre 
di connettività diretta con loro facendo leva sul prezzo e che di queste 
problematiche non se ne vedranno mai (con loro).
Anche loro commercializzano telefoni voip e adattatori, quindi una 
politica diversa.
Altri ancora (tra i quali c'è proprio quel fornitore di voip sicuramente 
incompatibile) ironizzano sulla struttura della rete fastweb :)