Kann mich selbst anrufen, habe aber keinen Ton

[acmelabs]

So, hallo erstmal.

Nach dem ich das Internet komplett durchgegoogelt habe ( :wink: ) und auch das Forum hier, weiss ich mir nicht mehr anders zu helfen, als hier zu posten, in der Hoffnung, dass es einen Crack gibt, der Ahnung von der Materie hat.

Meine Konfig: FBF5070/ATA:FW_14.03.71 + 2xISDN-Fons + IPCop_1.4.6
Vorweg muss ich sagen, dass eigentlich alles funktioniert. Die FBF laeuft sauber hinter IPCop (Router), ich kann angerufen werden, und die Gespraeche gehen auch sauber raus. Registrierung ist auch kein Problem. Feine Sache das Alles also.

Das Problem:
Jetzt wollte ich meinen Esel ein wenig shapen, und hierfuer wollte ich den layer7 Filter ausprobieren. Um zu testen, wollte ich mich auf meinem 2ten Fon ueber IP anrufen, und dann die QoS Regeln optimieren. Jetzt kommts: Wenn ich mich auf meinem 2ten Fon [highlight=red:e225680f55]selbst anrufe[/highlight:e225680f55], dann klingelt das entsprechende Telefon, ich sehe mit tcpdump die UDP-Pakete ueber die Leitung huschen, aber ich hoere nichts, [highlight=red:e225680f55]kein Ton[/highlight:e225680f55] also! Im Log der FBF steht dann an einer Stelle:

...
rtp_dgramrcv: packet from 192.168.1.5 ignored, should be from 80.129.5.247
...

Anmerkung
Wenn ich die FBF vorschriftsmaessig betreibe, dann kann ich mich auf mein 2tes Fon anrufen und der Ton ist da, das funktioniert tadellos. Scheint also auf ein Firewall/Routing-Problem hinzudeuten, sprich iptables und/oder NAT. Mann, hoffentlich hat jemand eine Idee.

Gruss

 

[Matthy]

Bei mir das gleiche Problem. Ich betreibe die Fritzbox Fon WLAN 7050 mit der neusten Firmware hinter einem Fli4l-Router (2.1.11), was ich über das Webinterface so konfiguriert habe. Interne VoIP-Anrufe klingeln, aber es kommt keine Sprechverbindung zustande. Abgehende und eingehende VoIP-Verbindungen funktionieren.

Hier ein Log-Auszug:

Oct 10 21:19:27 voipd[422]: rtp_start_session(video): no session definition
Oct 10 21:19:27 voipd[422]: bridgelimit: nConnections=1
Oct 10 21:19:27 voipd[422]: number of bridge interfaces 1
Oct 10 21:19:27 voipd[422]: found bridge lan with tiwlan0
Oct 10 21:19:27 voipd[422]: bridge lan set to max 30 packets/100ms
Oct 10 21:19:27 voipd[422]: call to sip:[meine sip-nummer]@1und1.de established
Oct 10 21:19:27 voipd[422]: x-route-info: costvalue is "IP" (INVITE)
Oct 10 21:19:27 voipd[422]: plci_connected(appl=4 plci=0x705 ncci=0x0 incoming)
Oct 10 21:19:27 voipd[422]: rtp_dgramrcv: packet from 192.168.2.1 ignored, should be from 84.163.163.120
Oct 10 21:19:27 voipd[422]: connected(appl=4 plci=0x705 ncci=0x10705 incoming) NCPIlen=0

 

[Matthy]

Da man die Fritzbox inzwischen ja offiziell und ohne Mod hinter einem Router betreiben kann, habe ich mal ein Ticket bei AVM dazu eröffnet. Mal gespannt was die dazu sagen.

 

[acmelabs]

Hi Matthy,

Wollte mal nachfragen, ob sich bei AVM mit dem Ticket etwas getan hat? Auch ich betreibe die FBF jetzt mit der neuen FW, wie Du auch. Das Problem besteht nach wie vor, und ich kann immer noch nicht sinnvoll meine QoS-Regeln testen, sprich - die IP-Telefonie kann man vergessen, wenn z.B. im Hintergrund der Esel saugt. Zum Testen sollte ich mich schon anrufen koenne, damit ich ueberpruefen kann, ob mein Traffic-Shaping ueberhaupt anschlaegt. Sehr aergerlich das Ganze!
Leider habe ich den Verdacht, dass das mit dem Ticket bei AVM nicht zum Erfolg fuehrt. Ich denke, wir haben ein Routing-Problem in unserer Firewall. Ich kenne zwar Fli4l nicht, aber ich glaube mich zu erinnern, dass auch diese Software, wie IP-Cop auch, auf iptables aufsetzt. Denn dass die FBF eine UDP Komminikation verweigert, weil die IP-Adresse nicht zum Kommunikationspartner passt, denke ich, ist doch normal. Ich hatte gehofft, dass jemand aus dem Forum hier genuegend Kenntnisse ueber iptables hat, und weiss wie man diese Loopback-Schleife im router aufloest.

Gruss

 

[Matthy]

Sorry, dass ich mich so spät melde. Das Ticket bei AVM hat wenig gebracht: Ich soll meine Portweiterleitungen abschalten und mein Router sei wohl nicht richtig konfiguriert. Wenn das Problem weiterbestehen sollte, soll ich mit dem in der Fritzbox eingebauten Paketsniffer die Kommunikation mitschneiden und an AVM senden. Das hab ich aber noch nicht gemacht, da mir der Aufwand zuviel war und ich in der Praxis wohl eh nie intern telefonieren werde.

 

[chres]

Wenn du neben dem signaling port (5060), auch noch eine ausreichende Anzahl an rtp ports weiterleitest (ausreichend heißt in diesem Fall mindestens 4, jeweils in/out für zwei Gespräche), dann funktioniert das auch hinter einem Router!

Mein Beispiel: FBF 5012 hinter fli4l 3.0.0:

forward port 5060 auf FBF
forward ports 7077-7081 auf FBF (der 7077 wird in der ar7.cfg als dnsport bezeichnet, weswegen dieser auch weitergeleitet wird + 7078-7081 (die 4 rtp ports))

Zweite Möglichkeit müsste mit Hilfe eines stun servers ohne Portweiterleitungen funktionieren! (so wie von AVM vorgeschlagen, hab ich aber nicht gestestet)

 

[Matthy]

Der Tipp mit den Portweiterleitungen bringt bei mir nix. Das hat bei meiner Fritzbox 7050 früher schon nicht geklappt. Ich hab's aber gerade eben nochmal probiert und es kommt noch immer folgendes im Log der Fritzbox:

Feb  5 19:26:28 voipd[662]: rtp_dgramrcv: packet from 192.168.2.1 ignored, should be from xxx.xxx.xxx.xxx

Ich rufe dabei mit der Fritzbox das 1&1 Softphone auf meinem PC an.

 

[chres]

Ich hab's jetzt extra nochmal nachgestellt!
Ich kann problemlos von meiner Fritz!Box (GMX, weitergeleitete ports: 5060, 7077-81) auf einem lokalen X-Lite (web.de, weitergeleitete ports 5061, 8000-8003) die sich beide hinter meinem Fli4 befinden, anrufen (und andersrum). codec: gsm, wegen meiner geringen Bandbreite. Alles ohne stun-Server!

 

[Matthy]

Nö, es zeigt bei mir keine Wirkung. Ich kann nichtmal vom einen ISDN-Telefon an der Box ein anderes ISDN-Telefon an der Box via VoIP anrufen. Es klingelt zwar, aber man kann keine Sprache übertragen. Sobald ich ein Portforwarding zur Fritzbox setze, kommt die oben genannten Fehlermeldung.

 

[Matthy]

Problem gelöst!!! Es lag am Masquerading des Fli4l. Ich habe nun selbst etwas dran gebastelt und das Routing von Masquerading auf SNAT umgestellt. Dadurch ist die Fritzbox endlich zufrieden und nimmt die Datenpakete an.

 

[chres]

Hmm, sehr seltsam, wie du siehst hab ich ebenfalls den fli in der 3.0.0 laufen und nie etwas in Richtung masquerading ändern müssen um es funktioieren zu lassen (oder in irgendeiner anderen 2.1.x Vorversion)!
Welche "Anpassungen" hast du denn vorgenommen, so dass es nun auch bei dir geht?

 

[Matthy]

Bisher war iptables des fli4l über die POSTROUTING-Einträge in der base.txt folgendermaßen konfiguriert:

POSTROUTING_LIST_1='IP_NET_1 MASQUERADE'
Ergibt dann: iptables -t nat -A POSTROUTING -s 192.168.2.1/24 -j MASQUERADE

Auch eine Änderung auf folgende Einstellung brachte keine Abhilfe:

POSTROUTING_LIST_1='if:anyppoe MASQUERADE'
Ergibt dann: iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Nun benutze ich in der base.txt gar keine POSTROUTING-Einträge mehr, sondern ich habe mir folgendes Einträge in ein ip-up-Skript geschrieben, was das Routing per SNAT nach dem Verbindungsstart aktiviert:

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -d fritzbox-7050-voip -j SNAT --to-source $local
iptables -t nat -A POSTROUTING -o $real_interface -j SNAT --to-source $local

$local ist in meinem Fall die IP-Adresse von ppp0 und $real_interface ist ppp0. Die Variablen stehen in den ip-up/down-skripten zur Verfügung.

SNAT mit dynamischer IP lässt sich über die base.txt leider nicht konfigurieren, da man dafür ja eigentlich MASQUERADE benutzt. Daher musste ich das über eigene ip-up/down Skripte lösen.

Seltsamerweise funktioniert MASQUERADE statt SNAT bei mir für die Fritzbox-Paketfilterregel nicht. Vielleicht kommt das MASQUERADE dadurch ins Schleudern, dass das interne Interface des Fli4l bei mir eine Bridge (br0) ist. Keine Ahnung.

Vorteil meiner Lösung ist außerdem, dass SNAT effizienter ist, da bei MASQUERADE bei jedem Paket die externe IP ermittelt wird.

 

[chres]

Vielleicht kommt das MASQUERADE dadurch ins Schleudern, dass das interne Interface des Fli4l bei mir eine Bridge (br0) ist. Keine Ahnung.

Das wäre möglich, zumindest unterscheidet dies deine Konfiguration von meiner!

 

[acmelabs]

Hallo Matthy,
auch bei mir geht der Traffic ueber br0 und nicht direkt ueber ethX. Intern telefonieren will ich hier auch nicht ;-), das Ganze sollte der Ausarbeitung von QoS-Regeln dienen. Mit Deiner Lösung des Problems laege also mir nichts mehr im Wege, die Arbeit anzugehen, wenn ..., ja wenn da nicht der mldonkey mit seinen 400 gleichzeitigen Connects waere. Bei dieser Menge von Connects bringt mir die beste QoS-Regel und der beste Layer7-Filter nichts, da 400 Connect faktisch einer auf sich selbt gerichteten DDOS-Attacke gleichkommt. Halbwegs brauchbare Gespraeche koennte ich hier noch bei ca. 50 Connect fuehren (down:6016kbs,up:576kbs). Leider saugt der Esel damit nicht mehr sondern nuggelt nur noch die Bits aus der Leitung ;-(. Wie dem auch sei, mein Webserver hier hat auch das Potential meine VoIP-Gespraeche zu killen, und hier kommt wieder QoS zum Zuge. Darueber hinaus wirst du mit Deiner Arbeit vielleicht dem Einen oder Anderen viel Zeit und Muehe ersparen. An dieser Stelle ein herzliches Dankeschoen fuer Deine Loesung.