[RESOLU] Firewall / VOIP (SIP)

[mfncbm]

Hello la communauté !
Content de voir la nouvelle peau d'Ix... pardon de PhenIXUS !

Je viens vers vous vis-à-vis d'un petit soucis rencontré chez un client.
Le Firewall est un Zentyal 2.2 à jour.

Voici l'architecture réseau:



Pour résumer le schéma :

- 2 réseaux distants reliés par un lien interlan completel 100M : donc les deux réseaux se voient de manière transparente (connexion de niveau 2)
- Le LAN (constitué des deux interlan possède un plan IP classique : 192.168.1.0 /24 avec un serveur DHCP qui adresse donc pour les 2 sites
- Le Firewall Zentyal fait office de lien LAN-WAN (il y a une DMZ mais elle n'entre pas en ligne de compte dans la problématique). LAN : eth0 / WAN : eth2.
- Un routeur installé par le prestataire téléphonique pour assurer la liaison entre le réseau de ces tél. IP (SIP) en 192.168.16.x et le LAN en 192.168.1.x. Derrière ce routeur sont donc installés tous les tél. IP du Réseau 2 et l'IPBX...
- Les tél. IP du réseau 1 par contre attrapent des IP par le serveur DHCP donc en 192.168.1.x
- A la demande du prestataire j'ai créé une route statique dans Zentyal envoyant toutes les requêtes destinées au réseau 192.168.16.0/24 vers l'IP de son routeur (192.168.1.100)

Jusque là tout va bien ! Sauf au niveau VOIP...

Toute les communications sont nickel :
- A l'intérieur du Réseau 2 : normal, les tél. IP sont en lien direct avec l'IPBX
- Depuis le Réseau 2 vers les Réseau 1

Mais les connexions sont "merdiques" (connexions une fois sur deux, débit pourri...) quand un tél. IP du Réseau 1 appelle vers un tél. IP du Réseau 2.
Le prestataire téléphonique s'est tourné vers nous en accusant le firewall linux (ha oui ! satané firewall linux ...)
Dans un premier temps j'ai dit au prestataire téléphonique que ça n'avait rien à voir avec le firewall Zentyal... à priori !

MAIS j'ai trouvé des logs étranges au niveau du Pare-Fe de Zentyal (quelques lignes pas des dizaines non plus mais avec des IP différentes !) :

Date Interface d'entrée Interface de sortie Source Destination Protocole Port source Port de destination Décision
2011-11-04 16:06:59 eth0 eth0 192.168.1.129 192.168.1.129 UDP 5060 5060 ABANDONNER

L'IP 192.168.1.129 en question est un tél. IP du Réseau 1 et les ports correspondent à du SIP. Ces paquets ont donc été "droppés" par Zentyal quand ils sont arrivés par sa patte LAN.

Déjà, étant plutôt admin. système, j'ai du mal à comprendre cette ligne : pourquoi l'IP source et de destination est identique ?
Pourquoi ce paquet arrive-t-il sur la patte LAN de mon Zentyal ?
N'est-ce pas le rôle du routeur du prestataire tél. de gérer les communications entre les réseau 192.168.16.x (où se situe l'IPBX) et le réseau 192.168.1.x où se situent les PC mais aussi les tél. IP du réseau distant ?
De plus, dans "Règles de filtrages pour les réseaux internes" dans la GUI de Zentyal : je n'ai rien commencé à filtrer ! Donc toutes les communications (any/any/tous protocoles/tous ports) sont autorisés sur mon lan et ma dmz et entre les deux, forcément... Pourquoi donc ce DROP (ABANDONNER en français dans l'interface) de l'UDP/5060 ??

D'avance merci pour vos lumières

lembal

[jdh]

Quelques réflexions :
- le lien completel est un "bridge" : il doit impérativement transférer tout protocole (udp ou tcp) de part et d'autre, il ajoute un temps de traitement;
- SIP est un protocole connu pour passer non aisément un routeur NAT : il n'y a pas là de NAT, donc à priori correct;
- le flux SIP (entre postes internes) n'a pas à traverser Zentyal, mais comme Zentyal est gateway, il y a au moins une redirection icmp pour indiquer la "bonne" route.

2 tests à réaliser :
- le cas d'un téléphone en 192.168.1.x dans le réseau 2 pose-t-il les mêmes problèmes qu'un téléphone dans le réseau 1 ?
- que se passerait-il si le DHCP fournissait le routeur SIP comme gateway (quitte à ajouter une route vers @ via Zentyal) ?

[jibe]

Salut,

Déjà, bravo pour la présentation du problème !

J'espère que Cool34000 va passer par là, parce que mes compétences en VoIP sont un peu limitées, et ce problème ne m'inspire pas trop. Toutefois, je note déjà un truc bizarre au niveau du schéma : ton serveur DHCP est en 192.168.1.0 ? L'adresse en 0 est normalement réservée comme identifiant de réseau, la première adresse utilisable étant celle en 1. Donc, pour respecter la logique de ton adressage, j'aurais mis pour ton serveur DHCP 192.168.1.2.

Le prestataire téléphonique s'est tourné vers nous en accusant le firewall linux (ha oui ! satané firewall linux ...)

Ben... Si tu as le problème en interne, ton serveur Zentyal ne sert à rien pour cela => tu le débranches et fais les essais sans lui. Si pas d'amélioration, tu appelles ton prestataires et lui demande de faire fonctionner les appels internes, Zentyal débranchée

pourquoi l'IP source et de destination est identique ?

Heu... Effectivement, à part un truc qui ne me viendrait pas à l'esprit, je ne vois aucune raison à cela !
Quoique... Si tu as une règle qui drope all sources, all destinations... Là, il va peut-être falloir donner le détail de tes règles dans Zentyal. Es-tu vraiment sûr de tout autoriser, et qu'une autre règle venant de je ne sais où ne passerait pas en priorité ?

Pourquoi ce paquet arrive-t-il sur la patte LAN de mon Zentyal ?

Ben ça, c'est normal... Il transite sur le LAN, normal que ta Zentyal le voit passer. La question n'est-elle pas plutôt "Pourquoi Zentyal le traite ?", puisque c'est LAN->LAN.

N'est-ce pas le rôle du routeur du prestataire tél. de gérer les communications entre les réseau 192.168.16.x (où se situe l'IPBX) et le réseau 192.168.1.x où se situent les PC mais aussi les tél. IP du réseau distant ?

Logiquement, oui. Mais d'expérience, dès qu'il y a deux prestataires sur un même réseau (toi pour les PC, lui pour les tél), c'est toujours de la faute de l'autre. Et puis, je dirais que ça dépend du contrat. Perso, j'essaie (mais bon, pas toujours facile) d'éviter ce genre de situation. Là, j'aurais dit au client : Je prends le tout, et je sous-traite la VoIP. Ainsi, c'est toi le maitre d'oeuvre, toi qui as un contrat avec le prestataire VoIP, et il est obligé de travailler avec toi. Là, il fait ce qu'il veut et surtout raconte ce qu'il veut au client...

Moi, j'expliquerais clairement la situation au client, et je lui dirais d'exiger que vous vous trouviez ensemble sur le terrain et que vous collaboriez pour trouver la solution. Mais bon, il vaut peut-être mieux essayer de trouver d'abord la raison de ces logs bizarres, ou au moins faire un essai sans Zentyal, histoire d'être sûr de prouver que le problème n'est pas le tien et qu'on ne te fasse pas assumer les coûts des interventions inutiles !

(any/any/tous protocoles/tous ports) sont autorisés sur mon lan et ma dmz et entre les deux, forcément...

Alors, j'espère que tout est bloqué entre DMZ et WAN !!! Sinon, je sens que je vais me faire un plaisir de téléphoner aux frais de ton client !

[EDIT]Entre temps, jdh a posté... Ça ne change pas grand chose à ce que je dis, sauf qu'il précise mieux que moi pourquoi Zentyal "voit" les paquets VoIP...

[jdh]

@Jibe : si on débranche le Zentyal, il n'y aura plus aucun appel ... puisque Zentyal est sans doute la passerelle par défaut fourni par le DHCP et qu'il contient une route statique pour atteindre l'IPBX : les téléphones en réseau 1 ne sauront jamais joindre le routeur SIP.

Le test le plus important est de placer un téléphone dans le réseau 2 : il ne doit pas subir l'influence du "bridge" réseau 1-réseau 2 : le temps de transfert doit avoir un impact non négligeable sur le proto SIP !

Perso, je ne vois pas l'intérêt d'un bridge : un lien avec 2 routeurs de chaque côté eut été plus naturel.
Mais il est probable qu'il soit difficile de passer à ce schéma ...

Alternative à tester : pourquoi ne pas installer un proxy SIP sur le réseau 2 ? (p.e. siproxd) (et configurer dument les téléphones ...)
(En fait je remplacerai le routeur SIP par une bête Debian à 2 interfaces avec ip_forward actif plus siproxd directement.)

[jibe]

@Jibe : si on débranche le Zentyal, il n'y aura plus aucun appel ... puisque Zentyal est sans doute la passerelle par défaut fourni par le DHCP et qu'il contient une route statique pour atteindre l'IPBX : les téléphones en réseau 1 ne sauront jamais joindre le routeur SIP.

Entièrement d'accord avec toi. C'est pour cela que j'avais bien précisé :

Si tu as le problème en interne, ton serveur Zentyal ne sert à rien pour cela => tu le débranches et fais les essais sans lui. Si pas d'amélioration, tu appelles ton prestataires et lui demande de faire fonctionner les appels internes, Zentyal débranchée

Normalement, les appels internes ne devraient pas passer par l'opérateur SIP. Mais si c'était le cas, ça pourrait peut-être expliquer les lenteurs et la responsabilité de Zentyal dans l'affaire !

Je déplace le fil : même si le problème vient de Zentyal, c'est quand même nettement un problème VoIP !

[EDIT]Je crois que je ne sais plus lire

@Jibe : si on débranche le Zentyal, il n'y aura plus aucun appel ... puisque Zentyal est sans doute la passerelle par défaut fourni par le DHCP et qu'il contient une route statique pour atteindre l'IPBX : les téléphones en réseau 1 ne sauront jamais joindre le routeur SIP.

routeur SIP != opérateur SIP, bien sûr !!!

Mais bon, j'essaierais quand même : ça ne mange pas de pain, et d'après le magnifique schéma que nous a fourni lembal, le tél du réseau 1 est en IP fixe. Pas dit qu'il ait besoin d'une route statique fournie par Zentyal... D'ailleurs, si tout n'a pas été fait par la même société, je vois mal la téléphonie se servir de quoi que ce soit ayant été installé par l'autre société. A moins bien sûr que les deux travaillent réellement ensemble, mais l'accusation de l'installateur VoIP semble prouver le contraire.

[Cool34000]

Salut,

Effectivement, super schéma !
On dirait qu'il y a du NAT entre le réseau 192.168.1.x et le réseau 192.168.16.x !
Pour un tel schéma, il faut soit utiliser STUN qui permet de faire passer SIP dans du NAT, soit passer par un proxy SIP.

Si c'est bien un problème de NAT, logiquement, tu devrais avoir les symptomes suivants :
- communication OK entre les téléphones du réseau 2
- communications dans un seul sens si appel entre les téléphones du réseau 1 et 2
- communications qui coupent au bout d'une 40ènes de secondes (et les WARNING de retransmissions qui vont avec dans la console Asterisk) si appel entre les téléphones du réseau 1 et 2

[mfncbm]

Merci jibe / jdh pour vos réponses !
Je vois que les anciens sont encore là
J'avais un compte sur ixus.net depuis 2003 mais j'étais moins actif depuis qqs temps.
A l'époque je gérai un firewall MNF et plusieurs serveurs Linux. Depuis j'en ai un peu moins en gérance mais ça augmente progressivement.

Bref !

Pour le moment, on en est pas à la sortie vers le WAN mais bien uniquement en interne.
Pour l'entrée de la téléphonie, ils ont deux T2.
Pour la sortie ça passera effectivement par le WAN (SDSL 10M).
Pour répondre à vos questions :

- Concernant le Bridge entre les 2 réseau distants, il est là depuis un temps certain et le client n'y changera rien. Donc il faut faire avec mais il n'y a pas de double-NAT ou de filtrage d'aucune sorte, c'est du niveau 2 pur et dur.
- Pour le proxy SIP, je soumettrai la question au preta. tél. ; mon expérience en VOIP se limitant à l'installation d'une trixbox derrière ma Freebox à la maison :p
- Les communications depuis les tél. IP du Réseau 2 vers le Réseau 1 ne posent aucun pb. Ni celles entre tél. IP du Réseau 2, forcément ! C'est vraiment quand la comm. part d'un tél. du Réseau 1 vers un tel. du Réseau 2
- Je suis d'accord sur le fait que le SIP ne devrait pas transiter sur mon firewall Zentyal lors de comm. internes mais d'où viennent ces trames ? Elles se sont égarées ?
- Autre indice qui mettrait hors de cause mon firewall Zentyal (parce que je veux pas passer pour un "dumb ass" aux yeux de mon client), la veille et le matin même les comm. tél. ne passaient pas du tout entre le Réseau 1 et le Réseau 2 alors que l'inverse était possible. Le presta. tél. s'est baladé (littéralement) entre les 2 sites (heureusement séparés que de 200m) et a joué avec les cascades de switches : l'après-midi les comm. tél. passaient entre le Réseau 1 et le Réseau 2 mais "merdiquement" (miracle ?) ! Entre temps inutile de dire que je n'avais rien touché à mon Zentyal... Il m'a alors reproché de ne pas appliquer de QOS sur le protocole SIP (sic !). Alors que je ne voyais pas en quoi mon Zentyal devait lisser le trafic de paquets SIP internes au LAN qui en outre ne sont pas censés passer par lui ??!! J'avais bien appliqué un lissage de trafic mais sur ma patte WAN pour prioriser les flux SIP sortant vers Internet mais ça ne le satisfaisait pas. J'ai donc inutilement lissé le trafic sur toutes les pattes de mon firewall pour mettre une priorité maximale aux protocoles VOIP (SIP, H323, ventrilo, teamspeak...etc). Mais je le répète, je pense que c'est inutile, qu'en pensez-vous ?

J'ai pensé à la même chose que vous en mettant le tél. IP du Réseau 1 soit en DHCP avec baux statiques soit en IP fixe mais dans dans les deux cas en précisant le routeur VOIP du presta. tél. (192.168.1.100) comme default gateway pour éviter d'interroger mon firewall Zentyal.
Petite question qui me taraude à ce sujet : quand un routeur a une route statique comme dans mon cas de figure, est-ce que c'est le routeur qui re-route tous les paquets vers le second routeur (et donc tout revient vers lui en réponse) ou bien transmet-il juste l'information au client que le routeur pour le réseau X est le routeur Y et qu'à partir de là il ne gère plus le routage et qu'ainsi la réponse part directement du réseau X vers le routeur Y pour finir sur le client.

Graphiquement, est-ce la cas 1 ou le cas 2 qui s'applique en cas de routage statique ?

CAS 1 :
Client -----------------> Requête -------------------> Default Gateway -------> Info routeur Y au client
(192.168.1.2) (vers 192.168.16.100) (192.168.1.1) (info 192.168.1.100)
^ !
! !
---------------------------------------------------------------------------------------------------------<!
!
------------> Routeur Y -----------> Routage vers destination
(192.168.1.100) (192.168.16.100)

CAS 2 :
Client -----------------> Requête -------------------> Default Gateway -------> Re-routage------------> Routeur Y -----------> Routage vers destination
(192.168.1.2) (vers 192.168.16.100) (192.168.1.1) (vers 192.168.1.100) (192.168.1.100) (192.168.16.100)

J'ai également réfléchi à la gueule de mon paquet "droppé" : est-il normal que l'adresse source et destination soient identiques ? Je pense (mais c'est peut-être idiot) qu'il est mal formé et que c'est la raison du DROP que lui fait subir IPTables...
Et que s'il était normal il le laisserait passer...

J'ai toutefois pris la précaution de forcer l'autorisation du protocole SIP (TCP/UDP 5060) en entrée, sortie, forward... sur toutes les pattes de mon Zentyal. On verra bien si d'une part les paquets bizarres sont toujours droppés et si ça améliore les communications. J'ai fait ça hier soir et le presta. tél. fera ses tests demain matin...

Merci encore de votre "coup de patte" (wow elle est bonne celle-là, je vais appeler Laurent Gerra !)

[mfncbm]

Salut,

Effectivement, super schéma !
On dirait qu'il y a du NAT entre le réseau 192.168.1.x et le réseau 192.168.16.x !
Pour un tel schéma, il faut soit utiliser STUN qui permet de faire passer SIP dans du NAT, soit passer par un proxy SIP.

Si c'est bien un problème de NAT, logiquement, tu devrais avoir les symptomes suivants :
- communication OK entre les téléphones du réseau 2
- communications dans un seul sens si appel entre les téléphones du réseau 1 et 2
- communications qui coupent au bout d'une 40ènes de secondes (et les WARNING de retransmissions qui vont avec dans la console Asterisk) si appel entre les téléphones du réseau 1 et 2

Merci de ta réponse Cool34000

En fait je ne connais pas les symptômes exacts du pb tél.
Le presta. tél. a juste bêtement accusé le firewall... et moi je dois essayer de me défendre monsieur le juge !
Les pb que tu décris cependant semblent être les bons. Je suis pratiquement sûr que le routeur VOIP natte les communications entre le réseau 192.168.16.0 et me réseau 192.168.1.0 (c'est pas ce que fait un routeur normalement ?)...
Je voudrais bien lui soumettre ton analyse mais avec une certitude supplémentaire que Zentyal n'a rien à voir dans SON problème de VOIP.
On était sur site au même moment avec le presta. VOIP et nos relations étaient plus ou moins cordiales donc je n'ai aucune raison de lui en vouloir mais comme il est plus calé que moi sur le réseau, il me prend de haut et dédouane le pb sur moi.
Moyen comme comportement
Thanx !

[Cool34000]

Re...

En fait je ne connais pas les symptômes exacts du pb tél.

Il va pourtant falloir pour diagnostiquer correctement le problème ! (difficile de corriger un problème qu'on ne peut pas décrire...)

Le presta. tél. a juste bêtement accusé le firewall... et moi je dois essayer de me défendre monsieur le juge !

C'est un très mauvais argument de sa part !
En réduisant au maximum, Zentyal est juste ton routeur Internet...
Ton seul besoin est de créer une route pour atteindre le réseau 192.168.16.0/24 comme ton prestataire te l'a demandé (sinon les paquets à destination de ce réseau seront envoyés sur Internet !)
Si Zentyal est ta passerelle par défaut alors revérifie ta route statique dessus (si ce n'est pas déja fait X fois).

Le reste se passe coté routeur VoIP...
Surement un problème de NAT comme déja expliqué, d'ou l'intêret de demander les symptomes aux utilisateurs (ou encore mieux : vérifier par soi même)

[jibe]

Salut,

[Edit]Cool34000 a apporté quelques précisions intéressantes pendant que je postais... Cela vient nuancer certains de mes propos, et en confirmer d'autres ! [/Edit]

Vu que Cool34000 doit maintenant suivre le sujet, je vais le laisser faire : c'est vraiment sa partie !

Toutefois, (et contre l'avis de jdh => j'ai peut-être tort, mais un essai de quelques minutes ne coûte vraiment pas grand chose), j'aurais bien tenté de débrancher purement et simplement Zentyal. Tu en aurais ainsi le coeur net !

Concernant l'accusation du prestataire VoIP et en reprenant les termes juridiques, tu as la présomption d'innocence et la charge de la preuve lui revient S'il est si câlé en réseau, qu'il te démontre comment ton serveur Zentyal peut foutre la merde (je profite que la censure automatique ne soit pas en place ), et s'il est malin la meilleure façon de le démontrer est de prouver que sans lui tout fonctionne bien, et avec lui non A moins que, comme le suppose jdh, les routes statiques interviennent... C'est vrai que si tu as mis en place des règles pour cela sur ton Zentyal, ça peut jouer, mais ces règles sont-elles bien utiles ? Et les règles de QOS pour le LAN ? Là, Cool34000 (et probablement jdh) devrai(en)t pouvoir expliquer tout cela.