Newsgroup: it.tlc.gestori.fastweb
Titolo: porta udp 5060 in uscita

Qualcuno ha effettuato test e prove che porterebbero a concludere che il 
traffico upd da un pc in rete fastweb verso un server (quindi porta in 
uscita) SIP siano cappate/menomate se non addirittura bloccate ?

 uscita) SIP siano cappate/menomate se non addirittura bloccate ?
cioè vuoi sapere se si possono usare telefoni IP od ATA SIP con 
FastWeb?
Ho capito bene?
-- 
Un'importante *precisazione* sui tagli di ricarica Vodafone
su  
http://marcoge.splinder.com

 
Non esattamente . Semplicemente noto che utilizzando un particolare 
telefono ip con connettività fastweb fibra , il comportamento dello 
stesso cambia a seconda di :
1) Se collegato direttamente alla cpe/hag (no audio in tx)
2) Se collegato tramite ulteriore NAT (funzionamento impeccabile)
3) Perchè il medesimo apparato, che presenta problematiche sulle 
chiamate in uscita (audio muto), quando collegato direttamente alla cpe 
quando chiama un SIP sulla 5060 , scompaiono e tutto va bene quando 
chiamano un fornitore SIP che da' il servizio sulla 5061.

 che da' il servizio sulla 5061.
Boh, io ho un ATA (PAP2) sulla 5060 (e così pure il softphone) e tutto 
va bene (GE, ADSL 6Mb -alla faccia di MS-)


 il giovedì 10/01/2008 alle 
16.23.52 ha scritto su it.tlc.gestori.fastweb :

confermo, ha IP 5.XXX.XX.X33 (ho pure creato un collegamento sul 
desktop per eventuali modifiche degli account)


 
A questo punto mi dici marca e modello cosi' do' un'occhiata al manuale 
e ai settaggi vari che ha ?

 settaggi vari che ha ?
Linksys PAP2 configurato con due account EuteliaVoip (in passato ho 
usato anche sipdiscount ma non con gran soddisfazione):
http://tinyurl.com/3xj4fq


 
http://tinyurl.com/3xj4fq
Setaggi piu' o meno identici a quelli da me utilizzati sull'ip phone.. 
Non mi rimane che andare di tcpdump e fare confronti quando uso il 
softphone e l'ip phone
Putroppo non è possibile spoofare il mac mannaggia, sarebbe stato 
interessante

 Putroppo non è possibile spoofare il mac mannaggia
Perchè no?!

 Perchè no?!
Intendo che non è possibile cambiare mac al telefono , ovviamente posso 
fare il contrario , assegnarlo al pc e vedere se il difetto si rigira.
Bisogna partire dal concetto : perchè se natto il telefono va tutto, 
cosa cambia oltre al mascheramento (ininfluente) dell'ip ?

 cosa cambia oltre al mascheramento (ininfluente) dell'ip ?
Se hai un linux box, settalo in modalità bridge piuttosto che in NAT e 
sniffa il traffico del telefono.

 va bene (GE, ADSL 6Mb -alla faccia di MS-)
Alla faccia mia? Sai che ne ne frega a me visto che Fastweb non e' il mio
unico provider e che per altro il VOIP con Fastweb a me funziona
perfettamente. Solo non ho ancora provato a connettere l'IP301 o un PAP
direttamente alla CPE.


Guarda Trip che un PAP non e' esattamente come un telefono. Ha un IP e uno
strato di NAT pure lui. Quindi ovvio che vada.

 strato di NAT pure lui. Quindi ovvio che vada.
Ma lui dice che ha preso un ip 5.x.x.x della rete Genovese Fastweb , 
esattamente come succederebbe al telefono 301 (che per altro ha anche 
lui la parte lan con nat ).
Visto che pare tu lo abbia, quando ti capita , collegalo alla cpe e 
prova a chiamare : vedrai che il telefono del corrispondente suona , ma 
tu non senti nulla, neanche il segnale di libero.

lorenzodes ha scritto:

Sto provando ma ho delle difficoltà senza scompigliare la lan.
Nel frattempo basta google : ip-301+fastweb+eutelia .
Non si puo' a questo punto negare che il problema non esista e dire che 
va tutto bene.

 Ma lui dice 
http://img27.picoodle.com/img/img27/4/1/11/f_pap2m_2bac661.jpg


 Alla faccia mia? Sai che ne ne frega a me
vista la crociata personale che svolgi contro FastWeb...
Onestamente io non comprendo nè chi difende un gestore/negozio/servizio 
ad ogni costo ma neppure chi, al contrario, si fa in quattro per 
denigrarlo.
Io con FW mi trovo bene *ora*, se la situazione muterà cambierò 
gestore.
Non inondo it.economia.banche nè con messaggi di lode per la mia 
attuale banca nè con crociate contro la precedente (che peraltro mi 
spennava in un modo feroce)


 tu non senti nulla, neanche il segnale di libero.
Stai usando uno STUN ?
-- 
Saluti, Federico
http://www.quaqo.org

 va tutto bene.
Dalla tua descrizione del problema non mi pare che si possa trattare 
di un semplice caso di "porta chiusa". Mi pare più probabile qualche 
giochino sul MAC address (cosa ancora più "sporca" e scorretta IMHO).



Il SIP dietro NAT ha bisogno semplicemente di alcuni workaround per 
sapere qual è il suo indirizzo pubblico e fare hole-punching del firewall 
(tipicamente lo stun server risolve tutto).
Ma tutto sta se il telefono si accorge di averne bisogno o no. Magari il 
tuo telefono con IP 192.168.x.x capisce al volo che è NAT-tato, mentre 
con IP di MAN di Fastweb "pensa" stupidamente di essere in rete e non usa 
lo stun. Puoi dumpare il traffico?
Comunque non sono i telefoni SIP che hanno questo problema del "non 
funziona sull'HAG ma funziona se c'è un secondo NAT di mezzo". Anche 
giochi online come PES 2008 su Playstation 3 hanno gli stessi sintomi.
La prova del nove è cambiare il DHCP (lato LAN ovviamente) del tuo router 
e fare assegnare indirizzi con classe tipo 1.x.x.x. Vedi se cambia 
qualcosa o no.
-- 
Conte Frobenius

"quaqo" <ntp_at_q...@quaqo.invalid> ha scritto nel messaggio
news:2058366.b...@quaqo.org...

Allora , lo stun è impostato , quanto ad non usarlo o usarlo , devo fare un
dump del traffico.
Forse appunto non viene usato quando il telefono trova un ip non idoneo per
le reti private.
Questa cosa unita al fatto, che , ad alcuni funziona , potrebbe essere un
indizio.

 Conte Frobenius
Bingo !!! Non va !!!
Non piacciono questi ip fastweb al telefono in questione.
Ecco perchè il softphone va e anche altri telefoni
Ed è probabile che non abiliti lo stun , l'effetto è il medesimo qualora
dietro nat lo disattivassi.

 ha scritto nel messaggio
news:kcak55x...@news.nixstation.ltd...

No, ho usato quel mac sul softphone e va, ma forse adesso abbiamo centrato
il problema.
Quel firmware non attiva lo stun se il telefono ha un ip di una classe
ritenuta pubblica e non lan .
Ecco cosa succede ad usare ip illeciti....

Se si usa ad es il servizio sip di messagenet che opera sulla 5061 non ci
sono problemi, forse lo stun qua non serve , si vede che qualche malefatta
sulla 5060 la fanno comunque evidentemente

 stun , l'effetto  il medesimo qualora dietro nat lo disattivassi.
Benissimo, hai appena verificato che si tratta di un bel bug software del 
telefono, comunque.
-- 
Conte Frobenius



5061 non è una porta standard, quindi può darsi che sia un altro 
"suggerimento" che il telefono interpreta come "c'è qualcosa di strano in 
questa rete dove sono attaccato, meglio ricorrere allo STUN!". Da degli 
idioti che hanno programmato un software che si affida alla classe 
dell'IP per fare una scelta del genere, non possiamo dare nulla per 
scontato! :P
In questo caso, la prova finale la ottieni solo dumpando il traffico; 
penso che il sistema più facile sia procurarsi uno switch ethernet di 
quelli piccolini a 4-8 porte, attaccarci telefono, router, e PC, e poi 
dumpare il traffico usando la modalità promiscua.
-- 
Conte Frobenius

 telefono, comunque.
Veramente si tratta di abuso da parte di Fastweb nell'utilizzo di subnet
non assegnategli dal RIPE che il telefono rietiene _giustamente_ pubbliche.



Sono le conseguenze all'utilizzo di IP ritenuti pubblici e mai assegnati
dal RIPE che il telefono correttamente interpreta come indirizzi Internet e
non locali non attivando lo STUN.



Sì è vero. Se Fastweb avesse rispettato le classi "ufficiali" sicuramente 
questo problema non ci sarebbe stato.
Ma questo non rende il telefono meno colpevole neppure dell'uno per mille 
Il protocollo del NAT ovviamente non parla di convenzioni di assegnamento 
di classi di IP decise dall'ICANN per la rete Internet. Un software che 
implementa i protocolli non dovrebbe basarsi anche su convenzioni 
(seppure a livello mondiale) perché starebbe travisando i livelli di 
definizione.
Ti faccio un esempio: io posso costruire un intera Intranet totalmente 
scollegata da Internet (al 100%). Molte aziende business hanno reti del 
genere. All'interno di questa rete (che chiamo Intranet perché basata su 
protocolli IP e TCP), posso assegnare gli indirizzi IP come meglio mi 
pare, perché non devo rispettare le assegnazioni ICANN per interoperare 
con Internet. E all'interno di questa rete, un software che assume che 
"essere dietro NAT" vuol dire avere una classe di IP tipo "192.168.x.x.", 
sicuramente avrà problemi.
Quindi riassumendo: il software è buggato perché dà per vera una 
convenzione che comunque Fastweb non avrebbe dovuto violare.
-- 
Conte Frobenius

 Quindi riassumendo: il software è buggato 
se fosse buggato sarebbe appunto difettoso, ovvero avrebbe comportamenti
diversi da quelli previsti. Semmai è la mancanza di una feature il
problema.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 Peccato che la rete Fastweb sia connessa ad Internet
Ma soprattutto un NAT in una rete come quella descritta da te non ha motivo
di esistere.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 problema.
Chiamalo come ti pare, ma il telefono ha colpa tanto quanto Fastweb. A me 
non sarebbe passato neppure per l'anticamera del cervello di scrivere del 
codice tanto stupido che guarda la classe di IP per capire che succede. 
E' segno di grossa incompetenza comunque.
-- 
Conte Frobenius

 E' segno di grossa incompetenza comunque.
Questa frase è segno di grossa incompetenza. E' una scelta progettuale,
condivisibile o meno, così come lo è quella di fastweb (perchè secondo il
tuo modo di pensare allora anche la rete fastweb è "buggata" e fatta da
incompetenti).
PS per Trip: hai appena verificato che si tratta di un bel bug di fastweb,
comunque. (semicit.)
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 da incompetenti).
E' una scelta progettuale non basata esclusivamente sulla definizione dei 
protocolli sui quali si appoggia (NAT, STUN, o SIP), ma anche su 
un'assunzione esterna storica che potrebbe essere modificata (cioè 
l'assegnazione corrente di IP stabilito dall'ICANN).
Ti faccio una domanda: supponi che domani, per un qualunque motivo, 
l'ICANN decide che la classe 2.x.x.x (non assegnata) deve diventare una 
classe dedicata alle rete locali come la 192.168.x.x. E' nel suo potere 
farlo (e ci sono state in questo senso anche mozioni da gruppi di ISP che 
si basano su NAT che hanno bisogno di più classi di IP). Ecco che il 
software del nostro telefono, per come è stato progettato non funzionerà 
correttamente con quella classe.
Ogni volta che l'ICANN compierà una scelta su una classe non assegnata, 
Fastweb dovrà correre ai ripari (colpa loro) e i programmatori di quel 
telefono dovranno fare altrettanto (colpa loro).
Io non ci vedo molte differenze. Assumere che il caso di NAT è limitato a 
10.x.x.x o 192.168.x.x. è sbagliato esattamente come usare per il NAT 
classi reserved. E' lo stesso errore dall'altra parte dello specchio. 
Sulle classi non assegnati non si può assumere nulla proprio perché sono 
non assegnate.
-- 
Conte Frobenius

 telefono dovranno fare altrettanto (colpa loro).
Si ma con due grosse differenze:
- la probabilità che l'ICANN rilasci una nuova classe ad uso privato è
tendente a 0 mentre la probabilità che IANA assegni le ultime classi
rimaste ai RIR tende a 1.
- con le scelte fatte la probabilità che chi ha comprato il telefono non
riesca ad usarlo per colpa di queste, in tutto il mondo, è bassa, molto
bassa. Approssimando: funziona.
Se poi vogliamo parlare di congiunzioni astrali ti lascio continuare da
solo.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 bassa. Approssimando: funziona.
Uhm sì, ripensandoci penso di aver preso un granchio. Alla fine non è una 
scelta così sbagliata come mi sembrava all'inizio. Grazie per aver 
insistito! :P
-- 
Conte Frobenius

 non assegnategli dal RIPE che il telefono rietiene _giustamente_
pubbliche.
E qui , ancora una volta , vuoi per colpa di un bug , di una feature mancata
, per qualsiasi cosa tu voglia , HAI UN PROBLEMA a causa di questa
architettura fastweb..
Perchè siamo d'accordo che tutte le volte che ci sono delle "complicazioni"
si va sempre a sbattere li ??
E stavolta non è un nerd che sta avendo un problema : è la casalinga di
Voghera che ha comperato via internet un apparato in offerta che funziona
senza problemi su tutte le adsl senza bisogno di alcuna cfg particolare
(sino a che non hai fastweb) e si aspetti che funzioni.
Casomai è vero il contarario : il nat non costituisce problemi al nerd di
turno che si arrangia sempre alla meglio , ma è disturbante per un normale
utente sprovveduto che non sa nulla .

Il telefono è bacato punto..
Se io barro la casella "attiva stun" lui lo deve fare senza discutere, non
deve ragionare , no non lo attivo perchè secondo me su un ip annunciabile
non è necessario.
Altrimenti non mettevano manco la possibilità di intervenire.
Tu mi dirai : come fa a capire se sei dietro nat ? appunto non lo deve
capire , deve comportarsi come l'utente lo ha configurato ovvero uso lo stun
se lo dichiaro abilitato , non lo deve usare se non lo abilito.

 normale utente sprovveduto che non sa nulla .
Secondo me a questo punto sarebbe meglio che Fastweb configurasse gli HAG 
per fare da NAT ad una ulteriore rete interna (con configurazione almeno 
dei port forwarding dall'indirizzo MAN alle rete interna). Così 
diventerebbe inutile comprare i router in cascata per il 90% delle 
persona, e si risolverebbe anche questo tipo di problemi.
-- 
Conte Frobenius

 Uhm sì, ripensandoci penso di aver preso un granchio.
Scusa per il tono ma non capivo l'insistenza.
Comunque, tra parentesi, anche nei sistemi operativi Windows viene
applicato lo stesso metodo per creare automaticamente un tunnel 6to4: se
l'interfaccia ha un IPv4 unicast globale viene creata l'interfaccia
virtuale 6to4, altrimenti no.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 se lo dichiaro abilitato , non lo deve usare se non lo abilito.
Ok, pensavo fosse semplicemente "autosensing", rendendo più semplice la
configurazione.
Rimane comunque quanto detto su fastweb.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 per fare da NAT ad una ulteriore rete interna 
Questa è un'idea pessima che si agiunge alla già pessima idea del NAT
fastweb.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 Conte Frobenius
poi come fanno a limitare l'uso a 3 pc a quelli che vanno a consumo ,
sperando sempre , e lo trovano , l'allocco che fa tre attivazioni
contemporanee provocando tripla fatturazione ?
Guarda che non scherzo , vai sul forum e vedi quanta gente attiva due volte
perchè il fratello sta usando un pc ..
Manco il wi-fi ti fanno personalizzare, figurati se ammettessero , secondo
sempre una mentalità demente , che l'utente smanetti nella cpe , cpe che
sono certo che possa essere configurata con nat su indirizzi 192.168.0.0 .
Conta anche i casini che creerebbe l'attivazione di ippd , altro gingillo
fatto per spillare quattrini ..Concedere l'uso della videostation nattata
rendendola trasportabile e flessibile ? Ma scherzi non si puo' fatturare il
servizio "aggiuntivo".A meno che : videostation wi-fi con gestione del
flusso UDP dietro nat : 10 euro per l'attivazione !!
E sarebbe una idea : configurare la cpe con il nat ? Due euro una tantum e
lo puoi fare...
Non vuoi piu' il nat ? Raccomandata con rr per disdire la cosa ,
naturalmente dopo 60 gg si riconfigura in bridge se se lo vuoi prima  penale
di 5 euro ... :)
Ah... il vile denaro ....

 fastweb.
E' come fanno tutti gli altri provider quando ti forniscono un router 
wifi in comodato d'uso. La differenza è che dietro ai comunque il NAT di 
Fastweb, ma questo non cambia nulla rispetto alla situazione precedente; 
mentre invece sembra che avere una macchina direttamente nel NAT di 
Fastweb crei i problemi di compatibilità di cui abbiamo discusso in 
questo thread.
-- 
Conte Frobenius

 questo thread.
Gli altri provider ti permettono però di agire sulle impostazioni del router: 
aprire porte, fare forwarding... magari usarlo anche in modalità bridge.
Il motto di FW, in relazione a tutti i suoi apparati, è "guardare ma non 
toccare".



Sì certo, in questo caso pensavo ad uno scenario nel quale l'HAG fa da 
vero router con NAT *e* le configurazioni di questo tipo sono a 
disposizione dell'utente.
-- 
Conte Frobenius

 questo thread.
Sul fatto che il NAT crei problemi in generale non c'è dubbio.
In questo caso specifico sono gli indirizzi IANA Reserved il problema, non
il NAT.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 caso specifico sono gli indirizzi IANA Reserved il problema, non il NAT.
Problemi che sarebbero aggirati se l'HAG facesse un NAT controllabile 
dall'utente, invece che essere costretti ad aggirarli comprando un 
secondo router in cascata. Cioè quello che stavo dicendo.
-- 
Conte Frobenius

 disposizione dell'utente.
Guarda, il NAT, quando si parla di Fastweb, non è la soluzione, ma il 
problema.
Anche al lavoro, abbonamento aziendale in fibra, mi ritrovo un bel 
Cisco1700 su cui è inibita ogni possibilità di intervento lato utente. 
Per carità, mai avuto un down, la connessione funziona bene ed è 
veloce, ma o ti accontenti di come è impostato, oppure acquisti uno 
dei tanti pacchetti commerciali aggiuntivi che FW ti fornisce con 
grande piacere.
In ufficio, pertanto, noi abbiamo un doppio NAT. Quello classico di 
FW, e quello ulteriore impostato sul Cisco1700. Lo scopo di 
quest'ultimo NON è proteggere l'utente dai worm che bazzicano la MAN 
(il commerciale aveva tentato, invero con scarso successo, di 
vendercela in quel modo), né di mitigare potenziali criticità 
dell'altra NAT, ma di imporre al cliente di dover ricorrere a mamma FW 
per ogni esigenza particolare. Questo secondo NAT è un ulteriore 
limite rispetto a quelli già noti e propri delle connessioni residenziali.
La nostra fortuna è che, almeno per ora, non abbiamo esigenze 
particolari che mal si conciliano con i vincoli di cui sopra.
Questo lungo discorso solo per dire che FW sul NAT, inteso come limite 
nei confronti dell'utenza, basa tutta la sua politica commerciale, per 
cui cambiamenti di rotta mi sembrano alquanto improbabili.

 cui cambiamenti di rotta mi sembrano alquanto improbabili. 
Anche perchè il protocollo di assegnazione IPv4 è saturo (che tra
l'altro sono di tipo C, compreso IP pubblico di fastweb), e IPv6 stenta
a decollare.
BTW i nostri vicini UE viaggiano sull'ordine dei Giga, e da quando in
Italia abbiamo ottenuto la fibra, noi non ci siamo spostati dai 10Mb.
Bah.

 BTW i nostri vicini UE viaggiano sull'ordine dei Giga,
Come no...
Comunque all'estero, oltre ad esserci un mercato diverso, c'è una cultura
diversa.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 dall'utente,
Questa è una cosa inutile.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 propri delle connessioni residenziali.
Sono d'accordo. Infatti alcune aziende con cui collaboro si fanno 
delegare le subnet di IP pubblici sul Cisco (es: 4 IP, di cui 1 rimane 
utilizzabile), e poi fanno NAT dietro i loro server. In pratica il Cisco 
diventa il default gateway della DMZ, ma non fa da NAT.
-- 
Conte Frobenius

 Questa è una cosa inutile.
Questo thread ha appena verificato sperimentalmente il contrario. L'hai 
letto?
-- 
Conte Frobenius

 Probabilmente mi sto spiegando male io. Provo a ripetermi.
Non è necessario, sbagli. Proponi una "soluzione" che crea più problemi di
quelli che risolve ==> non è una soluzione. Anche perchè in questo caso
specifco il problema è l'uso di IP riservati per una rete comunque connessa
ad Internet, quindi la soluzione sarebbe rinumerare (cosa che non avverrà
mai, come anche la tua soluzione).
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 non avverrà mai, come anche la tua soluzione).
So perfettamente quale sarebbe la soluzione perfetta, ma non stiamo 
discutendo di quella.
-- 
Conte Frobenius

 discutendo di quella.
Che senso ha discutere su:
- qualcosa che è peggiorativo
- qualcosa che non avverrà mai
- qualcosa che non è l'origine dei problemi con fastweb?
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 - qualcosa che non è l'origine dei problemi con fastweb?
Perché non sempre (purtroppo) l'unica cosa di cui ha senso ragionare è 
come si risolvono tutti i problemi alla radice. Spesso non è possibile 
risolvere i problemi alla radice, ma ha comunque senso documentarsi su 
possibili soluzioni parziali, workaround o alternative.
-- 
Conte Frobenius

 possibili soluzioni parziali, workaround o alternative.
Ti ho già risposto anche a questo: non è una soluzione, non è un
workaround, inutile stare a parlarne.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 commerciale (anzi...) ==> quindi non si fa. Fine.
Molti provider offrono router che fanno NAT con wi-fi integrato in 
comodato d'uso gratuito. Anche loro non ne traggono nessun vantaggio?
-- 
Conte Frobenius

 Anche loro non ne traggono nessun vantaggio?
A farti pagare un oggetto in comodato? Certo.
Peccato che fastweb ti dia già l'opportunità di collegare più computer
quindi non deve darti niente di più di quello che già ti fornisce.
Comunque guarda, ti do ragione, così la finiamo qua e siamo tutti contenti.
Sapere 3-4 cose non vuol dire automaticamente averle capite e saperle
utilizzare.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 comodato d'uso gratuito
E aggiungo: molti provider (o meglio, praticamente la totalità) portano a
casa dell'utente un IP pubblico. Allora, sulla base del tuo ragionamento,
mi aspetto che fastweb si adegui e tolga il NAT (il vero problema).
Fammi un fischio quando avverrà, ok?
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 saperle utilizzare.
Mi dispiace che tu debba ricorrere alle offese per chiudere un thread. 
Anche se non siamo d'accordo, non c'è bisogno di supporre che l'altro sia 
uno che non ci arriva.
-- 
Conte Frobenius

 problema). Fammi un fischio quando avverrà, ok?
Qui stai proprio esagerando.
Il mio ragionamento non era certo "Fastweb dovrebbe adattarsi a quello 
che gli altri provider fanno". Non hai letto con abbastanza attenzione o 
voglia di capire.
-- 
Conte Frobenius

 che se non ci fosse del tutto il NAT (siamo d'accordo), ma meno di ora.
E qui invece il tuo ragionamento è fallato. Il secondo NAT, per quanto 
riguarda le utenze residenziali, a FW non conviene, perché 
azzopperebbe la famosa rete interna. Quanto a dare all'utente il 
controllo sul NAT... suvvia, gli HAG fastweb sono sacri ed inviolabili 
ed è già tanto che ti permettono di spolverare il tuo ogni tanto. Non 
ti danno neppure quel minimo accesso necessario a verificare i 
parametri ADSL e lo stato della linea, figuriamoci il pieno controllo 
su un ipotetico NAT!

 La mia intelligenza è sufficiente per te?
Hai scritto ancora una volta un sacco di inesattezze e cose prive di senso.
Ti consiglio di lasciar pedere, sul serio.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 senso. Ti consiglio di lasciar pedere, sul serio.
Già. Per fortuna che ci sei tu ad illimunarci con le tue risposte!
-- 
Conte Frobenius