Il blog di DiRete

SMTP EOLO NGI

Vi segnalo una modifica della gestione della posta in uscita delle connessioni NGI con IP dinamico o “sotto NAT”.
Per questo vi segnalo anche la pagina di configurazione della posta di EOLO.

La modifica riguarda esclusivamente l’utenza che utilizza un server esterno alla rete di NGI per l’invio della posta in uscita senza autenticazione.

Da martedì 15 Ottobre non sarà più possibile effettuare connessioni verso server SMTP esterni alla rete di NGI che non abbiano autenticazione e questo vale solo per i contratti con IP dinamico o “sotto NAT”. Sono quindi esclusi i clienti che hanno nel contratto un IP statico.

Questa modifica è necessaria per proteggere i clienti NGI, abbattere il livello di spam e tutelare il buon funzionamento della posta elettronica.

Se invece si utilizzano esclusivamente interfacce webmail oppure i server di NGI (smtp.ngi.it) o di terze parti con autenticazione, non ci sarà alcun effetto.

Approfondimento tecnico: verrà bloccata la possibilità di effettuare connessioni in uscita sulla porta 25/tcp da IP dinamici o dietro NAT444 delle connessioni NGI. Consigliamo, quindi, di utilizzare smtp.ngi.it come server di posta in uscita. Qualora fosse necessario utilizzare server esterni, suggeriamo di utilizzare connessioni SMTP su SSL operanti su altre porte e/o l’utilizzo della porta submission (587/tcp).

 

 

Asterisk: niente audio sui client sip remoti e firewall Sonicwall.

Il nostro centralino Asterisk è ormai ad un eccellente livello di funzionalità. Ogni giorno impariamo cose nuove e siamo ormai praticamente pronti al test da qualche cliente ed alla commercializzazione del pacchetto (vedremo, a breve, di costruire un’offerta commerciale).

Oggi, però, abbiamo riscontrato (nuovamente) un problema già visto in passato: i softphone (usiamo eyebeam) connessi da reti remote si autenticano correttamente sul centralino, ma l’audio non passa.
“Sniffando” il traffico (sul ns. server linux il comando è: tcpdump -i eth0 -n -v not port 22 (not port 22 serve per evitare che ci si autosniffi essendo collegati in ssh)) si scopre che i pacchetti RPT (Real Time Transport Protocol) vengono mandati da asterisk all’ip privato del softphone.

Si apre quindi il tema, annoso, del VOIP su reti nattate. Premesso che il centralino non è nattato ma ha un ip pubblico sulla scheda di rete, il client non è nella stessa situazione e viene nattato dal router della connessione dietro cui si trova.

La soluzione standard, “banalmente” è quella di aggiungere una riga al file sip.conf:

nat = yes

o, se come noi usate l’ottimo voiceone (ne parleremo a breve), potete anche impostare il nat direttamente sulle singole estensioni che userete fuori dalla rete dell’ufficio (non che non lo si possa fare senza voiceone, ma con quest’ultimo è, evidentemente, tutto più semplice)

Questo, di per sè, sistema le cose … a patto … di non avere un firewall Sonicwall con attivo il flag su ” Enable SIP Transformations”, perché in quel caso, il sonic ci metterà uno zampino malefico e non funzionerà nulla!!!

In effetti, dal manuale, è chiaro che il firewall con quell’opzione attiva si occupa di cambiare l’ip scritto dentro i pacchetti ma, secondo logica, dovrebbe farlo correttamente, non al contrario (l’esempio, a onor del vero, è per il caso opposto: sip client in lan nattato e proxy asterisk remoto non nattato):

Selecting Enable SIP Transformations transforms SIP messages between LAN (trusted) and WAN/DMZ (untrusted). You need to check this setting when you want the SonicWALL security appliance to do the SIP transformation. If your SIP proxy is located on the public (WAN) side of the SonicWALL and SIP clients are on the LAN side, the SIP clients by default embed/use their private IP address in the SIP/Session Definition Protocol (SDP) messages that are sent to the SIP proxy, hence these messages are not changed and the SIP proxy does not know how to get back to the client behind the SonicWALL. Selecting Enable SIP Transformations enables the SonicWALL to go through each SIP message and change the private IP address and assigned port. Enable SIP Transformation also controls and opens up the RTP/RTCP ports that need to be opened for the SIP session calls to happen. NAT translates Layer 3 addresses but not the Layer 7 SIP/SDP addresses, which is why you need to select Enable SIP Transformations to transform the SIP messages.
Tip: In general, you should check the Enable SIP Transformations box unless there is another NAT traversal solution that requires this feature to be turned off. SIP Transformations works in bi- directional mode, meaning messages are transformed going from LAN to WAN and vice versa.