Wie FBF hinter Bintec-Router betreiben ?

iqnetwork schrieb:

Hallo Anti-T. Bei mir liegt auch noch eine FBF rum.

Zum Vergrößern anklicken....

Welche genau?

iqnetwork schrieb:

Du schreibst, dass du sie hinter dem Bintec betreibst. Das gleiche mache ich auch, allerdings arbeitet sie bei mir bisher nur als Accesspoint. Erzähl mir mal den Trick hier erfolgreich VoIP einzutragen.

Zum Vergrößern anklicken....

Du brauchst eine FBF mit der .85er Firmware (seit 30.09.2005 erhältlich). In der musst du dann einstellen:

1.) Internetzugang über LAN A, Wählen Sie diesen Zugang, wenn Sie FRITZ!Box an einen bereits vorhandes Netzwerk (LAN) oder einen DSL-Router anschließen möchten.

2.) Vorhandene Internetverbindung im Netzwerk mitbenutzen (IP-Client)

3.) IP-Adresse: halt eine
Subnetzmaske: wie bekannt
Standard-Gateway: der Bintec-Router
Primärer DNS Server: der Bintec-Router

QoS muss jetzt natürlich im Bintec realisiert werden, darüber habe ich mich aber noch nicht hergemacht. So lang die bei 1&1/AVM definitiv nicht sagen können, welche Ports wofür gebraucht werden ist das auch weitgehend sinnfrei.

Im Bintec sind ein paar Portforwardings zur FBF notwendig. Bei mir reichen 5060, 7078 und 7082 UDP. Über einen DEBUG ALL & findet man das aber auch selber leicht und schnell heraus.

Er blockt nicht den 5060. Dem DEBUG nach musst du die Ports 32798 und 33117 (die blockt er im Momant) zur FBF forwarden, denn dort will der 217.10.79.9 (sipgate.de?) die FBF kontaktieren.

Mein Snom 190 läuft übrigens mit sipgate hinter dem Bintec, ein Versuch und es klappt sofort. Es sind keinerlei Portforwardings notwendig. Einfach der Anleitung auf der sipgate-hilfe-Seite zum Snom 190 folgen.

Moin zusammen!

Die Ports 32798 und 33117 im obigen Log-Auszug werden sich immer mal wieder ändern. Dies sind nämlich die Ports, die durch das NAT des BinTec als externe Quellports für 5060 verwendet wurden. Dies ist ein Fehler oder zumindest eine Eigenart mancher Provider, daß sie ihre Antworten nicht auf die per Datenfeld im REGISTER kundgetanen Ports schicken, sondern "Return To Sender" auf den Port, der als Quellport im REGISTER drinsteht.

Also so (jeweils <ankommender Port>:<Gerät>:<abgehender Port>)
VoIP-Client:5060 --> 5060:BinTec:32798 --> 5060rovider

Die Antwort sollte so aussehen (laut Inhalt vom REGISTER)
Provider:5060 --> 5060:BinTec:5060 --> 5060:VoIP-Client

Sieht aber so aus:
Provider:5060 --> 32798:BinTec = Blockiert, da nicht zur Weiterleitung vorgesehen.

Anfangs klappt die Konstruktion, da der Port für eine gewisse Zeit offengehalten wird, durch die ausgehenden Telegramme. Der dafür zustaändige NAT-Eintrag wird aber nach einer gewissen Zeit gelöscht (meist 90 Sekunden). Danach funktionieren die Antworten nicht mehr und erzeugen den obigen Effekt.

Bei mir (auch BinTec) habe ich das gelöst, indem ich den abgehenden Port auch festgenagelt habe (per Port Forwarding von intern nach extern). Dadurch passt es immer, egal welcher Provider das gerade wie handhabt.

Moin, Jürgen!

Genauso habe ich das gemacht. Bei mir existieren mehrere Clients, entsprechend habe ich mehrere Control-Ports (bei mir 5060, 5070 und 5080) mit verschiedenen Quelladressen, aber ansonsten keine weiteren Ports. Die RTP-Ports scheinen ohne diese Tricks zu laufen.

Moin!

Hmm, irgendeine Adresse von Telefonica möchte mit Dir reden, wie es scheint

Dieses Problem tritt bei mir nicht auf. Sollte es auch nicht, da die RTP-Ports ja nun wirklich bei jedem Verbindungsaufbau zwischen beiden Partnern ausgehandelt werden.

Also kann es sich eigentlich nur um einen Control-Port handeln, der da mal wieder irregeleitet ist.

Für die weitere Lösung wäre es interessant, zu wissen, wie sich das Gerät denn nun insgesamt verhält. Anmelden klappt aber telefonieren nicht? Oder vielleicht nur in eine Richtung? Gib doch noch mal ein bißchen mehr Input...

Übrigens, schau doch mal in diesen Thread. Da sind auch ähnliche Geschichten mit Bintec und FBF.

Der Tip, den ich dort mit "debug all" gegeben habe, würde hier auch weiterhelfen, rauszubekommen, wie der Port 33174 (im Beispiel) ins Spiel kommt.

Dies ist ein Fehler oder zumindest eine Eigenart mancher Provider, daß sie ihre Antworten nicht auf die per Datenfeld im REGISTER kundgetanen Ports schicken, sondern "Return To Sender" auf den Port, der als Quellport im REGISTER drinsteht.

Zum Vergrößern anklicken....

Mmmmhh...zunächst einmal werden im Internet IP Pakete transportiert, und ob da nun SIP drin ist oder nicht, interessiert für die Kommunikation zwischen Internet Gateways ziemlich wenig.Eben wegen NAT ist es dringend erforderlich, das die Pakete auf den gleichen Port zurückgeschickt werden, von dem sie kamen, alles andere findet im Application Layer statt, und den wertet der Router ( mal von - von einem bestimmten Moderator hier immer gern erwähnten - "NAT-aware"-Routern abgesehen) nicht aus.

Das Verändern der Source Ports durch den Router ist eher ein unübliches Verhalten und dürfte eher eine Fehlfunktion oder "Macke" des BinTec Routers sein.Ich habe keinen einzigen Router, der sowas tut.

(per Port Forwarding von intern nach extern). Dadurch passt es immer, egal welcher Provider das gerade wie handhabt.

Zum Vergrößern anklicken....

Portforwardings gehen grundsätzlich immer nur von außen (Internet) nach innen ( LAN).Alles andere sind Filterregeln für einen Packetfilter ( auch gern Firewall genannt) , welcher hier wahrscheinlich auch das Problem ist.Eine NAT Session verfällt zwar, aber der SIP Client registriert sich regelmäßig beim SIP Server, weshalb das nicht zum Tragen kommen sollte.Scheint ein
BinTec-spezielles Problem zu sein.



Grüße

TWELVE

TWELVE schrieb:

Mmmmhh...zunächst einmal werden im Internet IP Pakete transportiert, und ob da nun SIP drin ist oder nicht, interessiert für die Kommunikation zwischen Internet Gateways ziemlich wenig.Eben wegen NAT ist es dringend erforderlich, das die Pakete auf den gleichen Port zurückgeschickt werden, von dem sie kamen, alles andere findet im Application Layer statt, und den wertet der Router ( mal von - von einem bestimmten Moderator hier immer gern erwähnten - "NAT-aware"-Routern abgesehen) nicht aus.

Zum Vergrößern anklicken....

Der Router soll den Application Layer ja auch nicht auswerten, genausowenig wie die diversen Zwischenstationen im Internet.

Ich habe vom Provider gesprochen. Dieser erzeugt ja die Antwortpakete. Und eigentlich wird dem Provider im REGISTER mitgeteilt, welche <IP-Adresse>:<Port>-Kombination für die Antwort benutzt werden soll. Und auf diese sollte der Provider dann seine Quittungen bzw INVITEs oder ähnlich auch schicken. Es handelt sich ja hier nicht um TCP-Quittungen, sondern um UDP-Pakete, die keiner automatisch beantwortet. Das muß schon irgendein Application Layer tun...

TWELVE schrieb:

Das Verändern der Source Ports durch den Router ist eher ein unübliches Verhalten und dürfte eher eine Fehlfunktion oder "Macke" des BinTec Routers sein.Ich habe keinen einzigen Router, der sowas tut.

Zum Vergrößern anklicken....

Was Du mit dem Verändern der Source Ports meinst, ist mir auch nicht klar. Die einzigen Veränderungen, die hier stattfinden, geschehen durch NAT selbst, sowie durch die Port-Rewrites, die hier ja gewollt sind. Und da ist erstmal nichts ungewöhnliches dran. Die Büchse macht genau, was sie soll. Und Du hast natürlich Recht, beides, also sowohl von innen nach außen, als auch umgekehrt sind eigentlich Filter-Regeln mit Rewrite, aber der Sprachgebrauch ist halt anders geworden (jedem Tierchen sein Pläsierchen)

TWELVE schrieb:

Eine NAT Session verfällt zwar, aber der SIP Client registriert sich regelmäßig beim SIP Server, weshalb das nicht zum Tragen kommen sollte.

Zum Vergrößern anklicken....

Das Re-Registering durch die FBF wird aber kaum so oft passieren, daß die NAT-Session erhalten bleibt. Bei mir wird zum Beispiel nur alle 3600 Sekunden eine erneute Registrierung gemacht. Man müsste also entweder die Lebensdauer der NAT-Sessions erhöhen oder den Registrierungszyklus auf 90 Sekunden setzen. Ersteres ist ein Sicherheitsmangel und könnte u.U. irgendwann zu einem Problem mit der Anzahl noch offener Sessions führen und das zweite könnte beim Provider evtl nicht so gut ankommen.
[hr:952d321afa]
@iqnetwork
Das ist mir schleierhaft, wodran das jetzt wieder liegt. Wie gesagt, bei mir tritt dieses Problem nicht auf. Ich habe auch nur die Portweiterleitungen von extern nach intern für die eingestellten RTP-Ports. Ich glaube, ich habe 6 Ports pro Client dafür vorgesehen.

Das hier finde ich aber etwas merkwürdig (hat aber wahrscheinlich nichts mit dem Problem zu tun)

iqnetwork schrieb:

any/udp ea 0.0.0.0/32, ia 192.168.0.2/32, ep 5061, ip 5060 //elmeg snom

Zum Vergrößern anklicken....

Wie hast Du denn hier die Antworten durchgereicht? Kommen die auf 5061 an? Denn das Snom hat ja wohl selbst die 5060 als Port konfiguriert. Kann man bei diesem abgehend und ankommend unterschiedliche Prots einstellen?

Aber wie schon gesagt: Versuch doch mal herauszubekommen, woher diese merkwürdigen Ports stammen. Man muß doch sehen können, wann die das erste Mal ins Spiel kommen. Mittels "debug all" kann man den logischen und zeitlichen Zusammenhang besser herstellen, da dort ja auch die Sachen zu sehen sind, die sonst nicht mitgeloggt werden (wie z.B. die einzelnen NAT-Sessions).

Darauf aufbauend kann man dann weiter forschen. Wenn das tatsächlich Antworten auf RTP-Ports sind, ist da noch mehr faul in der Firmware :-(

Was Du mit dem Verändern der Source Ports meinst, ist mir auch nicht klar.

Zum Vergrößern anklicken....

Du hast doch selber oben geschrieben, das die Source Ports der Pakete durch den Router verändert werden:

VoIP-Client:5060 --> 5060:BinTec:32798 --> 5060rovider

Zum Vergrößern anklicken....

Und eigentlich wird dem Provider im REGISTER mitgeteilt, welche <IP-Adresse>:<Port>-Kombination für die Antwort benutzt werden soll.

Zum Vergrößern anklicken....

Nöö...steht da nicht drin.Da steht nur drin, wo der User erreichbar ist, wenn ihn jemand anrufen möchste.Das schreibt der Registrar Server dann in seine Datenbank

sip.Via = Via: SIP/2.0/UDP 83.59.129.30;branch=z9hG4bK64EDD96F14223DB0511751BF523F

Ein Port steht hier nur, wenn er von 5060 abweicht und explizit angegeben wurde,

Wo das Paket herkam, weiß der Server ja über das UDP Protokoll, und genau dahin antwortet er auch wieder.

Obwohl das Verhalten des Bintec Routers, den Sourceport eines ausgehenden Pakets zu verändern, nicht ganz normal ist, dürfte das jedenfalls für die Registrierung keine Probleme aufwerfen, solange er die Port Translation speichert und wieder rückwärts durchführt, wenn die Antwort zurückkommt.Die Probleme könnten später auftreten, wenn jemand den user anrufen will und der Server die hinterlegte IPort
anspricht ( die bei der Registrierung übergeben wurde), aber für diese keine Portweiterleitung im Router existiert.

Das eigentlich wichtige sind aber die RTP Ports, die für die eigentliche Sprachübertragung genutzt werden.Da sie dynamisch ausgewählt werden, kommt man kaum um einen Mechanismus wie UPnP oder STUN herum, um die Ports im Router weiterzuleiten.

Grüße

TWELVE

TWELVE schrieb:

RB schrieb:

Was Du mit dem Verändern der Source Ports meinst, ist mir auch nicht klar.

Zum Vergrößern anklicken....

Du hast doch selber oben geschrieben, das die Source Ports der Pakete durch den Router verändert werden:

RB schrieb:

VoIP-Client:5060 --> 5060:BinTec:32798 --> 5060rovider

Zum Vergrößern anklicken....

Zum Vergrößern anklicken....

So funktionieren die meisten NAT-Varianten nun einmal. Was hier meist mit NAT bezeichnet wird, ist ja eigentlich NAPT (PAT) oder Masquerading (siehe diesen Wikipedia-Artikel)

TWELVE schrieb:

RB schrieb:

Und eigentlich wird dem Provider im REGISTER mitgeteilt, welche <IP-Adresse>:<Port>-Kombination für die Antwort benutzt werden soll.

Zum Vergrößern anklicken....

Nöö...steht da nicht drin.Da steht nur drin, wo der User erreichbar ist, wenn ihn jemand anrufen möchste.Das schreibt der Registrar Server dann in seine Datenbank

sip.Via = Via: SIP/2.0/UDP 83.59.129.30;branch=z9hG4bK64EDD96F14223DB0511751BF523F

Zum Vergrößern anklicken....

Ein Port steht hier nur, wenn er von 5060 abweicht und explizit angegeben wurde

Zum Vergrößern anklicken....

Dann sind wir uns ja einig - Wenn keine Angabe erfolgt ist, soll also der Port 5060 benutzt werden. Ist schon klar, daß dieser Standardport nicht angegeben wird. Ist ja Default. Da bei mir auch andere Ports benutzt werden, sind diese dann im REGISTER enthalten. Die Provider halten sich aber trotzdem nicht unbedingt dran...

TWELVE schrieb:

Das eigentlich wichtige sind aber die RTP Ports, die für die eigentliche Sprachübertragung genutzt werden.Da sie dynamisch ausgewählt werden, kommt man kaum um einen Mechanismus wie UPnP oder STUN herum, um die Ports im Router weiterzuleiten.

Zum Vergrößern anklicken....

Diese Ports wiederum sind zwar prinzipiell dynamisch, werden aber im INVITE bzw in der Quittung dazu ausgehandelt/vorgegeben und sind normalerweise im Client auf einen festen Bereich einschränkbar, so daß man ohne weiteres Portweiterleitungen einrichten kann. Bei mir funktioniert es so auch problemlos mit drei verschiedenen Clients, denen ich jeweils einen Bereich von 6 Ports zugewiesen habe.

Weder STUN noch UPnP habe ich im Einsatz. Und bei UPnP hätte ich auch große Bauchschmerzen, das zuzulassen. Ich halte nichts davon, daß irgendwelche Applikationen dem Router sagen können, welche Ports er öffnen/weiterleiten soll. Das mache ich lieber selber...

Das merkwürdige an der hiesigen Geschichte ist ja, daß das bei mir sowohl mit meinem Bintec (X1200II) als auch seinem Vorgänger (X1200) alles problemlos funktioniert. Sowohl mit SIPPS oder X-Pro auf einem meiner PCs, als auch mit meinem Cisco-Telefon oder einem AllNet 7902, der hier für Experimente parallel auch noch im Einsatz ist.

Allerdings habe ich keine FBF, um den Gegentest zu machen.

Hi,

ich habe nicht den Eindruck, dass es jemanden gibt, bei dem eine FBF problemlos hinter einem X1200 läuft. Oder habe ich den nur noch nicht gefunden?

Bei mir registriert sich die FBF nun endlich bei allen SIP-Providern, nachdem ich die Ports 5060-5063 und 7077-7081 von intern nach extern geforwarded habe.

Leider funktionieren einkommende Gespräche trotzdem noch nicht, da einkommende Sessions eine interne IP-Adresse anzusprechen versuchen, die es im Netz überhaupt nicht gibt.

@Ralf
Vielleicht wäre es sinnvoll, meinen Beitrag unter http://www.ip-phone-forum.de/forum/viewtopic.php?t=27512 hierher zu verschieben, da das Problem ja wohl eher dem Router bzw. der Router-Einstellung zuzuordnen ist als der FBF. Zumindestens habe ich bei der FBF keine Möglichkeiten gefunden, irgend etwas einzustellen, um das Problem zu fixen.

Viele Grüße
Charley

Hi,

ich habe nicht den Eindruck, dass es jemanden gibt, bei dem eine FBF problemlos hinter einem X1200 läuft. Oder habe ich den nur noch nicht gefunden?

Bei mir registriert sich die FBF nun endlich bei allen SIP-Providern, nachdem ich die Ports 5060-5063 und 7077-7081 von intern nach extern geforwarded habe.

Leider funktionieren einkommende Gespräche trotzdem noch nicht, da einkommende Sessions eine interne IP-Adresse anzusprechen versuchen, die es im Netz überhaupt nicht gibt.

@Ralf
Vielleicht wäre es sinnvoll, meinen Beitrag unter http://www.ip-phone-forum.de/forum/viewtopic.php?t=27512 hierher zu verschieben, da das Problem ja wohl eher dem Router bzw. der Router-Einstellung zuzuordnen ist als der FBF. Zumindestens habe ich bei der FBF keine Möglichkeiten gefunden, irgend etwas einzustellen, um das Problem zu fixen.

Viele Grüße
Charley

Moin!

@charley
Ich habe da so meine Zweifel, wo das Problem liegt. Wie schon gesagt, laufen meine Clients ja recht problemlos. Ich vermute eigentlich, daß diese Effekte durch irgendwelche Spezialitäten der FBF-Firmware zustande kommen. Diese sind wahrscheinlich von AVM absichtlich eingebaut worden, um bei einfacher gestrickten Routern enige Schwierigkeiten zu umschiffen. Nur hier geht das wohl in die Hose. Mangels Hardware kann ich das aber leider nicht verifizieren.

Hast Du die Möglichkeit den von mir in "Deinem" Thread angesprochenen Mitschnitt der Vorgänge zu machen? Eigentlich sollten die Ports 7077-7081 (ich nehme mal an, daß das die RTP-Ports sind) nicht nötig sein. Aber da fehlt eben so ein ausführlicher Debug / Mitschnitt, um da weiterzufahnden.

Ein Bintec-Router ist natürlich schon eine andere Liga, als die üblichen Home-Geräte. Aber eigentlich entstehen die meisten Probleme nur, weil es sich hier halt um eine symmetrische NAT handelt, die bei den meisten Clients nicht vorgesehen ist. Ich gehe mal davon aus, daß z.B. die teureren Router von Vigor und Intertex sowie von Cisco ähnliche Effekte mitbringen würden. Wobei zumindest die Intertex-Geräte ja selbst einen SIP-Proxy an Bord haben, also mit Eigenintelligenz diese Probleme umschiffen können.

Zum Verschieben Deines Threads: In dieser Abteilung habe ich keine Moderatoren-Rechte. Das müsste ggf ein Kollege übernehmen...

Portweiterleitung aktiv halten

Hi Ralf,

ich habe jetzt auch einkommende Gespräche wenigstens zum Teil zum Laufen gebracht.

In den erweiterten Einstellungen zur Internet-Telefonie hat die FBF folgende Option:

Portweiterleitung des Internet-Routers für Internettelefonie aktiv halten

Diese Option kann dann erforderlich werden, wenn der Internet-Router einkommende Internet-Telefonate nicht mehr an FRITZ!Box weiterleitet. FRITZ!Box hält die Portweiterleitungen des Internet-Routers für Internettelefonie aktiv.

Portweiterleitung aktiv halten alle 5 Min. 2 Min. 1 Min.

Zum Vergrößern anklicken....

Ich habe diesen Wert jetzt auf 1 Minute gestellt. Dies hat zur Folge, dass alle Minuten eine Session nach außen aufgebaut wird und eingehende Anrufe sofort diese Session benutzen. Nach wie vor geht die incoming Session ins Leere, da die interne IP-Adresse nicht existiert. Im Versuchsbetrieb hat es jetzt bei 8 von 10 eingehenden Gesprächen geklappt.

Es ist allerdings nicht befriedigend, dass es nicht bei allen eingehenden Gesprächen klappt. Außerdem habe ich das Gefühl, dass die von der FBF benutzte Möglichkeit ein gewisses Sicherheitsrisiko darstellt, da auf diese Weise ständig Sessions offen gehalten werden.

Freundliche Grüße
Charley

Heureka! Es läuft ...

Hi,

jetzt habe ich es mit eurer (vor allem Ralfs) tatkräftiger Hilfe geschafft: alle SIP-Accounts funktionieren ein- und auswärts.

Zunächst die Lösung des Problems der "seltsamen" internen Adresse:

Ich hatte bei den NAT-Einstellungen from outside als externen und internen Post 5060 angegeben, als interne Adresse 10.50.1.83, die Adresse meiner FBF. Als Subnetmask allerdings habe ich versehentlich 255.255.255.0 eingetragen. Das ist zwar meines Erachtens kein Grund Grund für den X1200, die Internadresse so zu verfälschen; nachdem ich die Mask aber auf 255.255.255.255 geändert hatte, wurden incoming sessions auf Port 5060 korrekt zur FBF weitergeleitet.

Insgesamt habe ich jetzt folgendes gemacht:

Ports 5060-5063 sowie 7077-7080 habe ich im NAT von inside nach extern geforwarded.

Von außen habe ich Ports 5060, 5061, 7077, 7078 und 8000 zur FBF geforwarded.

Alle STUN-Einträge habe ich aus der Telefonie-Einstellung der FBF entfernt.

Die Einstellung "Portweiterleitung des Internet-Routers für Internettelefonie aktiv halten" in der FBF habe ich wieder deaktiviert bzw. auf 5 Minuten zurückgestellt.

Wahrscheinlich kann ich noch ein paar Ports aus der NAT-Konfiguration rausnehmen; das teste ich noch in den nächsten Tagen.

Es ist übrigens auch möglich, mit der FBF auf dem einen SIP-Account rauszutelefonieren und das Gespräch auf dem anderen Account einkommend entgegenzunehmen.

Viele Grüße
mit herzlichem Dank an Ralf
Charley