Discussione:
ci spostiamo qua (NAT)
(troppo vecchio per rispondere)
Trip65
2007-02-01 14:48:10 UTC
Permalink
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
Luke
2007-02-01 15:22:38 UTC
Permalink
Post by Trip65
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.
kokoko3k
2007-02-01 15:37:23 UTC
Permalink
Post by Luke
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à.
Trip65
2007-02-01 23:16:58 UTC
Permalink
Post by kokoko3k
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à.
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
Macs
2007-02-02 02:22:38 UTC
Permalink
Ciao
Post by Trip65
Non è possibile sottoscrivere MOLTI servizi di telefonia voip *erogati
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 <|
|_| |_/_/ \_\___|___/<|> *FAQ ITGF http://plany.fasthosting.it <|
|>- RST - Plany/MACS -<|> *FAQ GCN http://faq.news.nic.it/ ____<|
Trip65
2007-02-02 07:42:22 UTC
Permalink
Post by Macs
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.
Parlavo appunto di questo, che a differenza di squillo.it che funziona
perfettamente e messagenet che usando SIP DOVREBBE andare (non testato
comunque e il fatto che richieda espressamente aperture di porte sul
router mi lascia qualche dubbio,ma appunto non testato).
La questione è simile a netmeeting quindi : occorre appoggiarsi sempre
su un sistema con ip pubblico H.323 gatekeeper.
Post by Macs
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'
==
- http://www.voip-info.org/wiki/view/NAT+and+VOIP
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 :)
Marc Serafino
2007-02-02 13:23:01 UTC
Permalink
Post by Trip65
Post by Macs
- http://www.voip-info.org/wiki/view/NAT+and+VOIP
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 :)
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.
Trip65
2007-02-15 22:04:58 UTC
Permalink
Post by Macs
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
==
- http://www.voip-info.org/wiki-STUN
Questo è SIP ma loro dichiarano incompatibile con fastweb
http://www.ehiweb.it/telefonia/faq.php
Marc Serafino
2007-02-16 14:59:05 UTC
Permalink
Post by Trip65
Post by Macs
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
==
- 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.
Paolo Palazzi
2007-02-16 18:26:03 UTC
Permalink
Post by Marc Serafino
Se sono cliente Fastweb, posso attivare i servizi VoIP?
Forse ho capito male, ma io uso tranquillamente Skype per telefonare.
Macs
2007-02-16 16:06:41 UTC
Permalink
Ciao
Post by Trip65
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).
--
|¯ \/¯ | /¯\ /¯__/¯__|<|> *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/ ____<|
Trip65
2007-02-16 18:20:22 UTC
Permalink
Post by Macs
Ciao
Post by Trip65
Questo è SIP ma loro dichiarano incompatibile con fastweb
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
2007-02-16 18:23:51 UTC
Permalink
Post by Trip65
Post by Macs
Ciao
Post by Trip65
Questo è SIP ma loro dichiarano incompatibile con fastweb
Non sono sinceri ;).
E direi forse stupidi visto che alle condizioni da te descritte e'
possibile.
Probabilmente non vogliono rogne della serie "problematiche extra" e
fatti i calcoli i potenziali clienti fastweb sarebbero una percentuale
minima = non vogliamo rogne
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
Macs
2007-02-17 04:21:35 UTC
Permalink
Ciao
Post by Trip65
E direi forse stupidi visto che alle condizioni da te descritte e'
possibile.
Ma magari anche no
Semplicemente i signori di Ehiweb sono al corrente dei problemi di
registrazione legati all'impostazione di STUN server sugli ATA Fritz!
(quando implementabile in modalita' Expert), e che sono stati rilevati
tanto con altri gestori SIP quanto in scenari NAT-ted anche su linee
di altri provider = e' sufficiente una ricerca sul gruppo di discussione
it.tlc.telefonia.voip, usando le chiavi stun e fritz!.

Usando infatti HW ATA o client SW con supporto corretto modalita' STUN :
==
- http://www.voip-info.org/wiki/view/STUN+clients
- http://www.sjlabs.com/sjp.html
==
& appoggiandosi a server STUN forniti dal provider VoIP o pubblici :
==
- http://www.voip-info.org/wiki/view/STUN
==
NON vi sono problemi per l'utilizzo di servizi VoIP basati su protocollo
SIP su linee MAN FW, qualunque sia il fornitore/rivenditore (Messagenet,
Skypho, Squillo, Vira, VoipStunt/SipDiscount, Digitel, Ehiweb, etc.).

Ehiweb NON puo garantire il corretto funzionamento in configurazione
STUN per tutte le offerte commerciali VivaVox che includono HW Fritz!,
e conseguentemente NON fornisce i parametri di impostazione in tal
senso.

D'altronde e' piu' conveniente per Ehiweb - anche in termini d'immagine
come fornitore di servizi - imputare 'erratamente' una limitazione ad un
provider terzo di connettivita' piuttosto che ai prodotti HW forniti in
associazione ad alcune sue offerte ;).
Post by Trip65
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.
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*.
--
|¯ \/¯ | /¯\ /¯__/¯__|<|> *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/ ____<|
Marc Serafino
2007-02-16 21:24:00 UTC
Permalink
Post by Macs
Post by Trip65
Questo è SIP ma loro dichiarano incompatibile con fastweb
Non sono sinceri ;).
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).
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.
Trip65
2007-02-17 08:35:34 UTC
Permalink
Post by Marc Serafino
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.
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 :)

Hozomeen
2007-02-01 17:30:28 UTC
Permalink
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
Trip65
2007-02-01 20:06:52 UTC
Permalink
Post by Hozomeen
funziona eccome nella sua forma standard, visto che lo standard ha previsto
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
Macs
2007-02-02 01:28:15 UTC
Permalink
Ciao
analizzando il traffico di rete appariva un chiaro blocco di
protocollo (non di porta) usando il nat convenzionale dell'utenza
residenziale.
Quello che rilevi corrisponde al mancato VPN passthrough in uscita dalla
rete FW a livello di protocollo IP dei pacchetti, che e' peraltro
presente non solo con IPSec ESP (IP 50) ma anche con GRE (IP 47).

Tale e' infatti il motivo per cui non sono effettuabili connessioni PPTP
base/standard da utenze MAN FW, mentre lo sono senza problemi da scenari
NAT Hidden/Dynamic M-1 con PPTP/GRE Passthrough.

Usando IPSec NAT-T - ESP, oltre all'utilizzo di UDP Encapsulation per
ESP cambia quindi anche la gestione IKE :
==
http://www.isaserver.org/articles/IPSec_Passthrough.html
http://www.microsoft.com/technet/community/columns/cableguy/cg0802.mspx
==
proprio per far fronte a scenari problematici causati dal NAT e/o dalla
gestione lato rete di IPSec Passthrough.
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.
In tal caso tu non utilizzi infatti la policy automatica IPSec degli OS
Windows in associazione all'accesso remoto via L2TP, visto che l'hai
disabilitata a livello di registro di sistema & hai definito manualmente
dalla console snap-in MMC un apposito criterio di protezione tramite
chiave condivisa per gestire autenticazione/negoziazione a livello di
protezione del trasporto.

Qualora questo non venga fatto in uno scenario NO IPSec NAT-T con client
su connessione MAN FW, l'accesso tramite L2TP fallisce = non viene
infatti stabilita la protezione del trasporto, per cui non viene avviato
PPP per effettuare la negoziazione del tunnel L2TP.
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
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/ ____<|
Hozomeen
2007-02-03 18:07:51 UTC
Permalink
Ciao,
Post by Trip65
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.
<cut>
Post by Trip65
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 ?
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
Trip65
2007-02-05 18:26:09 UTC
Permalink
Hozomeen ha scritto:
Cioe' se l'IT manager ha
Post by Hozomeen
deciso che il protocollo di auth e' solo AH in transport mode, allora
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 ....
Hozomeen
2007-02-06 10:50:47 UTC
Permalink
Ciao,
Post by Hozomeen
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.
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 ....
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
Slocum
2007-02-01 23:36:15 UTC
Permalink
Post by Trip65
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
Non si può accendere il pc da remoto tramite WOL

S
Trip65
2007-02-01 23:40:56 UTC
Permalink
Post by Slocum
Non si può accendere il pc da remoto tramite WOL
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 ..
Trip65
2007-02-01 23:46:21 UTC
Permalink
Post by Slocum
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
slocum
2007-02-02 08:54:28 UTC
Permalink
Post by Trip65
Post by Slocum
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
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
Trip65
2007-02-02 09:02:01 UTC
Permalink
Post by slocum
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.
Qualcuno c'è riuscito (dice) a quanto pare,non ricordo proprio,
interpondendo un router o qualche tecnica simile.Era su fibra .
Se fai delle ricerche forse proprio su vecchi post di questo news trovi
l'argomento.
Post by slocum
Il metodo che suggerisci via telefono fastweb è una specie di wake on
ring?
S
Esatto, bruttissima ma possibile
Macs
2007-02-02 14:13:23 UTC
Permalink
Ciao
Post by slocum
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 Wake On Wan diretto puo essere fatto senza reali intoppi direttamente
sul computer da accendere da remoto solo su connessioni con IP Pubblico
statico & senza filtri a livello di rete del provider per quanto
riguarda l'invio in broadcast di alcuni datagrammi UDP (allo scopo di
proteggere la rete da eventuali smurf o denial of service) -> vedasi
capitolo 2.8.7 delle FAQ citate in firma.

Altrimenti, pur in assenza di filtri UDP Broadcast sulla rete del
provider, e' richiesto un maggior impegno di configurazione -> cio' vale
sia per le connessioni di altri provider con IP pubblici dinamici che
(maggiormente) per quelle FW.

Si rende infatti necessaria la presenza di un apparato acceso/associato
ad un IP pubblico per l'inoltro del magic packet WOL -> tale apparato
puo essere un altro computer oppure un router, e l'IP puo esservi
assegnato direttamente oppure associato ad un altro host.

L'associazione puo essere effettuata tramite tunnel VPN o SSH, oppure
tramite NAT/PAT diretto su rete FW con un IP Pubblico FW, vedansi IP
Pubblico IPPD per le utenze residenziali/SOHO e opzioni Address per le
utenze Business/Aziendali.

A meno che si stia usando un router che preveda la funzione di WOL
Proxy con l'indicazione del MAC Address del client LAN da 'svegliare',
e' necessario definire il port-forward verso l'indirizzo di broadcast
della subnet LAN dei client per le connessioni in ingresso su una o due
porte UDP (a seconda che sul sistema di inoltro sia consentito il
traffico Subnet Directed Broadcast).

Antonio Martino p.es. aveva indicato ad Aprile 2006 il successo in uno
scenario con IPPD attivato da remoto per un suo computer previamente
registrato, usando :
==
- MC-WOL come WOL client - http://www.matcode.com/wol.htm
- Router con Subnet Directed Broadcast consentito
- Impostazione inoltro UDP 65535 su IP broadcast della sua LAN *.*.*.255
- Ulteriori info su http://tinyurl.com/22npsx

Negli anni precedenti (ved. FAQ) io ho invece preferito evitare l'uso di
client software, concentrandomi sull'utilizzo di pagine web per
l'accensione da remoto di sistemi prima associati ad IP Pubblici via
tunnel protetti (SSH e VPN) e successivamente via NAT/PAT -> questa e'
p.es. una configurazione funzionante :
==
- Pagina web WOL over Internet - http://www.dslreports.com/wakeup
- Inoltro porta UDP 9 su IP broadcast LAN RFC-1918
- Inoltro porta UDP 32767 su IP broadcast LAN RFC-1918
Post by slocum
Il metodo che suggerisci via telefono fastweb è una specie di wake on
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.
--
|¯ \/¯ | /¯\ /¯__/¯__|<|> *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/ ____<|
Trip65
2007-02-02 08:04:53 UTC
Permalink
Post by Luke
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.
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.
Blak
2007-02-02 08:56:06 UTC
Permalink
Post by Trip65
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.
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
Continua a leggere su narkive:
Loading...