VoIP unter Linux (Debian, ipv4 netfilter) und IPCop

[Phil]

Ok, nachdem ich herausgefunden habe, dass es nicht an evtl. gesperrten Ports liegt, dass hier im StudWohnheim VoIP nicht geht habe ich neue Infos bzw. eine neue Problemstellung.

An der FH läuft ipv4 auf einem Debian System als Firewall.
Es gibt wohl ein Modul, dass VoIP funktionieren lässt. Dieses Modul ist aber bisher nicht integriert.

Kann mir jemand helfen?
Es MUSS ein Kernel-Modul sein, sonst kann es nicht "installiert" werden...

Auf dem Backup-System des StudWohnheimes läuft nicht ipv4 netfilter, sondern IPCop als Firewall. Mit diesem System hat VoIP funktioniert, das bedeutet, dass dort die VoIP-Funktionalität evtl. sogar als Standard implementiert ist.

Ich hoffe, hier gibt es wen, der sich mit Linux in Verbindung mit den o.g. Firewalls auskennt....

 

[hank]

Hmm, was meinst du mit "IPv4 firewall" ?? Wahrscheinlich netfilter / iptables, huh?

Ich kenne kein kernel-Modul, dass "Voip funktionieren lässt" (link). Entweder,
a) die FW macht stateless port forwarding von 5060/udp für SIP und ein paar udp-ports für RTP auf die (fixe) IP von deinem SIP client, oder
b) dein SIP client ist in der Lage, per STUN / UDP-hole-punching durch die firewall durch sich zu registrieren, oder
c) auf der firewall läuft ein SIP proxy (z.B. siproxd, Asterisk, SIP Express Router), der die SIP pakete / header umschreibt.

Bei mir haben a) und b) nicht richtig funktioniert, immer gabs es irgendwelche Probleme mit nur einseitigem Ton oder nur einseitiger Signalisierung - aber andere Leute haben das (unter anderem auch hier im Forum) sicher schon hinbekommen. Ich habe mich dann für c) entschieden, da ich dort die beste Flexibilität habe.

Eine Uni oder ein Studentenwohnheim sollten sicherlich auch an c) Interesse haben, damit eine große Gruppe von usern den Dienst nutzen kann.

 

[Phil]

Danke für die Antwort.
Ja, habe netfilter gemeint....

Dann werde ich das mal mit dem SIP-Proxy in angriff nehmen....

Oder hat jemand anderes noch eine Idee?

 

[otaku42]

Es gibt wohl ein Modul, dass VoIP funktionieren lässt. Dieses Modul ist aber bisher nicht integriert.

Eventuell beziehst Du Dich auf einen NAT-Helper, der aber fuer SIP zum einen nicht existiert, und zum anderen nicht notwendig ist. Einen solchen NAT-Helper gab/gibt es fuer H.323, aber wenn Du kein H.323 benutzt, wirst Du das auch nicht brauchen.

Auf dem Backup-System des StudWohnheimes läuft nicht ipv4 netfilter, sondern IPCop als Firewall.

IPCop ist eine Linux-Distribution, die wiederum Netfilter verwendet.

Ueblicherweise sollte Dein Client problemlos durch die Firewall kommen, wenn er STUN beherrscht (sofern der Dienst korrekt installiert ist und die Firewall ausgehende Anfragen auf bestimmten Ports nicht absichtlich blockt). Das waere die einfachste Loesung.
Die andere Moeglichkeit bezueglich SIP-Proxy wurde ja schon genannt. Von einfach kann man hier aber in der Regel nicht mehr sprechen.

 

[Phil]

So....jetzt habe ich mein ATA + Telefon, aber das gleiche Problem: Verbindung kommt zustande, aber Sprache wird nicht übertragen.

@otaku: Was meinst du mit "ausgehenden Anfragen auf bestimmte Ports"?

Es kann ja irgendwie nicht sein, dass es mit dem einen System klappt, und mit dem anderen nicht. Da muss es ja einen kleinen Unterschied geben.
Was hat IPCop, was Debian (mit netfilter ipv4) nicht hat? Hat jemand vielleicht eine Idee?

 

[otaku42]

@otaku: Was meinst du mit "ausgehenden Anfragen auf bestimmte Ports"?

Damit meine ich, dass Pakete, die aus dem lokalen Netzwerk nach draussen ins Internet gehen sollen, nicht von der Firewall ausgefiltert werden. Das ist aber eher selten der Fall und wird wohl eher wissentlich von Admins konfiguriert als automatisch durch die verwendete Distribution.

Was hat IPCop, was Debian (mit netfilter ipv4) nicht hat? Hat jemand vielleicht eine Idee?

Eine andere Firewall-Konfiguration?

 

[Phil]

Schon.....aber es kann ja nicht an vielen verschiedenen Einstellungen liegen, wenn sonst alles gleich ist und gleich funktioniert.....

Aber ich glaube so langsam, die Admins haben einfach keine Lust, sich näher damit zu befassen und die Firewall richtig einzustellen

 

[Phil]

Ich habe noch ein wenig recherchiert und habe folgende interessante Seite gefunden: http://linuxwiki.de/VoiceOverIp#head-9c477726980eec690f3c67b14049b991487c23e2

Was soll ich von dem Satz: "Das Problem von SIP ist es, dass es anscheinend beliebige Ports für das Gespräch selbst braucht" halten?
Heißt das, dass im Grunde fast alle UDP-Ports geöffnet sein müssen, damit das Protokoll SIP problemlos fuktioniert? Das kann ja auch nicht sein...

 

[hank]

Nicht ganz beliebig

Also jeder RTP stream benötigt 2 UDP ports. Typischerweise werden diese aus einer Range zugewiesern, die im (Soft-)phone oder SIP Proxy festgelegt wird. Dazu kommt der Signalling-Channel, der ja eigentlich immer auf udp/5060 laeuft.

Sprich, die firewall *muss* udp/5060-zu-udp/5060 und eine udp-Range (mindestens 2 Ports pro parallelem Gespräch) erlauben. Die Range muss dann auch im SIP client (Softphone / Hardphone) nachgetragen werden.

 

[Phil]

Ach...ich werde an diesem Problem noch verzweifeln..... :cry:
Und der zuständige Admin kann das Problem auch nicht eindeutig identifizieren bzw. hat keine Lust/Zeit dazu.

Dabei kann es sich doch nur um eine Kleinigkeit handeln, wenn NUR keine Audiodaten übertragen werden, sonst aber alles klappt...

Die Ports 5060, 5062, 10000-10012, 30000-30021 sind alle offen....

Wie kann ich z.b. herausfinden, wo es hängt bzw. wo die Daten nicht durchkommen? Welche Verbindungen aufgebaut werden, kann ich ja z.B. mit netstat kontrollieren....

Bei Gelegenheit werde ich mal den Admin fragen, ob er für eine Minute einfch mal alle Ports öffnet, sodass ich ausprobieren kann, ob es vielleicht doch an irgendwelchen anderen Ports hängt...

:bahnhof:

 

[hank]

Was für einen SIP client verwendest du denn? Hast Du die Ports konfiguriert? Klingt mir recht stark nach der default config für SIPPS... Die 10000er ports sind fuer STUN, die 30000er ports sind die RTP ports und 5060 ist natürlich das signalling.

Zum troubleshooting würde ich zwei Sachen vorschlagen: Einige Softphones (e.g. Xlite und SJphone) bieten das "loggen" des SIP traffics an - dort sieht man oft schon interessante Sachen (e.g. das sich proxy und SIP client nicht auf einen codec einigen können, etc). So ein log kannst Du hier posten und hoffen, daß jemand es entziffern kann.

Parallel dazu würde ich mit ethereal / tcpdump / snoop / winpcap / ... eine gesamte session "aufnehmen" und analysieren. Wenn das hier jemand anschauen sollte, müsstest du es wahrscheinlich zippen und hochladen. Ausserdem wären infos über dein Network environment sinnvoll, wie deine IP, IP vom gateway, IP vom SIP proxy / SIP registrar...
Vielleicht aber erstmal mit einem admin checken, ich weiss nicht, wie das ist mit dem hochladen von (grösseren ?) files...

 

[Phil]

Was für einen SIP client verwendest du denn? Hast Du die Ports konfiguriert? Klingt mir recht stark nach der default config für SIPPS... Die 10000er ports sind fuer STUN, die 30000er ports sind die RTP ports und 5060 ist natürlich das signalling

Ich habe X-Pro, SIPPS und ATA ausprobiert, aber nichts ging.
Die Sache ist ja, dass es nicht an meinem Rechner oder am Proxy liegen kann, weil es ja über eine andere Firewall (=anderer Server) funktionierte. Nur leider war dies ein Backup-System und war nur in Betrieb, weil der andere Server abgestürzt war.

Bezüglich der Logs. Ich habe dem Admin auch mal meine Logs von X-Pro und SIPPS geschickt, aber ´bis jetzt habe ich keine Rückmeldung erhalten....

 

[mddtommy]

Alt aber immer noch wichtig

Ich weiss, dieser thread ist schon sehr alt.. aber ich hatte das gleiche Problem...

Verwende ein Elmeg IP Telefon an einem Debian Server mit netfilter / iptables..

Vorher habe ich das telefon über mein Windows XP als Gateway ohne Probleme nutzen können. Da ich jetzt mein Debian als DSL-Router einsätze, musste natürlich auch im Telefon "nur das Gateway" umgestellt werden, so dachte ich.. aber pustekuchen...!

Lösung:

Als erstes NAT und Port forwarding aktivieren (falls noch nicht geschehen ist.. also damit überhaupt der Debian Server als "gateway" fungiert...:

# NAT modul laden
modprobe iptable_nat
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
# IP-Forwarding aktivieren
echo 1 > /proc/sys/net/ipv4/ip_forward

Das einfach ans ende der /etc/ppp/ip-up
die ip-up datei wird jedes mal nach erfolgreichem Verbindungsaufbau gestartet. Am Ende der Datei ist ein guter ort für die Sonderfall PortForwarding Aufgaben....



wenn jetzt mit

pon dsl-provider

eine Verbindung aufgebaut wird, müssten andere Rechner über den Debian Router surfen können. Wenn nicht brauchst du hier nicht weiterlesen.
Kleiner Tip: cat /etc/resolve.conf zeigt dir deine DNS Server an.. die musst du bei deinen dosen natürlich auch eintragen!

Mein Elmeg Voip Telefon hat bei mir die IP Adressee 192.168.0.99

# voip freigabe für elmeg telefon
iptables -t nat -A PREROUTING -p udp --dport 5060 -i ppp0 -j DNAT --to 192.168.0.99
iptables -A FORWARD -p udp -d 192.168.0.99 --dport 5060 -o eth1 -j ACCEPT

Das einfach ans ende der datei /etc/ppp/ip-up hängen... Fertig!

Total OffTopic, aber dank Google vielleicht auch eine Hilfe für ein ähnlich gelagertes Problem..

Stichwort Emule auf Windows an Debian als Router.... => LowID

Lösung:

Der Windows Rechner auf dem Emule laufen soll hat im Beispiel die 192.168.0.1 als ip

# emule ports durchreichen:
iptables -t nat -A PREROUTING -p tcp --dport 5881 -i ppp0 -j DNAT --to 192.168.0.1
iptables -t nat -A PREROUTING -p udp --dport 5906 -i ppp0 -j DNAT --to 192.168.0.1
iptables -t nat -A PREROUTING -p tcp --dport 24500:24505 -i ppp0 -j DNAT --to 192.168.0.1
iptables -A FORWARD -p tcp -d 192.168.0.1 --dport 5881 -o eth1 -j ACCEPT
iptables -A FORWARD -p udp -d 192.168.0.1 --dport 5906 -o eth1 -j ACCEPT

Das auch wieder ans ende der datei /etc/ppp/ip-up hängen... Fertig! Auch hier gilt natürlich, das das Gateway als solches bereits funktioniert (siehe oben)

viel Spaß

 

[mddtommy]

nachtrag

und wer lieber azureus auf seiner dose nutz:

#azureus
iptables -t nat -A PREROUTING -p tcp --dport 6881:6889 -i ppp0 -j DNAT --to 192.168.0.1
iptables -A FORWARD -p tcp -d 192.168.0.1 --dport 6881:6889 -o eth1 -j ACCEPT