flux dans tunnel vpn

[mistergorgo]

Bonjour les amis,
j'ai déjà installé un pbx chez un client relié à deux autres sites en vpn sans aucun probleme.
Fort de cette expérience, je fais la même install entre deux sites d'une même boîte relié en vpn ipsec.
Et là problème.
en interne:
sip fonctionne bien, ça sonne des deux côtés et quand un raccroche ça raccroche de l'autre côté aussi
mais le flux audio ne va que dans un sens.
vers exterieur:
depuis le site dit distant (celui donc dans un autre subnet que le pbx),
ça sonne pour l'appelant mais pas chez l'appelé ou avec un gros décallage ou appel en absence longtemps après ou encore quand l'appelé décroche ca continue à sonner chez l'appelant. Donc sip fonctionne pas bien et là on parle même pas encore du flux audio.

J'ai fais la comparaison avec le client chez qui ça fonctionne au niveau du pbx c'est identique
j'ai bourlingué sur la toile et j'ai trouvé comment signalé à pbx qu'il y a deux subnets:
"""""
Example:
Server 192.168.1.2 on a 192.168.1.0/255.255.255.0 network
Phones inside the office are on the 192.168.2.0/255.255.255.0 subnet

Requires these two lines in the either sip_general_custom.conf or sip_nat.conf file
localnet=192.168.1.0/255.255.255.0
localnet=192.168.2.0/255.255.255.0
"""""
mais ça n'a pas résolu mon problème

j'imagine bien que le problème vient de la conf des firewalls: problèmes de nating entre les deux sites, ports rtp?
ps: les fonctions sip alg sont désactivées sur les firewalls

Quelqu'un aurait-il une bonne idée?

D'avance merci

f

[jean]

ben, d'abord je regarderai avec ngrep (mon outil favori...) que les paquets arrivent bien.

et regarder les adresses insérées dans les paquets, si elles sont correctes et routables. je ne savais pas qu'il pouvait y avoir plusieurs ligne localnet - essaie éventuellement une seule, genre 192.168.0.0/16 - tout ce qui est dans ce réseau sera routé directement - le reste prendra la valeur de externip

[mistergorgo]

bonne idée pour le subnet, je vais essayer
cependant, dans peu de temps le problème va se représenter avec des subnets très différents genre 192.168.x.x et 10.0.x.x
donc faut que je debugge ça
je me lance demain matin dans les test de ngrep tcp dump et autres joyeusetés auxquelles je ne manquerai pas de vous tenir au courant

merci pour ton intervention

[jean]

en précisant:
- si des paquets SIP se perdent, c'est un pbm de réseau/firewall etc...
- si les paquets sip voyagent bien, mais les paquets RTP se perdent (pbm d'audio), c'est un pbm de nat

en gros, ma compréhension de la logique du nat:

- si nat=no, * touche pas aux ip
- si nat=yes, il prend les adresses des ports de réception et non plus les @ contenus dans les invite. si l'@ de destination est dans le masque localnet, pas de modif, si l'@ de destination ne colle pas avec le masque localnet, il remplace les @ par externip/externhost


bon courage