Client SIP su OSO MX quali porte aprire/nattare

[Hunter]

Ciao a tutti,

stavo facendo delle prove per registrare dei Client SIP che utilizziamo sui ns cellulari al ns OSO MX, normalmente con altre centrali è sufficiente aprire la porta 5060 e "nattarla" sull'IP privato del centralino, ma con l'OSO non riesco a registrarmi.

Viceversa se sono collegato alla WLAN aziendale non ho problemi ad usare il Client.

Bisogna aprire altre porte che voi sappiate!? 

[Lucky]

Siete riusciti ad utlizzare dei client sip collegandovi ad un indirizzo pubblico nattato su un indirizzo privato???
Avete per caso un sbc?
Le porte che servono per far passare la voce sono in realtà un range da rtp-min a rtp-max, ma se c' è di mezzo nat e nientaltro dubito che funzioni.

[Kimera]

Metti mai che abbiano davvero un SBC (tipo questo) o abbiano realizzato uno STUN (dubito)...ma se c'è di mezzo solo il NAT (Port Forwarding) e questo è solo per la Porta 5060...la vedo non dura, durissima. Direi impenetrabile.

[sattelema]

Ciao,
io ho lo stesso problema di Hunter, qualcuno sa come fare?
Ho provato con diversi client SIP e su diversi smartphone ma dall'esterno della rete aziendale non si loggano al sistema..
E' necessario nattare altre porte oltre alla 5060 UDP?
O bisogna usare questo OpenScape Session Border Controller??
Grazie.

[Lucky]

Per semplificare le cose:
il centralino e il telefono devono vedersi l' un l' altro con l' indirizzo ip effettivo.
Quindi:
o si usa wan o dmz con indirizzo pubblico sul centralino (no nat)
o vpn
o si inserisce un apparecchiatura in mezzo (SBC appunto) che permette di "spaccare il pacchetto" e convertire gli indirizzi ip.
o ... al momento non me ne vengono altre
Solo con nat come dice Kimera non te la caverai mai.
Ciao

[Kimera]

Soluzioni che prevedono la presenza di un SBC (sia esso X oppure Y) sono in uso nel mondo Enterprise (grandi aziende)...e, di certo, non vengono sviluppate ed implementate per essere convenienti quando da abilitare è "solo" il "singolo" Client SIP remoto.

Anni fa...ma davvero anni fa (correva l'anno 2003/2004...), quando ancora Siemens era nella fase di approccio al SIP per implementarlo poi nei propri sistemi (eravamo agli albori...), il problema del NAT Traversal era stato affrontato e sviscerato da alcuni sviluppatori (Siemens Svizzera) che hanno gettato le basi per i vari SIP Client (di Siemens) che usiamo ora.

Allego un documento dell'epoca (ora il dominio "mysip.ch" che veniva usato dagli sviluppatori per testare i SIP Clients non è più di Siemens Svizzera...) che, personalmente, ritengo "storico" (ed è una chicca introvabile...sperando di non infrangere qualche legge)...e che la dice lunga (ovviamente, ora come ora, in giro si possono trovare anche spiegazioni e rimedi, vedi caso di ALG/Firewall o di SBC, migliori...e più al passo con i tempi) sul problema dello stare "Behind a NAT".

Forse sarebbe il caso di andare a vedere lato Firewall cosa si ha (SIP ALG?)...prima di esporre il proprio sistema facendolo risiedere (almeno per la parte WAN) nella DMZ o prima di assegnare direttamente un indirizzo IP Pubblico (magari di un Pool a disposizione) alla sua WAN Interface.

Saluti, Kimera.

[Hunter]

Mmm...sono piuttosto scettico sul fatto che le centrali debbano vedersi l'un, l'altra come con una VPN o direttamente con un IP Pubblico, (in realtà sono scettico a priori su queste cose) posso capire che la chiamata magari non venga instaurata, e qui sarebbero un altro paio di maniche, ma se io da un IP esterno qualunque, punto un IP Pubblico, dove ho un NAT sulla porta 5060 che mi va a finire sull'OSO MX, per lo meno la registrazione deve avvenire...poi se vorrò chiamare o utilizzare dei servizi, questo è un altro discorso, ma la registrazione deve funzionare, allo stesso modo in cui, mi loggo internamente...a meno che, la porta 5060 non sia quella che utilizza l'OSO per il SIP (e se devo essere sincero, la cosa non mi sembra nemmeno così strana perchè la S di Standard, non ho mai capito bene perchè l'abbiano messa visto che di standard nel SIP c'è veramente molto poco)

Comunque farò qualche prova giusto per levarmi lo sfizio! 

[sattelema]

Kimera, il tuo documento è davvero una chicca, molto interessante considerando che è stato fatto 10 anni fa!

Tornando ai giorni nostri,  io vorrei evitare di dare un IP pubblico al centralino, e usare un SBC per pochi client SIP remoti non vale la pena, forse la soluzione della VPN fra telefono e centrale è la giusta via di mezzo.
Ma a questo punto chiedo: quale protocollo va usato, IPSec, PPTP, L2TP?
Si può usare il software VPN già a bordo degli smartphone o bisogna usare un'app specifica?

Hunter, se scopri che l'OSO non usa la 5060 facci sapere!

[Kimera]

Mah...difficile a dirsi...comunque è un fatto ormai noto che, a causa della caduta (avvenuta recentemente) del protocollo PPTP posto sotto attacco anti-crittografico (de-crittografico), ultimamente siano raccomandati IPSec ed L2TP rispetto al "debole" PPTP (che era forte fino a l'altro ieri...).

[Kimera]

Kimera, il tuo documento è davvero una chicca, molto interessante considerando che è stato fatto 10 anni fa!

Stiamo deviando per la tangente...ma chicca per chicca...eccoti un posto dove qualcuno ha conservato (da qualche parte ho una Folder con tutto pure Io) le prove tangibili di quel passato. Vedi mysip per le tracce lasciate...con tanto di Datasheet del SIP Client (SCS)...e correva l'anno 2004!

Devo anche aver scambiato qualche mail con gli sviluppatori...all'epoca.

Alla storia non si comanda!

Saluti, Kimera.

[Kimera]

Tornando al discorso relativo a come ovviare ai problemi EDIT di tramite il NAT Traversal (ALG)...direi che vale sempre prima la pena di provare ad usare, se presenti, le funzionalità di SIP ALG (SIP Transformations) quando si hanno a disposizione dei Firewall che le possiedono. Non è detto che se ne riesca a venire a capo...ma tentar non nuoce...e poi bisogna sempre vedere che tipologia di indirizzamento IP Pubblico viene offerta dalla connessione in uso (ad esempio: un solo IP Pubblico sul quale si attua il NAT a livello di xDSL Router con conseguente Forwarding di tutte le Porte ed i Protocolli verso la WAN del Firewall retrostante oppure un Pool di IP Pubblici per il quale un indirizzo del Pool stesso può essere assegnato direttamente alla WAN del Firewall [in questo caso il NAT non lo attua il xDSL/Rotuer] ed al quale, in questo caso, spessa l'onere [o meno] del NAT verso la Subnet privata interna...sempre a seconda della posizione [LAN vs DMZ] in cui è [topo]logicamente posizionato l'IP-PBX).

[Hunter]

Tornando al discorso relativo a come ovviare ai problemi EDIT di tramite il NAT Traversal (ALG)...direi che vale sempre prima la pena di provare ad usare, se presenti, le funzionalità di SIP ALG (SIP Transformations) quando si hanno a disposizione dei Firewall che le possiedono. Non è detto che se ne riesca a venire a capo...ma tentar non nuoce...e poi bisogna sempre vedere che tipologia di indirizzamento IP Pubblico viene offerta dalla connessione in uso (ad esempio: un solo IP Pubblico sul quale si attua il NAT a livello di xDSL Router con conseguente Forwarding di tutte le Porte ed i Protocolli verso la WAN del Firewall retrostante oppure un Pool di IP Pubblici per il quale un indirizzo del Pool stesso può essere assegnato direttamente alla WAN del Firewall [in questo caso il NAT non lo attua il xDSL/Rotuer] ed al quale, in questo caso, spessa l'onere [o meno] del NAT verso la Subnet privata interna...sempre a seconda della posizione [LAN vs DMZ] in cui è [topo]logicamente posizionato l'IP-PBX).

Lo scenario dove sto facendo le prove è un IP Pubblico pulito (stessa espressione che usiamo con gli elettricisti quando chiediamo i contatti per i citofono) assegnato alla WAN e poi è il Firewall "natta" le varie porte sugli IP Privati. Però ormai la curiosità mi sta lacerando, giusto per la cronaca, non faccio prove mettendo la centrale su un IP Pubblico, perchè so già che funziona.

Vi terrò aggiornati.

[Kimera]

Lo scenario dove sto facendo le prove è un IP Pubblico pulito assegnato alla WAN e poi è il Firewall "natta" le varie porte sugli IP Privati.

(un IP Pubblico è) Assegnato alla WAN di chi?

...è assegnato alla WAN del Firewall (si usano 3 IP...due assegnati sulle interfacce WAN e LAN del Router ed uno sulla WAN del Firewall...) ed il Firewall, che è posto dietro il Router (quindi con un solo livello di NAT realizzato appunto dal Firewall...visto che il Router non fa NAT in questo caso), esegue poi il suo NAT (quindi NAT singolo)...oppure tale IP Pubblico è assegnato alla WAN del Router che esegue un primo NAT lasciando al Firewall il compito di eseguire il secondo (quindi double-NAT)?

Di solito quando si ha un solo IP Pubblico statico non si può evitare il doppio NAT (anche se si fa Any Port/Any Protocol Forwarding verso la WAN del Firewall)...nel senso che tale IP Pubblico è assegnato dal gestore ITSP alla WAN del Router a prescindere da cosa c'è alle spalle tale Router (potrebbe anche non esserci un Firewall)...e tale Router deve quindi realizzare forzosamente il primo NAT verso la sua LAN (ossia verso la Subnet interna o verso comunque la Subnet interna che si instaura tra la sua LAN e la WAN dell'eventuale Firewall posto alle sue spalle, sempre che questo ci sia)...e quindi l'eventuale Firewall alla fine si ritrova a fare il secondo NAT verso la LAN privata...mi pare che solo avendo un Pool di IP Pubblici si possa ricadere nel primo caso (NAT fatto solo dal Firewall).

Qualcuno potrebbe aggiungere (od obbiettare) che anche il più blasfemo dei Router ha funzionalità Firewall (benchè difficilmente funga da terminatore VPN come fa un Firewall di rango)...ma, detto in sintesi, un conto è un Firewall con "ALG Support" (ed anche qui...si spalancano le porte dell'infinito) ed un altro è un normale Router che offre il servizio di Virtual Server ([Port/Service]-Forwarding verso gli Host della IP Subnet privata)...se, all'apparenza, entrambi possono sortire effetti simili (raggiungibilità di alcuni specifici servizi interni dall'esterno, vedi RDP, VNC, SSH, HTTP/HTTPS e chi ne ha più ne metta...) dall'altro, per il VoIP ad esempio, non sono affatto la stessa cosa (quando nel Payload dei messaggi di un SIP Client è contenuto il proprio IP Privato e tale SIP Client deve connettersi con un altro SIP Client all'esterno) al punto di arrivare, se non ci si fa caso, agli annosi problemi del Simmetric NAT/Full-Cone NAT ecc.

La VPN (Client to Gateway e Gateway to Gateway) può sicuramente essere una soluzione...

Nota: insisto con lo scrivere che c'è, da qualche parte, un (xDSL)-Router interposto tra Internet ed il Firewall ma, questi due apparati, potrebbero essere anche "accorpati" in un unico device (un xDSL Modem/Router/Firewall...esempio: il Netgear DGVF338 che in più aveva anche il WiFi)...ma questa è solo una mia presunzione per tentare di dare un nome alle cose.

Correggetemi se sbaglio (Sopra ho corretto "...di NAT Traversal (ALG)..." con "...di tramite il NAT Traversal (ALG)..." altrimenti sembra che il NAT Traversal sia il problema e non una tecnica per risolvere un problema!).

[Kimera]

Per gli scettici (a parte TUTTO quello che si trova in Internet relativamente al NAT e alle conseguenze, positive e negative, del suo uso) invito la lettura di questa pagina (fonte Gigaset Communications GmbH, AKA Gigaset PRO, per i suoi terminali DECT/IP). Non tanto perchè essa fa riferimento a questioni specifiche dei Gigaset VoIP ma soprattutto per la parte di "Background Informations" annessa.

Saluti, Kimera.

[Hunter]

Lo scenario dove sto facendo le prove è un IP Pubblico pulito assegnato alla WAN e poi è il Firewall "natta" le varie porte sugli IP Privati.

(un IP Pubblico è) Assegnato alla WAN di chi?

Alla WAN del Firewall.  Avendo una subnet pubblica /28 non aveva senso fare un doppio NAT, a che pro!? 
Il router diventa quindi trasparente poichè diventa il Gateway del Firewall, non ci sono NAT di mezzo.

Poi sarò io dal mio firewall che farò i vari PAT/NAT come preferite chiamarli. In ogni caso rimango abbastanza curioso sull'arcano. Perchè i casi sono veramente nell'ambito del rasoio di Occam, quindi o il firewall non fa il NAT corretto, oppure la porta 5060 non è quella che l'OSO MX utilizza per la registrazione dei client SIP, la seconda delle due mi lascia più perplesso perchè forzando internamente la registrazione sulla porta 5060 la registrazione avviene normalmente....uhm...