Problème de NAT avec SIP

Bonjour

Pour montrer le problème de protocole SIP avec les routeurs nats et firewalls, j’ai implementer l’architecture réseau suivante :

  • Une machine A dans un LAN privé (192.168.1.0/24), avec une adresse statique 192.168.1.10. sous debian etch 4.
  • Un serveur brekeke pour SIP dans le même LAN avec une adresse statique 192.168.1.4, sous Win 7.
  • Une machine NF avec 2 interface représentant le NAT et Firewall en utilisant Netfilter 1.3 sous Debian 4. l’interface interne eth1 ayant l’@ 192.168.1.1, l’externe eth0 : 193.168.1.1.
  • Une machine B coté public avec une adresse statique 193.168.1.11.

voir le schéma suivant (le serveur ne se figure pas) :

(A)192.168.1.10------------------------------192.168.1.1 (NF) 193.168.1.1 --------------------------193.168.1.11( B )

J’ai spécifié les règles suivantes d’iptables (Netfilter) pour la machine NF (nat firewall) :

[code]----------------------------------------------------------------------------------------------
#!/bin/bash

Ce script met en place la politique de filtrage

----------------------------------------------------------------------

On charge les modules nécessaires

modprobe ip_tables
modprobe iptable-filter
modprobe iptable-nat

Initialisation des règles

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X

Politique du pare-feu

--------------------

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

Mise en oeuvre du routage

echo 1 > /proc/sys/net/ipv4/ip_forward

Autorise les paquets du protocole ICMP

iptables -A INPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
iptables -A FORWARD -p icmp -j ACCEPT

Regles du parefeu

-----------------

Autorise toute connexion deja etablie et relative

iptables -A FORWARD -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Ouverture du port 5060 pour sip

iptables -A FORWARD -p udp --dport 5060 -j ACCEPT

Regles de NAT

----------------------------------------------------

Regles de NAT sortant (partage de la connexion Internet)

Tout ce qui sort, prend l’adresse de eth0 au passage

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -p udp --dport 5060 -j SNAT --to-source 193.168.1.1:10080
-----------------------------------------------------------------------------------------[/code]

Le problème c’est avec ces 2 règles spécifiées dans ce script pour le nat :

et

Le masquerading (masquage) ne fonctionne pas avec SIP, ni l’adresse source ni le port change dans les paquet SIP, ils sortent toujours avec leur addresse/port privé (192.168.1.4/5060), et l’appel se fait avec succès, pourquoi donc le netfilter ne les change pas en sortie de l’interface eth0 de la machine NF.
Voici la figure attachée qui explique ce qui se passe normalement pour les paquets SIP :
1 invite : changement d’adresse/port source par le NAT de 192.168.0.111/5060 à 140.113.131.80/10080 (qui est non fonctionnel pour moi, c’est ça mon problème).
2 ok : blocage de ce paquet du au port 5060 qui n’est pas connu par le NAT et firewall
les paquets RTP : adresse/port (192.168.0.111/9000) adresse non routable et port inconnu.


Noter que la traversée du NAT, upnp, et nat-pmp sont désactivés au niveau de serveur Brekeke. le port utilisé par les clients et le serveur est 5060.
Netfilter version 1.3, x-lite 2, Debian 4 pour les machines A, B et NF, Win 7 Pour le serveur Brekeke.

Y a-t-il des suggestions, S.V.P ? Merci pour votre lecture, efforts, et aide.

Debian 4/Etch, c’est antédiluvien. Pourquoi ne pas utiliser la version stable actuelle (6/Squeeze) ?
La règle SNAT n’est jamais activée car tous les paquets qui pourraient y correspondre sont déjà traités par la règle MASQUERADE qui précède. Accessoirement, pourquoi vouloir changer le port source ?
Netfilter a des modules pour la prise en charge du suivi de connexion et le NAT du protocole SIP : nf_conntrack_sip et nf_nat_sip, qu’il faut charger en l’absence de prise en compte explicite du NAT par les applications SIP.
Si la règle MASQUERADE ne modifie pas l’adresse IP source de paquets qui devraient correspondre, alors c’est peut-être qu’une connexion de ce type a déjà été enregistrée avant que la règle soit en place. A vérifier dans la table des connexions suivies /proc/net/nf_conntrack. Normalement les connexions UDP expirent au bout de 2 minutes.
Cependant ce n’est pas cela qui bloque les paquets : la règle dans FORWARD prend bien le port 5060 et est appliquée avant la règle MASQUERADE. Comment vois-tu que les paquets ne sont pas NATés et sont bloqués ?

Merci pascal pour ta réponse.

rep : l’application à utilisée pour le NAT traversal (NSIS) est incompatible avec Squeeze, leur développeurs m’ont conseillé de revenir à Debian etch 4.

rep : J’ai ajouté la 2ieme règle lorsque j’ai constaté que la masquerade ne fait son role, et pour donner une précision en plus.

Donc je doit ajouter ces 2 modules et sont nécessaires.

B1 sure, c’est l’enregistrement de client externe de la machine B, une requete register est envoyée au serveur suivie d’une ask, la requete register est autorisée par la règles :

# Ouverture du port 5060 pour sip iptables -A FORWARD -p udp --dport 5060 -j ACCEPT

J’utilise wireshark pour capturer les paquets au niveau de NAT (machine NF) et la machine B ou se trouve l’appelée, comme j’ai déja cité précédemment le paquet INVITE de SIP sort avec 192.168.1.4/5060 et pas changement d’@/port, et la réponse 200 OK n’est pas bloquée.

Merci beaucoup!

Salut,

Ce qui me choque dans ton script c’est la ligne :

Je vois pas l’intérêt d’un tel ligne… En plus elle devrais se trouver avant la précédente…

Ensuite tu as :

Moi je mettrais plutôt :

[code]iptables -A INPUT -i eth0 -p udp --dport 5060 -j ACCEPT

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 5060 -j DNAT --to-destination 192.168.1.10[/code]

La première règle accepte le paquet et la seconde le redirige vers l’ip de destination.

Merci leo

Je vais tester tes 2 règles proposées a la place de la mienne, elle sont plus restrictives, demain je vous informerais s’il y aura de nouveau, à bientôt.

merci

Rien ne t’empêche d’indiquer les adresses source et destination…

En quoi est-elle incompatible ? Elle ne compile pas ? S’il s’agit de l’implémentation nsis-0.6.0 de l’université de Goettingen, la dernière version date de 2008, on peut se demander si c’est encore en développement.

Mais placée en second, elle n’a aucun effet.

Si le but est d’utiliser NSIS pour le firewall/NAT traversal, alors je dirais non, car les deux mécanismes risqueraient d’interférer de façon imprévisible.

On ne parle pas de la même chose. Je parle d’enregistrement de connexion générique au sens du suivi de connexion/NAT de Netfilter, pas au sens du protocole SIP.
En attendant avec ces informations on n’en sait pas beaucoup plus…

[quote=“leo-25”]Moi je mettrais plutôt :

iptables -A INPUT -i eth0 -p udp --dport 5060 -j ACCEPT iptables -t nat -A PREROUTING -i eth0 -p udp --dport 5060 -j DNAT --to-destination 192.168.1.10
La première règle accepte le paquet et la seconde le redirige vers l’ip de destination.[/quote]
Je pense qu’une précision s’impose : le paquet traverse PREROUTING avant INPUT, et si la destination finale est une autre machine, alors le paquet ne traverse pas INPUT mais FORWARD.
Au fait, pourquoi une règle DNAT en entrée plutôt que la règle SNAT/MASQUERADE en sortie ?

Merci pour l’info,je ne suis pas encore un pro d’IPtables, et continue à en apprendre tous les jours.

C’est comme ça que je fait d’habitude pour rediriger le trafic du WAN vers une machine… Après ce n’est pas forcément obligatoire de faire comme ça.

Ou as-tu vu dans le message initial qu’il fallait rediriger du trafic du WAN vers une machine ?

Bonjour

NSIS ne se compile pas par gcc >4.1 (4.2 peut être), des erreurs se produisent à la compilation de nsis-0.6.0 dans le module NSLP, mais nsis-0.5.0 se compile sans erreurs.
En fait, je suis revenu à Debian 4 en suivant le conseil de NIKLAS Steinleitner : x-prof à goetingen, parmi les fondateurs de NSIS.

Oui, je l’ai supprimé. t’as raison.

Ces deux modules (cités auparavant) n’existent pas dans ma version Netfilter (1.3.6), il y a plutôt ip_conntrack_sip et ip_nat_sip, je l’ai pas ajouté, ils n’ont aucun effet.

Oui, il y avait des connexions enregistrées dans /proc/net/ip_conntrack.
Aucune de vos propositions des règles (PREROUTING, INPUT) permet de montrer le problème de SIP avec le NAT.
Pour l’instant j’ai écarté le serveur Brekeke de mon réseau pour rendre les choses plus simples, j’ai changé également xlite par ekiga 2.0. et je n’ai laissé que la règle masquerade dans mon script (avec les règles initiales bien sure), mais aussi :

changée à

ceci pour laisser que le NAT.

Les captures de wireshark sur la machine NAT montrent qu’il y a un masquerade pour les adresses sources mais sans changement de port, et le paquet ringing n’est pas acheminé par le NAT à l’appelant (machine A). effectivement j’ai trouvé un problème ou l’appel échoue mais ce n’est pas comme expliqué dans la figure de mon premier message (à cause de port destination inconnu).
voici mes captures au niveau de NAT :








Le premier Trying est envoyé au appelant puisque l’adresse est publique et le port est connu, cependant le 2ieme trying n’est pas envoyé après changement de port source, j’ai pas compris, pourquoi ce changement? je pense c’est à cause des champs rport et received qui j’arrive pas à les désactiver au niveau des clients ekiga…

Et voici la capture au niveau de l’appelant qui montre qu’il n’a pas reçu les messages qui suivent le premier TRYING :



Selon mes lectures concernant le NAT traversal :
1 des articles citent que le problème est du au port inconnu lors de réception de réponse par le NAT comme dans la figure de mon premier msg,
2 d’autres citent que le client appelé utilise l’@ privée contenue dans l’entête de message INVITE de SIP qui est non routable dans le WAN.
Qui est juste?

Merci beuacoup…

Mélange avec les adresses ( très similaire ) autant pour moi…