Fritz!Box 7270 hinter Linux Router Voip

[heppth]

Hallo,

ich habe einen Linuxrouter, der die Internetverbindung herstellt. Dahinter ist eine Fritz!Box 7270 mit einrerichteten VoIP (sipgate).

Zunächst habe ich versucht das NAT-Problem über den STUN-Server zu lösen. Resultat: Beim raustelefonieren kann ich den Gesprächspartner nicht höhren. Er jedoch mich. Bei eingehenden anrufen funktioniert alles.

Nun habe ich die Vermutung, dass ich da noch irgendetwas an der iptables Firewall des Linuxrouters verändern muss. Nur leider bin ich was Linux/Netzwerk angeht nicht wirklich bewandert. Weis jemand, was ich tun muss?

Vielen Dank!!!

 

[pibi]

Sorry, dass ich mich hier anschliesse, aber ich habe das gleiche Problem und dieselbe Hardware (FB 7270 mit aktueller Firmware hinter einem Linux-Router).

Anfangs (vor etwa zwei Jahren) hat alles wie gewuenscht funtioniert. Dann habe ich die FB direkt ans IN angeschlossen und die internen Routing-Funktionen genutzt. Nun musste ich aber die FB wieder ins interne Netz integrieren. Seither kann ich nur noch mit anderen sipcall.ch-Teilnehmern telefonieren. Wie gesagt: Ich benutze zwar sipcall.ch als Provider, aber ich denke, dass das nur am Rande eine Rolle spielt, das Problem ist meiner Meinung nach eine Firewall-Einstellung.

Wenn ich die FB direkt am Kabelmodem anschliesse, funktioniert alles wie gewuenscht. Ich muss die FB aber zwingend im internen Netz betreiben.

Bei Calls auf CH-Festnetz oder -Mobilanschluesse hoere ich weder den Rufton noch den angewaehlten Teilnehmer. Er dagegen hoert mich. Der Support von sipcall.ch konnte mir bisher nicht weiterhelfen.

Ich leite auf meinem Router alle incoming UDP-Requests (ohne Einschraenkung der Source-IP) sowohl auf den Ports 5060 bis 5070 als auch 7070 bis 7100 auf meine FritzBox weiter.
Wie gesagt, anfangs (ca. vor 2 Jahren) hat es mit exakt diesen
Einstellungen funktioniert, als ich die FB gekauft habe.

Alle abgewiesenen Verbindungsversuche werden in /var/log/firewall protokolliert. Dort steht aber nichts auffaelliges.

Welche Infos fehlen noch?

Gruss Pit.

PS: Server und Firewall ist SuSELinux 11.2

 

[heppth]

Hallo pibi,

so in der Art habe ich es auch schon probiert. Kein erfolg. Nur noch ein Tipp: Wenn du das ganze via Portforwading machst, musst du den STUN-Server raus nehmen. Du kannst dann auch mal probieren den Proxy leer zu lassen.

Ich habe das Thema Portforwading schon aufgegeben. Da mein snom das auch ohne Portforwarding schafft, muss das die FB auch können.

Ich habe mich an Sipgate Support und an AVM Support gewendet. AVM habe ich Logs gesendet. Warte aber noch auf eine Antwort. Das Thema ist auf jeden Fall noch aktiv.

Wir kriegen das schon noch hin ;-)

 

[grbde]

Hoi, Ihr alle,

@heppth: Genau so eine Konfiguration läuft hier mit sipgate völlig problemlos, nur Skype-SIP zickt noch 'rum. Mein erster Schuss: Hast Du dem STUN-Server den Port mitgegeben (normalerweise 10000, der Eintrag sieht also z.B. so aus: stun.sipgate.net:10000)? Irgendwie scheint es so zu sein, dass ein Teil der ausgehenden Pakete ja zurückkommt - der Ruf wird offensichtlich ja aufgebaut -, ein anderer Teil nicht - die, welche die Voice-Information transportieren. Wie hast Du denn das UDP-Routing in der Firewall gelöst?

Ansonsten erzähle uns doch noch ein bisschen mehr über Deine Kofiguration, und die Fehlermeldungen der Fritz-Box wären vielleicht auch erhellend.

@pibi: Wie gehst Du denn 'raus, hast Du einen Proxy oder STUN-Server angegeben? Wenn ja, welchen?



Viele Grüße aus dem verschneiten Saxenwald

Gunnar.

 

[pibi]

Hoi Gunnar

Danke fuer die Antwort. Ich richte mich genau nach der Anweisung des Sipcall-Support-Teams:
[zitat ON]
Als Registrar und Proxy ist pro1.voipgateway.org korrekt. Wir verwenden keinen Stun-Server.
[zitat OFF]

Und langsam sollte die ganze Geschichte wirklich funktionieren. Wie gesagt: Nach dem Kauf der Occasions-FB mit der damaligen aktuellen Firmware (irgendwo habe ich sicher noch einen Backup...) hat alles perfekt geklappt. Nebst den diversen Updates der FB hat auch in dieser Zeit sipcall.ch die Einwahlparameter geaendert.

Anyway: Diese Versuche haben fuer mich den initialen Funken gegeben, meinen ISDN-Anschluss zu kuendigen und in der FB als nicht vorhanden zu deklarieren. Laut Gedaechtnisprotokoll fingen etwa in dieser Zeit die Probleme an:-(

Da ich aber gleichzeitig die FB direkt ins IN gehaengt und als "Internet-Router" configuriert habe, war fuer mich alles OK. Daher kann ich leider nicht genau sagen, seit wann und welcher Aenderung die Probleme anfingen. Ich war einfach happy, eine Alternative zur teuren Swisscom zu haben mit vergleichbarem Funktionsumfang.

Momentan geht auch ein Call von meinem Sipcall auf einen CH-Festnetzanschluss nicht mehr. Dies hat aber definitiv vor kurzer Zeit noch geklappt. Wissentlich/Willentlich habe ich alle Firewall-/Routing-Einstellungen nach bestem Wissen und Gewissen restauriert. Super-strange!

Gruss Pit.

 

[grbde]

Hoi, Pit,

Jau, das mit ohne STUN bei Sipcall ist richtig, die haben wohl einen anderen Mechanismus die IP hinter der Firewall 'rauszukriegen.

Stellt sich die Frage nach dem UDP-Transport durch die Firewall. Was genau steht denn da in der /var/log/firewall, bezüglich der SIP/UDP-Packages?

Wie hast Du die Weiterleitung spezifiziert (mit Yast oder händisch)? Funktioniert die Weiterleitung? Hier ist Wireshark Dein Freund - ich weiß, da muss man sich ein bisschen hineinfummeln, aber man gewinnt Erkenntnis!

Viele Grüße aus dem hohen Norden

Gunnar.

 

[pibi]

Stellt sich die Frage nach dem UDP-Transport durch die Firewall. Was genau steht denn da in der /var/log/firewall, bezüglich der SIP/UDP-Packages?

Eben steht leider nix drin, denn sonst haette ich die Regeln laengst erweitert und koennte problemlos telefonieren. Alle abgewiesenen Pakete werden bei mir in /var/log/firewall geloggt, wie Du richtig erkannt hast. Oder habe ich das selber geschrieben?

Wie hast Du die Weiterleitung spezifiziert (mit Yast oder händisch)?

Ich bin ein Selfmade-Man Dank des Logs kann man wunderbar die Firewall anpassen. Bis anhin hat das auch wunderbar geklappt.

Eigentlich bleibt nur noch die Moeglichkeit, dass Pakete bereits vor den Regeln "Internettelefonie" von einer anderen weiter vorne stehenden Regel bereits verworfen werden und dass deswegen nix geloggt wird. Aber ich meine, dass ich das bereits gecheckt habe. Am Wochenende gehe ich nochmal ueber die Buecher.

Funktioniert die Weiterleitung? Hier ist Wireshark Dein Freund - ich weiß, da muss man sich ein bisschen hineinfummeln, aber man gewinnt Erkenntnis!

Welche Weiterleitung? Und Wireshark ist gut und schoen, aber mit diesem Tool habe ich so gut wie keine Erfahrung. Gehe ich recht in der Annahme, dass ich zuerst mal eine erfolgreiche Verbindung mitschneiden (also die FB wieder in den Keller direkt am Kabelmodem anschliessen) und danach mit einem Mitschnitt eines fehlgeschlagenen Anrufs vergleichen muss?

Gruss Pit.

 

[pibi]

Wie hast Du die Weiterleitung spezifiziert (mit Yast oder händisch)?

Hier die massgebenden Einstellungen. Vielleicht kannst Du es ja mal mit den Deinigen vergleichen. Ich habe erst an Deiner Signatur gesehen, dass wir ja eine sehr aehnliche Umgebung haben. Vielleicht hast Du ja einen konkreten Tip fuer mich

[...]
FRITZ_IP=192.168.10.250
FRITZ_PORTS=5060:5070,7070:7100
[...]
# flush and delete all chains
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD

$IPTABLES -F
$IPTABLES -X
$IPTABLES -t nat -F
$IPTABLES -t nat -X
$IPTABLES -t mangle -F
$IPTABLES -t mangle -X

# default policy, DROP anything
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP
[...]
# Erlaube alles, was zu einer bestehenden Verbindung gehoert
# Um festzulegen, was darueber hinaus erlaubt wird, --state NEW benutzen
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
[...]
# Fritz!Box: Download von Firmware-Udates via ftp bzw. http
$IPTABLES -A FORWARD -p tcp -s $FRITZ_IP -o $EXT_DEVICE --dport ftp -m state --state NEW -j ACCEPT
$IPTABLES -A FORWARD -p tcp -s $FRITZ_IP -o $EXT_DEVICE --dport http -m state --state NEW -j ACCEPT
# die Uhrzeit moechte sie auch erfahren (NTP)
$IPTABLES -A FORWARD -p udp -s $FRITZ_IP -o $EXT_DEVICE --dport ntp -m state --state NEW -j ACCEPT

$IPTABLES -A FORWARD -p udp -s $FRITZ_IP -o $EXT_DEVICE -m multiport --sport $FRITZ_PORTS -m state --state NEW -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -p udp -s $FRITZ_IP -o $EXT_DEVICE -j MASQUERADE
$IPTABLES -A OUTPUT -p udp -o $EXT_DEVICE -m multiport --sport $FRITZ_PORTS -m state --state NEW -j ACCEPT

$IPTABLES -t nat -A PREROUTING -p udp -m multiport --dport $FRITZ_PORTS -i $EXT_DEVICE -j DNAT --to $FRITZ_IP
$IPTABLES -A FORWARD -p udp -i $EXT_DEVICE -d $FRITZ_IP -m state --state NEW -j ACCEPT
[...]

Gruss Pit.

 

[grbde]

Hoi, Pit,

so richtig kann ich zu Deinem IP-Tables-Listing nichts sagen, ich nutze das SuSEFirewall-Script. Da sehen die iptables natürlich ganz anders aus.

> Eben steht leider nix drin

Logge doch 'mal bitte alle durch die Firewall gehenden Pakete, dann müssten die auch zu sehen sein.

> Wireshark ist gut und schoen, aber mit diesem Tool habe ich so gut wie keine Erfahrung.

Macht nix. So schwierig ist der Umgang damit - zumindest für den Anfang - nicht, und Du findest auch viele Ressourcen im Internet. Der Vorteil wäre halt, dass wir wüssten, was auf Paketebene passiert. Und denke daran - Du musst es auf dem Server nutzen, auf der Schnittstelle zum internen Netz.

> zuerst mal eine erfolgreiche Verbindung mitschneiden

Im Prinzip hast Du recht. Aber man könnte überhaupt erst einmal sehen, was passiert, denn die Fritz-Box liefert auch Fehlermeldungen zurück.

Viele Grüße aus dem Saxenwald

Gunnar.

 

[pibi]

zuerst mal eine erfolgreiche Verbindung mitschneiden

Nicht mehr noetig;-)

Ich bin ein verdammter Trottel! Mea culca, mea maxima culpa! Oder wer Asterix nicht kennt: "Alles meine Schuld!"

Meine Infrastruktur besteht aus zwei Servern, die am Internet haengen und als Gateway eingerichtet sind mit allen noetigen Programmen und Tools. Auch die Firewall-Einstellungen sind gleich. Dachte ich jedenfalls. Bei irgendeinem Restore habe ich auf Server2 (der eigentlich als Reserve dienen sollte), die Firewall-Einstellungen auf einen uralten Stand zurueckversetzt. Zudem habe ich nicht bemerkt, dass dieser (faelschlicherweise) als Standard-Gateway im DHCP definiert war.

So nahm das Unheil seinen Lauf. Ich modifizierte die Firewall-Settings auf Server1, dabei fungierte Server2 als Gateway. Ich daemlicher Trottel!

Grund fuer das Nicht-Funktionieren war eine Port-Ueberschneidung in den Forward-Einstellungen der Ports. Faelschlicherweise wurden Ports > 6000 an eine andere Maschine im internen Netz weitergeleitet, die FB bekam sie nie zu sehen:-(

Jetzt habe ich es korrigiert, eine Kontroll-Anruf in Deutschland hat wunderbar funktioniert. Sorry fuer den falschen Alarm.

Als kleine Wiedergutmachenung werde ich Euch ich den naechsten Tagen (aber definitiv erst *nach* den Weihnachtsfeiertagen) eine kurze Zusammenstellung der notwendigen Firewall-Settings zukommen lassen fuer diejenigen, die "haendisch" konfigurieren.

Merci fuer den Einsatz. Geruhsame Festtage und einen Guten Rutsch ins 2011 wuenscht

Pit.

 

[grbde]

Hoi, Pit,

schön zu hören, dass es jetzt geht. Wie immer, steckt der Teufel halt im Detail...

Dir und allen hier die besten Grüße für eine beschauliche Weihnacht und einen guten Rutsch in's neue Jahr - und dann machen wir weiter mit dem Wahnsinn!!!

Alles gute aus dem weißen Saxenwald


Gunnar.