Cosa farebbe sì che il traffico SIP venga visto entrare in uno switch ma non uscire?

sfondo

Ho avuto difficoltà a ottenere i miei telefoni SIP per registrarsi dietro un router nuovo di zecca e passare nel nostro ufficio nuovo di zecca. Il nostro PBX è ospitato fuori sede. Ho lavorato con il nostro fornitore per tentare diversi approcci. Abbiamo provato un normale NAT per connettersi al loro controller di bordo sessione sensibile al NAT. Abbiamo provato a utilizzare siproxd (il pacchetto pfSense) per intercettare le richieste di registrazione SIP e registrarsi per conto dei telefoni. Infine, abbiamo provato a configurare manualmente i telefoni per registrarsi con il demone siproxd sulla mia rete locale.

Durante i test abbiamo visto che i telefoni eseguono correttamente tutte le seguenti operazioni:

Contattare il server FTP ospitato per indirizzo IP
Scarica la configurazione da detto server
Eseguire query DNS per risolvere l'indirizzo IP del server NTP
Interrogare il server NTP per impostare l'ora
Eseguire query DNS per risolvere l'indirizzo IP dei server SIP

Sintomi

Dopo che i telefoni hanno completato con successo tutte le attività di pre-registrazione, non vediamo mai il tentativo di registrazione colpire la casella pfSense o il PBX del provider. Ho abilitato il più alto livello di debug in siproxd da parte mia e non ho mai visto una connessione TCP o un pacchetto UDP. Tuttavia, un semplice telnet alla porta 5060 da una workstation genererà i messaggi di registro previsti. L'esecuzione di un'acquisizione di pacchetti sulla casella pfSense non ha mostrato assolutamente alcun tentativo di traffico SIP.

Che diamine?

Il mio ultimo passaggio per la risoluzione dei problemi che mi ha sconcertato e mi ha portato a porre questa domanda è stato il seguente. Ho prima rispecchiato la porta dello switch a cui era collegato un telefono alla porta dello switch della mia workstation. Ho eseguito un'acquisizione di pacchetti di tutto il traffico sull'interfaccia. Con mia sorpresa, ho visto i pacchetti di registrazione SIP provenienti dal telefono. Ecco un esempio:

Acquisizione pacchetti telefonici

Chiaramente il telefono sta provando a registrarsi con i PBX (anche quelli sono gli indirizzi IP corretti).

Il passo successivo è stato il mirroring della porta dello switch che si immette sul lato LAN del router pfSense. Ho visto tutto il traffico FTP, NTP e DNS dal telefono 172.200.22.102 che esce dallo switch, ma non una traccia dei pacchetti SIP. Questo è completamente sconcertante per me! Qual è la causa solo il traffico SIP a svanire all'interno dello switch?

Ambiente

Hardware
- Router / Firewall: Netgate m1n1wall 2D2
- Interruttore: HP 1810G-24
- Telefoni: Polycom SoundPoint IP 501
Software: pfSense 2.0-RC3

Cambia configurazione

Il telefono con indirizzo IP 172.22.200.102 è nella porta 4 di questo switch, il collegamento LAN del router è nella porta 22.

Configurazione VLAN

Partecipazione VLAN 200

Posso condividere altre impostazioni che potrebbero essere necessarie.

pfsense sip switch

— hobodave
fonte

So che è logico che i pacchetti debbano essere diretti verso l'interfaccia LAN del router, ma non diamo nulla per scontato. Potresti ottenere WireShark per mostrarti gli indirizzi MAC di destinazione su quei pacchetti che escono dal telefono e confermare che in realtà sono l'indirizzo MAC del router? Se per qualche motivo non lo fossero, ciò spiegherebbe perché non li stavi vedendo sulla porta mirror.

— MadHatter,

@Mad: confermato l'indirizzo MAC di destinazione corretto del router

— hobodave

Dannazione. Bene, valeva la pena controllare. Mi dispiace non avere idee migliori.

— MadHatter,

Ho trovato la soluzione dopo aver trascorso circa 40 ore su questo problema.

C'è un'impostazione nell'interruttore che abilita la protezione "Auto DoS". Apparentemente considera il traffico TCP o UDP che ha le porte di origine o destinazione corrispondenti come un attacco palese e rilascia il pacchetto. Questo è ridicolmente miope poiché il traffico SIP spesso (sempre?) Si basa sul fatto che le porte di origine e di destinazione sono 5060.

Nel caso in cui una descrizione testuale fosse insufficiente:

inserisci qui la descrizione dell'immagine

— hobodave
fonte

wow, è brutale. Ottimo lavoro trovandolo. Scommetto che non compare neanche nei registri, giusto?

— gravyface,

@gravyface: corretto, niente registrato. Tutti i registri mostrano un collegamento di base su / giù e tentativi di autenticazione

— hobodave il

Whaaaaaaaaaaaaaaaat? Bel lavoro HP!

— voretaq7,

Che schifo; rovinerebbe (es.) NTP e DNS server-server. Nelle parole di voretaq, "bel lavoro. HP". Ben diagnosticato, tuttavia, hobodave; ti meriti una birra!

— MadHatter,

+1 - Mi sono imbattuto in questo oggi con lo stesso interruttore in un'altra applicazione. Il protocollo "Single Sign-On" di SonicWALL utilizza datagrammi UDP con le stesse porte di origine / destinazione. Vorrei aver guardato qui prima di rintracciarlo con un rubinetto Ethernet. È interessante notare che i frame "offensivi" vengono persino rimossi quando si esegue il mirroring delle porte sulla porta di ingresso. Completamente fallito, HP. Posso confermare che il firmware PK 1.15, rilasciato a gennaio, presenta ancora questo malfunzionamento.

— Evan Anderson,