Softclient in abweichendem Subnetz klingelt nicht

[Mathias.D]

Hallo zusammen,


ich habe ein Problem beim Einsatz von Softphones im Zusammenspiel mit einer FB7490, die in einem anderen Subnetz eines nachgeschalteten Routers laufen.


Folgende Konstellation:


Habe VDSL2 mit VoIP von T und als Modem wird eine FritzBox 7490 eingesetzt. Die 7490 dient auch als PBX für einige DECT-Telefone sowie kabelgebundene VoIP-Telefone (direkt am LAN-Port der FB angeschlossen).

T-VDSL -> FritzBox 7490 192.168.0.1



Für mein Netzwerk hängt hinter der 7490 ein zusätzlicher Ubiquity ERL Router mit fester IP 192.168.0.2:


T-VDSL -> FritzBox 7490 192.168.0.1 -> ERL 192.168.0.2 (Gateway 192.168.0.1)



Der Ubiquity ERL stellt nun ein maintainance LAN 192.168.1.1 sowie mehrere VLANs zur Verfügung:


T-VDSL -> FritzBox 7490 192.168.0.1 -> ERL 192.168.0.2 -> LAN 192.168.1.1 ohne DHCP
T-VDSL -> FritzBox 7490 192.168.0.1 -> ERL 192.168.0.2 -> VLAN2 192.168.2.1 mit DHCP
T-VDSL -> FritzBox 7490 192.168.0.1 -> ERL 192.168.0.2 -> VLAN3 192.168.3.1 mit DHCP
usw....


Mein Rechner hängt nun im VLAN2 und hat die IP 192.168.2.122.
Auf der FB habe ich nun ein neues Telefoniegerät mit Anschlussart "LAN/WAN" angelegt und die Zugangsdaten (Benutzername z.B. "620" sowie entsprechendes PW)
in das Softphone auf dem Rechner eingetragen. Das Softphone verbindest sich auch ordentlich mit der FB und ich kann problemlos nach außen telefonieren.


Mein Problem ist nun: eingehende Anrufe werden nicht an mein Softphone im Netz 192.168.2.1/24 weitergeleitet - das Softphone klingelt nicht.
Wie bringe ich also nun der FB bei, dass in einem anderen Subnetz auch noch ein Softphone auf Anrufe wartet? Die DECT-Telefone sowie die an der FB angeschlossenen
kabelgebundenen VoIP-Telefone sollten natürlich auch weiterhin funktionieren, wobei ich die kabelgebundenen Telefone auch in das 192.168.2.1/24 hängen kann.


Ich habe bereits eine statische Route in der FB zu meinem Rechner 192.168.2.122 eingerichtet doch das scheint nicht auszureichen. Bei Portforwarding bin ich mir nicht sicher,
ob dann die PBX der FB noch funktioniert - davon abgesehen lässt die FB das Forwarding von 5060 auch nicht zu....


Bin etwas ratlos und wäre über Unterstützung sehr dankbar.


Viele Grüße
Mathias

 

[Theo Tintensich]

Du musst auf der F!B für jedes Netz, dass der Ubiquity-Router bereitstellt, eine Route einrichten, so dass die Geräte in diesem Netz auf erreicht werden können.
(Willst du das nicht, musst du eben in diesen Netze eine passende Firewall-Regel eintragen).

Also keine statische Router zu 192.168.2.122, sondern zu 192.168.2.0/24 (und 192.168.1.0/24 sowie 192.168.3.0/24) und der Router IP 192.168.0.2. Mit den passenden Subnetzmasken.


(Du könntest diese statische Route auch bei allen Systemen einzeln setzen, es reicht aber, wenn du sie in der F!B einträgst. Die leitet den Verkehr dann dorthin weiter. Nachteil: jeglicher Verkehr in die drei Netze geht erst zur F!B)

 

[Mathias.D]

Danke Theo,

ich habe nun entsprechend statische Routen in der FB angelegt:

IPv4: 192.168.1.0
Subnetzmaske: 255.255.255.0
Gateway: 192.168.0.2
IPv4-Route aktiv: 'X'

IPv4: 192.168.2.0
Subnetzmaske: 255.255.255.0
Gateway: 192.168.0.2
IPv4-Route aktiv: 'X'

Dann habe ich das Softphone beendet und neu gestartet doch leider klingelt es immer noch nicht...

Danke
Mathias

 

[eisbaerin]

Probiere mal bei dem Telefoniegerät 620: Aus dem Internet anmelden zulassen
Aber nur mit einem extrem sicheren Paßwort!

IMO hat AVM da mal was geändert und jetzt wird jedes Netz, was nicht direkt am LAN ist, als Internet angesehen.

 

[Mathias.D]

leider hat die Option "Aus dem Internet anmelden zulassen" auch nicht funktioniert. Der Softclient ist nicht erreichbar.

Ich habe auch nochmals den Test gemacht und den Rechner direkt an die FB gehängt, dann klingelt der Softclient auch.

 

[PeterPawn]

Ich würde ja eher annehmen, daß der (unsolicited) Traffic seitens der FRITZ!Box zur Benachrichtigung des SIP-Clients über den Anruf am nachgelagerten Ubiquity-Router scheitert.

Um das aber sicher zu diagnostizieren, muß man schon in der FRITZ!Box (entweder direkt oder über die Supportdaten und zwar unmittelbar nach dem Anruf, der Ringpuffer ist nicht so riesig) nachsehen, ob die FRITZ!Box entsprechende INVITE-Requests an den Softclient abgesetzt hat und wohin (sprich an welchen Port) die gehen sollten. Sind die sichtbar, blockt da wohl der zusätzliche Router ab und dann gibt es mehrere mögliche Lösungen.

Aber ohne genaue Diagnose der Ursache macht es wenig Sinn, darüber bereits zu diskutieren. Nur aus dem empirischen Ergebnis, daß das Softphone nicht klingelt, kann man die Ursache nicht ableiten, dafür gibt es da einfach zu viele.

 

[Mathias.D]

@PeterPan... habe mal einen Mitschnitt gestartet und anbei die INVITES: (btw.. "625" ist nun der Account der FB um den es geht).
Ich sehe dort auch ein paar 401 Meldungen... kann es damit zusammenhängen?

 

[PeterPawn]

Die 401-Fehler sind vollkommen normal - für jede neue Anforderung, bei der eine Autorisierung erforderlich ist, ist so ein Fehler praktisch unvermeidlich, weil erst in dieser Fehlermeldung der passende Salt-Wert für die einmalige Verschlüsselung (auch Hashen ist ja Kryptographie) des Kennworts (als "nonce") enthalten ist.

Aber auf die INVITEs kommen eben keine Antworten ... und dieser Screenshot ist etwas zu wenig, um sichere Angaben machen zu können, aber da wird offenbar auf zwei verschiedenen Ports (und mit zwei verschiedenen lokalen "Nummern") versucht, das Softphone zu erreichen.

Aber vermutlich kommt der Ubiquity-Router ohnehin nicht damit klar (der macht ja offensichtlich (und auch logischerweise) NAT), daß die FRITZ!Box direkt an die 192.168.2.121 senden will anstatt an die 192.168.0.2 mit dem passenden Port, von dem das REGISTER kam. Entweder das Softphone verwendet einen festen Port, der dann im Ubiquiti-Router per Forwarding durchgeleitet werden kann oder da muß ein SIP-ALG dazwischen oder das Softphone muß selbst zusehen, wie es NAT-Traversal für SIP so hinbekommt, daß die FRITZ!Box den SIP-Client nicht als 192.168.2.121 sieht, sondern als den passenden Port auf der 192.168.0.2 ... das geht sicherlich alles, aber da fehlt jede Menge Fleisch (Infos) am Knochen (Problem).

Um die Möglichkeiten besser einschätzen zu können, braucht es schon eine DPI für die REGISTER- und INVITE-Pakete und je nach anzugehender Lösung sind sogar die jetzt in der FRITZ!Box gesetzten Routen unnütz bis falsch. Wenn der Ubiquity-Router ganz offensichtlich NAT macht, schlägt jedes von der FRITZ!Box an eine Adresse aus 192.168.2.0/24 gesendete Paket an der Firewall auf und da ist Sense. Wenn ein Client im Netz hinter dem Ubiquiti-Router erreicht werden soll, braucht es die externe Adresse dieses Routers (also die 192.168.0.2) in Kombination mit dem passenden Port. Das kann entweder einer sein, der durch eine ausgehende Verbindung "geöffnet" wurde oder ein festes Forwarding für einen Port an einen bestimmten Client im LAN des Ubiquiti-Routers.

Alles andere ist Voodoo ... jedenfalls solange da ein Router mit NAT arbeitet, bei dem man keine "Ausnahmen" konfigurieren kann. Dann bräuchte es wieder die lokalen Routen und entsprechende Regeln im kaskadierten Router, daß bestimmte Adressen 1:1 durchgelassen werden sollen - also weder ins Connection-Tracking noch ins Umschreiben von Adressen und/oder Ports einbezogen werden sollen ... das ist aber in einem Consumer-Gerät eher selten anzutreffen.

PS: Ich kaufe ein "w" ... mein Nickname ist zwar auch eine gewollte Assoziation - aber der Name stammt noch aus meinen Blitzschach-Zeiten und so wenig wie ich die Verballhornung meines "realname" mit "ling" am Ende schätze, so sehr bestehe ich auf dem zusätzlichen Buchstaben in meinem Pseudonym. Auch wenn es sicherlich nicht absichtlich geschah, wäre das ein Grund für den Ruf nach Satisfaktion - zeitgemäß als Deathmatch in einem FPS.

 

[Mathias.D]

das "W" sollst du bekommen verziert mit einer Bitte um Nachsicht...... also PeterPawn, Danke für die Aufhellung so weit....

Würde dann nicht eine Port-Weiterleitung im Ubiquiti von 53632 nach 192.168.2.121:5060 reichen?

 

[PeterPawn]

das "W" sollst du bekommen

Danke, damit ist Revokation zu vermelden und der Ruf nach Satisfaktion hiermit annulliert. :mrgreen:

Würde dann nicht eine Port-Weiterleitung im Ubiquiti von 53632 nach 192.168.2.121:5060 reichen?

Jein ... das funktioniert natürlich nur, wenn das Softphone von einem festen Port aus sendet und der auch immer 1:1 vom Ubiquiti-Router auf die externe Adresse umgesetzt werden kann ... es also kein Port ist, der dynamisch beim NAT verwendet wird. Ich kenne die Einstellmöglichkeiten an dem kaskadierten Router nicht genau genug.

Die FRITZ!Box sieht halt die Adresse aus dem REGISTER-Request (und zwar aus dem SIP-Inhalt und nicht aus dem TCP-Paket, mit dem die Registrierung ankam ... jedenfalls gehe ich bei dem im ersten Screenshot sichtbaren "transport=tcp" davon aus, daß die SIP-Kommunikation da auf TCP anstelle von UDP basiert) als Client an und sendet ihren INVITE-Request an diese Adresse aus dem SIP-Payload. Vielleicht schaust Du mal in die SIP-Clients der Box (showvoipdstat, falls Shell-Zugang möglich ist, ansonsten steht das auch in den Support-Daten, ebenso wie die letzten SIP-Pakete (ein- und ausgehend), wo man dann genauer sieht, was da vom Softphone via Ubiquiti-Router gesendet wird und was die Box daraus macht.

 

[Mathias.D]

Danke, damit ist Revokation zu vermelden und der Ruf nach Satisfaktion hiermit annulliert. :mrgreen:

Danke - dann bin ich beruhigt

Jein ... das funktioniert natürlich nur, wenn das Softphone von einem festen Port aus sendet und der auch immer 1:1 vom Ubiquiti-Router auf die externe Adresse umgesetzt werden kann ... es also kein Port ist, der dynamisch beim NAT verwendet wird. Ich kenne die Einstellmöglichkeiten an dem kaskadierten Router nicht genau genug.

...und da scheint ein Problem zu sein, da der Ubiquiti dynamisches NAT verwendet... ich muss mich da mal schlauer machen/einlesen...

 

[madtech]

Hi Mathias,

ich habe ein ganz ähnliches Problem wie du, bloß mit einer Fritzbox und einem DD-WRT Router.
Bei mir habe ich jetzt den Workaround über den Telekom Registrar genommen. Also anstatt mich an der Fritzbox anzumelden melde ich mich direkt beim Telekom Server an.
Die nötigen Zugangsdaten findest du hier: https://www.telekom.de/hilfe/festne...telefonie-mit-anderen-clients?samChecked=true
Vielleicht auf für dich erst mal praktikabel bis eine zufriedenstellende Lösung gefunden ist.

lg Steffen

 

[Theo Tintensich]

@Mathias.D

Kann man dem Ubiquiti das NAT nicht abgewöhnen?

Nach https://dl.ubnt.com/guides/edgemax/EdgeOS_UG.pdf (Seite 33ff) sollte das möglich sein.