Cercando un poco su google si incappa facilmente in post di utenti di Fastweb che dichiarano di sospettare che quest’ultima filtri il protocollo SIP, rendendo di fatto difficile l’utilizzo di tanti provider VoIP che stanno nascendo in questi ultimi anni.

Io devo dire che sinceramente non ho trovato questi problemi, e, nat a parte con i suoi casini, un client SIP dentro la rete fastweb mi ha sempre funzionato egregiamente.

Oggi pero’ mi sono scontrato con un fatto sconcertante con il suddetto ISP.

Prima spieghiamo la situazione: un mio cliente, che possiede in ufficio un contratto “small businness”, decide di piazzare un Asterisk server sul quale ricevere delle chiamate via SIP. Per fare questo, essendo fastweb un grande NAT, compra il servizio “IP Pubblico”, e si fa assegnare 4 indirizzi ip pubblici, routati verso una macchina interna alla propria LAN (badate, non nattati o in pat, routati!)

Detto fatto, ci assegnano 4 indirizzi, rediretti verso la nostra macchina interna con ip 192.168.0.7, macchina linux che funge da router e redirige gli ip pubblici a 4 macchine dietro di essa. Tutto sembra funzionare a meraviglia, impostati gli ip alias sulle macchine che dovevano essere raggiungibili dall’esterno, queste ultime sono effettivamente raggiungibili, ci entro in ssh, mi apro apache, faccio tante cosine e tutto funziona.

Allora installo asterisk, mi chiamo via IAX2, funziona.

Configuro asterisk per stare in ascolto con chan_sip sulla porta udp 5060 (la porta standard per SIP) provo a registrarmi con un client dall’esterno e… uhmm… nulla, non si registra. Strano, funziona tutto… perche’ non si registra?

Decido quindi di tracciare un po’ il traffico, mi piazzo sul router, avvio tcpdump, entro in una mia macchina esterna a fastweb, e avvio un hping2 -2 -p 5060 . Niente, non c’e’ traccia di pacchetti che arrivino al mio router. Strano. Magari e’ il firewalling. Cancello TUTTE le regole di iptables, tanto per essere sicuri. Nulla, non arriva nulla.

Cambio porta ad hping2, provo la 5061, e i pacchetti arrivano. Provo un po’ di porte random, e i pacchetti arrivano. Riprovo la 5060, il nulla. Decido quindi che il problema e’ in Fastweb, e quindi chiamero’ l’assistenza domani. Domani e’ oggi.

Siamo quindi arrivati a questa giornata infame. Stamattina, appena arrivato in ufficio, chiamo il 192194, servizio clienti di fastweb per le aziende. Spiego il problema all’operatore del call center, che apre un ticket e mi fa lasciare il numero di telefono, dicendomi che mi fara’ richiamare da un tecnico.

Dopo 2 ore non mi ha chiamato nessuno, quindi richiamo il 192194. Di nuovo mi dicono che un tecnico mi chiamera’ a breve, ed effettivamente dopo circa 10 minuti ricevo una telefonata.

Spiego il problema, il tecnico mi mette in attesa mentre controlla la configurazione del “GAD”, ovvero il loro piccolo router telsey con linux che mettono con questo genere di contratti. Dopo un po’ l’attesa finisce e il tecnico mi dice “non c’e’ nessun filtro sul gad, e’ sicuro che dal suo lato e’ tutto a posto?”

A questo punto io spiego che sto sniffando con tcpdump, che solo quella porta da problemi, che sono collegato diretto al gad e quindi non c’e’ ne firewall ne altro in mezzo. Sembra convincersi, e mi rimette in attesa. Attendo… attendo… passano 16 minuti in attesa, e cade la chiamata.

Richiamo il 192194, risponde un altro operatore, rispiego il problema. Mi conferma che non ci sono filtri sul gad e mi dice che mi richiameranno.

Dopo un’ora mi richiama un altro tecnico, rispiego nuovamente il problema, mi mette in attesa e dopo un po’ mi dice “non ci sono filtri sul gad, non e’ un suo problema?”. Io inizio ad irritarmi, ma gentilmente rispiego nuovamente il tutto, sottolineando che o i pacchetti si perdono a meta’ del cavo di rete di 50 cm tra il gad e il mio router, oppure i pacchetti si fermano da loro, sul gad o prima. Il tecnico a quel punto mi dice “forse e’ la sua scheda di rete rotta, ha provato a cambiare scheda di rete?”.

Ora mi incazzo sul serio, e inizio a spiegargli, bestemmiando allegramente, che dovrebbe provare a tracciare i pacchetti dumpando il traffico sulle sue fottute schede di rete, oppure che facciano uscire un tecnico a verificare di persona il problema, e smetterla di dire che e’ un problema dal mio lato, perche’ semplicemente NON e’ cosi’.

Il tecnico mi risponde “capisco, ok attenda un attimo, la richiamo io” e riaggancia. Dopo 10 minuti di richiama, e mi conferma che non ci sono problemi, e che quindi secondo lui il problema e’ da me. Non piu’ tanto gentilmente gli spiego qualcosa sulle reti e su quello che sto provando sperando di dimostrare che il problema non e’ mio. Dopo un po’ mi rimette in attesa, cade la linea e finisce li.

Irritato chiamo nuovamente il call center, dove mi viene detto che il ticket e’ stato chiuso con motivazione “problema di competenza del cliente”. Mi incazzo, chiedo di parlare con un responsabile, mi passano uno pseudotale, che riapre un nuovo ticket.

Ora senza tirarla ulteriormente per le lunghe, andiamo avanti tutta la giornata, fino alle 19 circa in questo modo. Ho chiamato il call center almeno altre 14/15 volte, tutte le volte mi confermavano che il ticket precedente era stato chiuso con la stessa motivazione, e mi dicevano che mi avrebbero fatto richiamare da un tecnico. Nessun tecnico mi richiamava, io richiamavo e il ciclo ricominciava.

Alla fine mi sono decisamente rotto, ho staccato fisicamente il loro “gad”, ho attaccato la mia macchina linux diretta al media converter, ho spoofato il mac-address del gad e mi sono preso il suo indirizzo IP interno a fastweb. Tutto magicamente ha iniziato a funzionare, e i pacchetti udp 5060 arrivano senza problemi, riesco a registrarmi al server senza problemi e le chiamate via SIP funzionano alla perfezione. Ma come, non mi avevano detto che non c’era nessun filtro e che il problema era mio?

Sono senza parole.

Fastweb e VoIP SIP... capitolo secondo
Rilasciata una nuova release di Astronomix