Question technique protocole SIP & FW

Bonjour à tous.
J'ai un petit souci au niveau d'un de mes firewalls, qui a tendance a bloquer des INVITE.

Donc quand un téléphone (aastra 6757i) lance un INVITE vers le serveur, celui ci est bloqué par le firewall, et le téléphone (ne voyant pas de réponse a l'INVITE arriver), continue a émettre des INVITE a raison d'environ 1 par seconde.

Est-ce un comportement normal ?

Est ce que quelqu'un aurait une piste pour régler ce problème de firewall qui me tracasse depuis plusieurs mois ?
je précise que mes téléphones et mon asterisk sont dans deux lans différents, mais qu'il n'y a pas de NAT (routage only).
le firewall est une machine linux (kernel 2.6.36.2 tout beau tout neuf, mais même probleme avec ancien kernel). kernel compilé en statique avec le module sip_contrack.

Si quelqu'un a la moindre idée ou piste... je suis preneur.
Cdt

EDIT : je précise que ce problème est complètement aléatoire. Il peut ne pas se produire pendant 3 semaines et ensuite survenir 5 fois dans la même journée.

C'est l'INVITE qui est bloqué, ou bien la réponse à celui-ci ?

L'invite

La réémission de l'INVITE semble logique (pas forcément de cette manière mais bon), mais est-ce que ça finit par s'arrêter ?

Un peu de théorie:

Citation:

---

Afin de palier aux pertes éventuelles de messages possibles si UDP est utilisé SIP doit donc avoir ses propres mécanismes de retransmissions. Les requêtes émises par les UAC sont donc retransmises périodiquement jusqu’à réception d’une réponse de l’UAS. Plus spécifiquement pour les requêtes de type INVITE, l’UAC réémet la requête au bout d’une durée initiale de T1 secondes qui double à chaque réémission. L’UAC cesse de réémettre s’il reçoit une réponse de l’UAS ou s’il a réémit le paquet 7 fois.

---

Pour le pare-feu, une idée de la règle qui le bloque ? As-tu tenté de journaliser les blocages ?

Citation:

---

Envoyé par ffossard

La réémission de l'INVITE semble logique, mais est-ce que ça finit par s'arrêter ?

Un peu de théorie:


Pour le pare-feu, une idée de la règle qui le bloque ? As-tu tenté de journaliser les blocages ?

---

Non, aucune idée de la règle qui bloque, puisque ça ne bloque que très rarement.

J'ai arrêté ma capture au bout d'environ 1 minutes, et j'ai 49 requetes invite envoyées par mon téléphone...

le temps d'attente n'est pas doublé entre chaque réemission

L'invite lancé par le téléphone vers le serveur se fait forcément sur le port SIP du serveur (5060 ou ou celui que tu as défini).
Je suppose que tu autorises toutes les communications sortantes de ton réseau téléphone sur le port SIP du serveur ?
J'ai du mal à comprendre comment cela peut bloquer ? Quel numéro de port le téléphone tente t'il de contacter ?

Bonjour a tous.

j'avance un peu.
Suite a la mise ajour du kernel de notre FW (passé en 2.6.36.3), nous avons vu dans le kernel.log des lignes de ce genre :

Code:

---

Jan 18 11:30:08 sar-fw1 kernel: nf_ct_sip: dropping packetIN= OUT=eth1.98 SRC=10.205.29.171 DST=x.x.x.x LEN=1005 TOS=0x10 PREC=0x60 TTL=63 ID=4241 PROTO=UDP SPT=5060 DPT=5060 LEN=985
Jan 18 11:30:10 sar-fw1 kernel: nf_ct_sip: dropping packetIN= OUT=eth1.98 SRC=10.205.29.171 DST=x.x.x.x LEN=1005 TOS=0x10 PREC=0x60 TTL=63 ID=4243 PROTO=UDP SPT=5060 DPT=5060 LEN=985
Jan 18 11:36:40 sar-fw1 kernel: nf_ct_sip: dropping packetIN= OUT=eth1.98 SRC=10.205.29.164 DST=x.x.x.x LEN=1005 TOS=0x10 PREC=0x60 TTL=63 ID=52271 PROTO=UDP SPT=5060 DPT=5060 LEN=985
Jan 18 11:36:41 sar-fw1 kernel: nf_ct_sip: dropping packetIN= OUT=eth1.98 SRC=10.205.29.164 DST=x.x.x.x LEN=1005 TOS=0x10 PREC=0x60 TTL=63 ID=52286 PROTO=UDP SPT=5060 DPT=5060 LEN=985
Jan 18 11:36:42 sar-fw1 kernel: nf_ct_sip: dropping packetIN= OUT=eth1.98 SRC=10.205.29.164 DST=x.x.x.x4 LEN=1005 TOS=0x10 PREC=0x60 TTL=63 ID=52289 PROTO=UDP SPT=5060 DPT=5060 LEN=985
Jan 18 11:36:44 sar-fw1 kernel: nf_ct_sip: dropping packetIN= OUT=eth1.98 SRC=10.205.29.164 DST=x.x.x.x LEN=1005 TOS=0x10 PREC=0x60 TTL=63 ID=52291 PROTO=UDP SPT=5060 DPT=5060 LEN=985
Jan 18 11:38:24 sar-fw1 kernel: nf_ct_sip: dropping packetIN= OUT=eth1.98 SRC=10.205.29.164 DST=x.x.x.x LEN=1004 TOS=0x10 PREC=0x60 TTL=63 ID=57376 PROTO=UDP SPT=5060 DPT=5060 LEN=984

---

ou :
10.205.29.164 est l'adresse IP ed mon téléphone
x.x.x.x est l'adresse de mon ipbx.

TOUJOURS PAS DE NAT

Donc le firewall drop bien des paquets, mais nous n'arrivons pas a comprendre pourquoi.

Après recherches, nous avons augmenté certaines valeurs dans sysctl.conf :

Code:

---

net.ipv4.netfilter.ip_conntrack_max = 262144
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 28800
net.netfilter.nf_conntrack_expect_max = 4096

---

mais ça n'a toujours pas réglé le problème.

Est ce que quelqu'un à une idée ?
il est vrai que ce problème ne concerne plus du tout asterisk, mais j'alimente quand même, en me disant que quelqu'un aura peut-être le même problème que moi !

Rico

salut
j'ai (preque) les mêmes logs quand je droppe volontairement des paquets via iptables. en regardant test logs, je vois en plus:
nf_ct_sip

un ptit google lance des références sur: netfilter, qui si j'ai bien lu freud, est cousin de iptables

a vue de nez, tu as netfilter d'installé, qui de temps en temps décide que ton SIP est pas bon... je te suggère de googler plus en détail nf_ct_sip pour comprendre un peu mieux (mais moi, j'en sais pas plus !), ou de chercher les logs de netfilter

fos !

J.

Salut,
j'ai déja googeulizé pas mal tout ça, et la j'arrive au bout, je ne trouve plus grand chose.

stopper iptables ou netfilter n'est pas envisageable, je suppose ?

Citation:

---

Envoyé par jean

stopper iptables ou netfilter n'est pas envisageable, je suppose ?

---

Je réponds à sa place, non :wink:

Citation:

---

Envoyé par ffossard

Je réponds à sa place, non :wink:

---

Je confirme, c'est notre firewall de tête de réseau....

Pour ma culture générale, votre FW est donc une box linux ? c'est truc packagé, ou vous avez pris un linux et configuré en fw ?

Pour info, certains modems (netgear) ont des fonctions "SIP ALG", qui permettent de faciliter le NAT - en pratique, il convient de désactiver - peut être que ton FW fait ça aussi.

Sinon, comment se passe l'entrée des packets ? doivent ils être forcément en réponse à un packet emis / sortant depuis ton réseau ? dans ce cas, tu as un timer max à régler.

Note que dans tes réglages présentés:
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 28800

celui là est inefficace puisque tcp - il faudrait trouver son équivalent en udp.


Eric