Qu'est-ce qui amènerait le trafic SIP à entrer dans un commutateur sans en sortir?

Contexte

J'ai du mal à faire enregistrer mes téléphones SIP derrière un tout nouveau routeur et à passer dans notre tout nouveau bureau. Notre PBX est hébergé hors site. J'ai travaillé avec notre fournisseur pour essayer plusieurs approches différentes. Nous avons essayé le NAT normal pour se connecter à leur contrôleur de bordure de session compatible NAT. Nous avons essayé d'utiliser siproxd (le package pfSense) pour intercepter les demandes d'enregistrement SIP et nous inscrire au nom des téléphones. Enfin, nous avons essayé de configurer manuellement les téléphones pour qu'ils s'inscrivent avec le démon siproxd sur mon réseau local.

Tout au long des tests, nous avons vu les téléphones effectuer avec succès toutes les opérations suivantes:

Contacter le serveur FTP hébergé par adresse IP
Téléchargez la configuration à partir dudit serveur
Effectuer des requêtes DNS pour résoudre l'adresse IP du serveur NTP
Interrogez le serveur NTP pour régler l'heure
Effectuer des requêtes DNS pour résoudre l'adresse IP du ou des serveurs SIP

Symptômes

Une fois que les téléphones ont effectué toutes les tâches de pré-inscription avec succès, nous ne voyons jamais la tentative d'enregistrement frapper la case pfSense ou le PBX du fournisseur. J'ai activé le plus haut niveau de débogage dans siproxd de mon côté et j'ai vu nary une connexion TCP ou un paquet UDP. Cependant, un simple telnet au port 5060 à partir d'un poste de travail générera les messages de journal attendus. L'exécution d'une capture de paquets sur la boîte pfSense n'a montré aucune tentative de trafic SIP.

Que diable?

Ma dernière étape de dépannage qui m'a complètement déconcerté et m'a amené à poser cette question était la suivante. J'ai d'abord reflété le port du commutateur sur lequel un téléphone était branché sur le port du commutateur de mon poste de travail. J'ai effectué une capture de paquets de tout le trafic sur l'interface. À ma grande surprise, j'ai vu des paquets d'enregistrement SIP provenant du téléphone. Voici un exemple:

Capture de paquets téléphoniques

De toute évidence, le téléphone essaie de s'enregistrer auprès des PBX (ce sont également les bonnes adresses IP).

Ma prochaine étape a été de mettre en miroir le port du commutateur qui alimente le côté LAN du routeur pfSense. J'ai vu tout le trafic FTP, NTP et DNS du téléphone 172.200.22.102 sortir du commutateur, mais pas une trace des paquets SIP. C'est complètement déroutant pour moi! Qu'est-ce qui fait que seul le trafic SIP disparaît dans le commutateur?

Environnement

Matériel
- Routeur / pare-feu: Netgate m1n1wall 2D2
- Commutateur: HP 1810G-24
- Téléphones: Polycom SoundPoint IP 501
Logiciel: pfSense 2.0-RC3

Configuration du commutateur

Le téléphone avec l'adresse IP 172.22.200.102 est dans le port 4 de ce commutateur, la liaison LAN du routeur est dans le port 22.

Configuration VLAN

Participation au VLAN 200

Je peux partager d'autres paramètres qui pourraient être nécessaires.

pfsense sip switch

— Hobodave
source

Je sais que c'est du bon sens que les paquets doivent être dirigés vers l'interface LAN du routeur, mais ne prenons rien pour acquis. Pourriez-vous demander à Wireshark de vous montrer les adresses MAC de destination sur ces paquets quittant le téléphone et confirmer qu'elles sont en fait l'adresse MAC du routeur? Si pour une raison quelconque ils ne l'étaient pas, cela expliquerait pourquoi vous ne les voyiez pas sur le port miroir.

— MadHatter

@Mad: adresse MAC de destination correcte confirmée du routeur

— hobodave

Zut. Eh bien, cela valait la peine d'être vérifié. Désolé de ne pas avoir de meilleures idées.

— MadHatter

J'ai trouvé la solution après avoir passé environ 40 heures sur ce problème.

Il y a un paramètre dans le commutateur qui active la protection "Auto DoS". Apparemment, il considère le trafic TCP ou UDP qui a des ports source ou de destination correspondants comme une attaque indirecte et abandonne le paquet. C'est ridiculement myope puisque le trafic SIP repose souvent (toujours?) Sur les ports source et de destination étant 5060.

Dans le cas où une description textuelle était insuffisante:

entrez la description de l'image ici

— Hobodave
source

wow, c'est brutal. Bon travail pour trouver ça. Je parie que cela n'apparaît pas non plus dans les journaux, non?

— gravyface

@gravyface: correct, rien enregistré. Tous les journaux indiquent les liaisons de base haut / bas et les tentatives d'authentification

— hobodave

Whaaaaaaaaaaaaaaaat? Beau travail HP!

— voretaq7

Ça craint; cela viserait (par exemple) NTP et DNS serveur-serveur également. Pour reprendre les mots de voretaq, "beau travail. HP". Bien diagnostiqué, cependant, hobodave; vous méritez une bière!

— MadHatter

+1 - J'ai rencontré ce problème aujourd'hui avec le même commutateur dans une application différente. Le protocole SonicWALL "Single Sign-On" utilise des datagrammes UDP avec les mêmes ports source / destination. J'aimerais avoir regardé ici avant de le retrouver avec un robinet Ethernet. Il est intéressant de noter que les trames "incriminées" sont même supprimées lors de la mise en miroir des ports du port d'entrée. Échec complet, HP. Je peux confirmer que le firmware PK 1.15, sorti en janvier, contient toujours cette erreur.

— Evan Anderson