Portfreischaltung Fritzbox im WAN hinter einer zweiten Fritzbox

123sat

Mitglied
Mitglied seit
24 Mrz 2007
Beiträge
224
Punkte für Reaktionen
1
Punkte
18
Hallo,

ich habe einen DSL-Zugang über eine Fritzbox 7530 (LAN "eins" - 192.168.178.x). Im LAN "eins" der 7530 befindet sich die Fritzbox 7590. Diese stellt einen eigenen LAN-Bereich (LAN "zwei" 192.168.188.x) bereit und stellt den Internetzugang über die 7530 am DSL-Anschluss her. Das funktioniert soweit alles :)

Nun möchte ich im LAN "zwei" Ports freigeben. Also --> "Internet" --> "Freigaben" --> "Portfreigaben". Soweit alles definiert.

Nun die Frage:
Alle im LAN "zwei" speziell definierten Ports müssen natürlich auch durch den Router am DSL-Anschluss durch. Muss ich in diesem Router all diese Ports erneut konfigurieren und auf die zweite Fritzbox weiterleiten?

Oder reicht es aus folgende Eintragung vorzunehmen, siehe Bild:

123.JPG

Bild geschrumpft by stoney
 
Zuletzt bearbeitet von einem Moderator:
Wie wäre es, wenn du es selber ausprobierst?
Wenn dann was nicht geht, kannst du ja fragen.
 
Ich kriege mein VoIP nicht zum Laufen und suche Fehlerquellen. Danke für deinen Tipp :(.
 
Welches VoIP? Von wo nach wo?
Ein paar klitzekleine Infos mehr wären IMO nicht verkehrt. ;)
 
Lass uns am besten versuchen die Ausgangsfrage zu klären, das Thema ist für alles zu komplex, weil das LAN sozusagen verschachtelt ist. Wenn das mit den Ports geklärt ist, kann ich erstmal selber an der Telefonconfig "1und1 im Grandstream 2613" arbeiten.
 
Im Prinzip mußt du, wenn du doppeltes NAT machst, natürlich auch doppelt freigeben.

Ob das Gerät die Portfreigaben selber machen kann hängt von dem Gerät ab, aber das willst du ja nicht verraten.
 
und suche Fehlerquellen
Ne ... du betriebst nur "Fehler-Raten". Eine echte Suche würde eine Systematik voraussetzen und dazu gehört es nun einmal, daß man sich alle möglichen Infos selbst zusammensucht ... und zwar nicht nur deshalb, weil man schließlich auch selbst das Problem hat, sondern auch, weil die Thematik viel zu komplex ist, als daß man eine Konfiguration tatsächlich in so dürren Worten wie in #1 so weit beschreiben kann, daß andere eine Entscheidung treffen können, ob ihre eigene Installation (und die daraus resultierenden Erfahrungen) überhaupt vergleichbar ist (sind).

Ob in der 7530 Ports für die 7590 freigegeben werden (was die dann damit macht, ist der 7530 egal) und auch welche, steht (a) im Event-Log der 7530 und läßt sich (b) über die "Sicherheit"-Seite in der 7530 jederzeit nachlesen und findet sich (noch viel ausführlicher) in der Support-Datei der 7530. In der 7590 sollte man (bei automatischer Freigabe) dann auch noch sehen können, welche Portnummern tatsächlich freigegeben wurden im Rahmen der PCP-Nutzung.

Man muß also weder wild spekulieren, warum das VoIP nun nicht funktionieren mag, noch muß man sich irgendwelche Infos aus anderen Installationen (und die Erfahrungen anderer dürften ja klar darauf beruhen, wenn sie hier "nachgefragt" werden) besorgen ... zumal diese bei den wenigen Infos aus #1 wohl auch nur selten die Situation vor Ort 1:1 nachbilden werden.

Denn hier reicht es ja ganz offensichtlich bereits aus, wenn aus irgendeinem Grund die Daemons in der ersten FRITZ!Box (der 7530) die Ports selbst nutzen (und auch das steht wieder in der "Sicherheit"-Seite im GUI) und der PCP-Daemon sich dann dazu veranlaßt sieht, anstelle des eigentlich angeforderten, externen Ports einen anderen zuzuweisen.

BTW ... Auch würde ich - sofern ich eine Installation noch nicht am Laufen habe - von Beginn an erst einmal auf den Einsatz einer Beta-Version (zumindest lt. Signatur) verzichten ... sollte nämlich eines der Probleme tatsächlich darauf beruhen, daß die Labor-Version noch einen Fehler enthält, wäre das schon mal eine denkbare Erklärung ... und trotzdem fühlen sich ggf. spätere Leser hier auch "angesprochen", weil sie gar nicht erkennen können, daß es sich um ein vollkommen anderes Problem handelt, das bis dahin vermutlich lange korrigiert ist. Nach der nächsten Änderung Deiner Signatur sieht nämlich NIEMAND in diesem Thread mehr, daß die 7590 eine Labor-Version verwendet und die PCP-Implementierung ist und bleibt eine Baustelle in der AVM-Firmware - ebendiese ist aber dafür verantwortlich, daß solche Freigaben dann auch "automatisch" bis zum Edge-Router durchgestellt werden.
 
Lass uns am besten versuchen die Ausgangsfrage zu klären
Leider ist das nicht so einfach. Normalerweise brauchst Du überhaupt keine Ports freigeben. Begründung: Die Endgeräte sorgen für das Öffnen, indem die Ports benutzt werden. Im Fall von VoIP öffnet ein SIP-Telefon von sich aus den RTP-Port für die Sprach-Übertragung – mittels Datenpaketen auf dem Port. Das nennt sich Punching. Was Du eingestellt hast, ist die Öffnung mittels UPnP. Das kann ein Grandstream GRP2613 gar nicht – wäre mir jedenfalls neu. Wenn Du 1&1 mittels VoIP-Telefon im Sub-Heimnetz (188.x) haben willst, musst Du uns erstmal sagen, was nicht geht (Anrufe kommen nicht an, kein Ton bei eingehenden Telefonen, …).

Wenn Du spielen willst, nur zum Test, kannst Du
  • das Grandstream in der FRITZ!Box 7590 als Exposed-Host und
  • die FRITZ!Box 7590 in der FRITZ!Box 7530 als Exposed-Host
anlegen. Bevor Du das machst, solltest Du die neuste Firmware aufspielen und bei beiden Endgeräten gute Passwörter vergeben.
 
Was Du eingestellt hast, ist die Öffnung mittels UPnP. Das kann ein Grandstream GRP2613 gar nicht – wäre mir jedenfalls neu.
Das, was da in #1 gezeigt wird, ist aber die Freigabe der 7590-Ports in der 7530 über PCP - das hat mit UPnP und dem Client hinter der 7590 nur noch sehr am Rande zu tun.
 
Danke für die Tipps,
ich werde dem morgen genauer auf den Grund gehen.

Zum VoIP-Telefon:
Ich bekomme gar keine Verbindung mit dem SIP-Server. Ich mache zur Vollständigkeit halber einige Screenshots von der aktuellen Konfiguration des Grandstream GRP 2613 mit aktueller Firmware.

1.PNG2.PNG3.PNG4.PNG5.PNG
 
Ich würde es, ehrlich gesagt, gar nicht erst versuchen, das Telefon hinter doppeltem NAT bei 1&1 registrieren zu wollen. Entweder das Telefon am ersten Router anschließen, oder die Telefonnummer in der Fritzbox eintragen und das Telefon dort registrieren. Wenn die Rufnummer eh' schon in einer Fritzbox eingetragen ist, funktioniert eine Mehrfachregistrierung bei 1&1 sowieso nicht richtig.
 
Hi, danke für deinen Beitrag.

Parallel Call wird von 1und1 explizit beworben (5 Geräte parallel), daher gehe ich davon aus, dass es in der Fritzbox und in einen VoIP-Telefon gleichzeitig gehen sollte.

Das Telefon hat weitere SIP-Konten für Auslandtelefonie. Ist es denn möglich das VoIP-Telefon direkt über die Fritzbox zu betreiben und parallel z.B. sipgate über das Telefon direkt laufen zu lassen? Hört sich auch kompliziert an.
Mein Sipgate funktioniert wunderbar. Daher sollte es mit 1und1 auch machbar sein.
 
Parallel Call ist doch nicht das gleiche wie Mehrfachregistrierung. Bei letzterer werden ankommende Anrufe von 1&1 nur an einem Telefon signalisiert.
Und das VoIP-Telefon direkt über die Fritzbox zu betreiben und parallel z.B. sipgate über das Telefon direkt laufen zu lassen, hört sich überhaupt nicht kompliziert an. Das ist doch nur ein weiterer Account im Telefon.
Mein sipgate funktioniert auch wunderbar. Die haben auch Erfahrung mit verschiedensten NAT-Umgebungen.
Deshalb sollte es mit 1&1 noch lange nicht machbar sein. Versuche doch mal im ersten Schritt, das Telefon bei 1&1 mit Einfach-NAT zu registrieren.
 
Ich habe das VoIP-Telefon nun über die Fritzbox verbunden.

Wie das geht:
 
Das, was da in #1 gezeigt wird, ist aber die Freigabe der 7590-Ports in der 7530 über PCP - das hat mit UPnP und dem Client hinter der 7590 nur noch sehr am Rande zu tun.
Verstehe ich leider nicht. Ich schreibe mal, was ich denke zu wissen:
Laut Hilfe erlaubt diese Check-Box dann UPnP (und neuerdings PCP). Aus Sicht der FRITZ!Box 7530 ist alles hinter der FRITZ!Box 7590 auch die 7590. Wenn also das Grandstream UPnP (oder PCP) könnte, hätte es so die Möglichkeit die Ports vorne in der 7530 freizuschalten. Kann Grandstream nicht … das war mein Einwurf. Wo liegt im Vorherigen mein Fehler?
 
Darin, daß es vollkommen Wumpe ist, ob die per PCP "weitergereichte Portfreigabe" in der 7590 nun über UPnP oder von Hand eingerichtet wurde.

Diese Checkbox, welche sich nach dem Screenshot eindeutig im GUI der 7530 befindet und offensichtlich der 7590 mit der IP-Adresse 192.168.178.50 das Recht zur automatischen Freigabe einräumt (die ist ja das Gegenteil der manuellen Freigabe, bei der der Benutzer jede dieser Freigaben explizit einrichten muß), erlaubt der 7590 als PCP-"Client" generell die Anforderung von Freigaben, ohne jeden Bezug dazu, wie diese in der 7590 eingerichtet wurden oder ob die gar nur zur eigenen, lokalen Benutzung im dortigen FRITZ!OS benötigt würden (wie z.B. eine GUI-Freigabe der 7590 für deren "WAN"-Port).

Angesichts der Tatsache, daß hier nur von zwei FRITZ!Boxen die Rede ist (einer 7530 und einer 7590), ist die Annahme, daß es sich bei der .50 tatsächlich auch um die 7590 handelt, wohl durchaus legitim (selbst wenn da nur "fritz.box" als Hostname steht) ... die 7530 würde in ihrem eigenen GUI nicht an dieser Stelle auftauchen.

Wenn man also in der 7590 die Ports für das Grandstream von Hand freigibt und dieser 7590 dann die automatische Einrichtung von Freigaben in der 7530 erlaubt, wäre das tatsächlich korrekt - vorausgesetzt, die beiden Firmware-Versionen arbeiten (im PCP-Bereich) so zusammen, wie man das erwarten kann. Dazu MUSS das Grandstream also gar nicht selbst in der Lage sein, Ports im Router freizugeben ... weder per UPnP (aka IGD-/IGD2-Interface) noch per PCP.

Und die manuelle Freigabe in der 7590 ist ja offenbar auch - nach #1 - bereits erfolgt:
Also --> "Internet" --> "Freigaben" --> "Portfreigaben". Soweit alles definiert.
Hier ging/geht es dem Fragesteller also nur noch darum, wie er diese Freigaben durch die Kaskade kriegt und ob dazu die - im Screenshot in #1 gezeigte - Erlaubnis an die 7590 ausreichend wäre - so lese jedenfalls ich das in #1 und den folgenden Beiträgen von seiner Seite.

Da macht die Frage, welche Ports in der 7590 von ihm freigegeben wurden und wie das danach in der 7530 aussieht, vielleicht noch Sinn ... die Betrachtung des Telefons hinter der 7590 ist dabei ziemlich egal (deshalb mein "nur noch am Rande"), das könnte auch jeder andere, beliebige Client sein, der einen Service "bis ins Internet" bereitstellen soll.

EDIT: Mal noch ein Beispiel, warum das PCP schon "einigermaßen geil" ist ... durch diesen Mechanismus ist es (wenn man die Rechte für die gesamte Kaskade einräumt) durchaus auch machbar, daß ein FTP-Server auf dem kaskadierten Router immer noch mit dynamischen Ports und passiven Transfers arbeiten kann - dazu muß nur der FTP-Server vor der Antwort auf das "PASV"-Kommando des Clients seinerseits per PCP dafür sorgen, daß der "ausgewählte" Port für die Datenübertragung auch freigeschaltet wird ... um den Rest kümmert sich dann die PCP-Implementierung und da der FTP-Server (als PCP-Client) mit der Bestätigung sogar die Info erhält, welcher externe Port nun tatsächlich freigegeben wurde, kann er die Antwort auf PASV auch gleich passend ändern, wenn die Weiterleitung nicht 1:1 möglich war - was in "großen Installationen", wo dann PCP z.B. zur IPv4-Freigabe trotz DS-Lite-Anschluß verwendet werden kann, schon eine Rolle spielt, weil da Konflikte zwischen dem lokal geäußerten "Wunsch" und den realen Möglichkeiten des AFTR-Servers praktisch vorprogrammiert sind. Solche PCP-Freigaben müssen also nicht immer nur "statisch" sein und ständig auf eingehende Verbindungen warten ... es gibt durchaus auch Protokolle, wo man die Möglichkeiten des PCP-Protokolls höchst dynamisch nutzen und dabei immer noch sinnvoll einsetzen kann. Der FTP-Server in einer FRITZ!Box arbeitet dann auch wieder als PCP-Client in Relation zu seinem lokalen PCP-Server und erst der ist dann dafür zuständig, die Freigabe bis zur richtigen, öffentlichen IPv4-Adresse "durchzustellen" und die Rückmeldung dann wieder an den (PCP-)Client zu geben. Wer das ausprobieren will, kann dazu das Programm "pcplisten" aus der AVM-Firmware mal genauer ansehen - genau das verwendet auch der FTP-Server im FRITZ!OS an dieser Stelle.
 
Zuletzt bearbeitet:
Es geht dem Fragesteller nur noch darum, wie er diese Freigaben durch die Kaskade kriegt und ob dazu die – im Screenshot in #1 gezeigte – Erlaubnis an die 7590 ausreichend wäre.
Ahh. Du meinst die statisch getätigten Freigaben in der 7590 und wie die an die 7530 kommen. Ich meinte, dass für VoIP/SIP überhaupt keine solchen Freigaben auf der 7590 (und der 7530) nötig seien.
 
Ich meinte, dass für VoIP/SIP überhaupt keine solchen Freigaben auf der 7590 (und der 7530) nötig seien.
Das hast Du - am Beginn des Absatzes - ja auch geschrieben und gegen Deine Erklärung des "hole punchings" richtet sich mein Einwand ja auch gar nicht.

Wobei das hier auch nicht 100% korrekt ist in meinen Augen, weil die Gegenstelle (der SIP-Registrar beim Provider) ja direkt kontaktiert wird und keine dritte Partei als "Vermittler" im Spiel ist (https://en.wikipedia.org/wiki/Hole_punching_(networking), die den beiden anderen jeweils die dynamisch verwendeten Ports des Gegenübers mitteilt. Zumindest nicht bei der SIP-Kommunikation, die Du hier ja hervorhebst, bei RTP kann das dann wieder anders sein ... eigentlich ist das hier nur eine stinknormale ausgehende Connection durch einen NAT-Router und zwar auch nur auf einer Seite, nämlich der mit der FRITZ!Box, die auch denselben "Regeln" unterliegt, wie jede andere TCP- oder UDP-Verbindung, insb. dem "Timeout" bei UDP-"Verbindungen" (die es eigentlich ja gar nicht gibt).

Ich habe aber die beiden Sätze (in der originalen Reihenfolge), auf die sich mein Einwand bezog, eindeutig zitiert und da bringst Du die fehlenden UPnP-Fähigkeiten des Grandstream in einen direkten Zusammenhang mit den im Screenshot gezeigten Einstellungen - ein solcher existiert schlicht nicht. Mehr wollte ich da gar nicht verdeutlichen.

Aber auch mit der sich anschließenden Feststellung aus dem Zitat in diesem Beitrag hier (die sich hier ja nicht explizit auf das verwendete SIP-Telefon bezieht und dessen Fähigkeiten kenne ich tatsächlich nicht detailliert genug, um das einschätzen zu können), daß für VoIP/SIP überhaupt keine Freigaben notwendig wären, gehe ich nicht so ganz konform ... egal, ob man dabei den Kontext "FRITZ!Box" noch zusätzlich einbindet oder nicht, denn hier ist wieder der UA entscheidend und wo er sich registriert (ob in der FRITZ!Box oder direkt bei einem Provider) und nicht der verwendete Router (zumindest nicht im Hinblick auf seine Eigenschaften als Router, auch wenn das bei einem IAD wie einer FRITZ!Box natürlich ein und dasselbe Gerät sein kann).

Ein automatisches Aufrechterhalten der Verbindung durch einen NAT-Router im Rahmen eines SIP-Dialogs kann auf mehreren Wegen erfolgen ... von wiederholten Registrierungen bis zu "eingestreuten" SIP-Messages wie "OPTIONS", die durchaus auch unterschiedliche Wirkungen entfalten und ansonsten keinen wirklichen Nutzen hinsichtlich ausgetauschter Informationen haben. Bei einem REGISTER wird (u.a.) eine "life time" für eine Registrierung vereinbart ("Expires"-Header allgemein bzw. "expires"-Option für den "Contact"-Header) und für diesen Zeitraum (zumindest für den kleineren der beiden, wenn beide angegeben sind) darf der "Registrar" davon ausgehen, daß er den UA auch unter der angegebenen IP-Adresse auf dem angegebenen Port "erreichen" kann - sprich: ihm auch weiterhin Datenpakete zuschicken kann, die diesen dann auch tatsächlich erreichen.

Liegt diese Zeitspanne jetzt aber oberhalb des in dem NAT-Router eingestellten Timeouts für ausgehende UDP-Verbindungen (mal kann man es sogar im Router-OS einstellen, bei der FRITZ!Box hingegen nicht), wird ggf. diese ausgehende Verbindung bereits abgeräumt, bevor die "expiration" auftritt und dann zerschellen weitere eingehende Pakete schlicht an dieser Firewall.

Dem kann der UA dann nur dadurch entgegenwirken, daß er halt regelmäßig weitere Daten in dieser "Verbindung" sendet (quasi als "keepalive") und damit den Timeout-Counter jeweils neu startet - und das muß der UA dann aber erst einmal beherrschen und man muß es am Ende dort auch passend einstellen können (da bin ich wieder bei den - mir unbekannten - Features des Telefons). Es gibt aber definitiv auch genug SIP-UAs, denen diese Möglichkeiten fehlen und die damit auf einen statischen Port und eine entsprechende Freigabe angewiesen sind, damit eben diese Timeouts keine Rolle mehr spielen, auch wenn der UA ansonsten keine anderen Möglichkeiten bietet, ausgehende Verbindungen durch eine NAT-Firewall mit unbekannten Konditionen am Leben zu erhalten.

Das findet man zwar (inzwischen) nicht mehr oft, aber zum Verallgemeinern, daß es überhaupt nicht notwendig wäre, ist es noch zu früh - für einen konkreten Fall wird das meistens allerdings tatsächlich stimmen. Aber schon bei der Frage, ob ein Router nun ein SIP-ALG bietet und damit die freizuschaltenden Ports von selbst "lernt" (indem er die Registrierungen analysiert und anpaßt an seine (verfügbaren) Ports, ggf. sogar diese länger offenhält als andere UDP-Ports), gibt es die nächsten Unterschiede und es entstehen die nächsten Fragen, wenn man SIP-ALG mit anderen Techniken kombiniert und es nicht klappen will.
 
Ähh. Ich hatte das Problem aus einem anderen Blickwinkel betrachtet – und zwar aus dem, dass bei VoIP/SIP nach jetzt wirklich nach 20 Jahren diese Port-Forwarderei nicht die erste Herangehensweise sein sollte, weil die SIP-Clients das inzwischen gebacken bekommen sollten. Abgesehen davon, dass ich ein (vergleichsweise aktuelles) Grandstream hier habe und genau das so bei mir klappt. Deswegen sollte man (meiner Meinung nach) das systematisch angehen und untersuchen, bevor man wild irgendwelche Ports aufmacht. Hier kann man gerne anderer Meinung sein, es aufgeben und Ports freischalten. 123sat hat es noch schlauer gelöst, indem er das mit dem Double-NAT nochmals überdacht hat und sogar das Grandstream direkt in die FRITZ!box angemeldet hat – also gar kein NAT bzw. Firewall mehr im Spiel ist. Ideal.
bringst Du die fehlenden UPnP-Fähigkeiten des Grandstream in einen direkten Zusammenhang mit den im Screenshot gezeigten Einstellungen – ein solcher existiert schlicht nicht.
Ähh. Doch – oder ich habe es immer noch nicht verstanden; meine These anders herum formuliert: Wenn das Grandstream UPnP (oder PCP) hätte, könnte es diese Forwarding-Rule (in der 7530) nutzen, um sich die Ports freizuschalten, weil das Grandstream aus Sicht des 7530 die 7590 ist.
 
Wenn das Grandstream IGD oder PCP beherrschen würde, wäre es - nach der Konfiguration in #1, die sich tatsächlich von der letztendlichen Lösung unterscheidet, das kam aber erst danach - immer noch die 7590, in der es zuerst die Ports freischalten müßte. Und ob das dann bis in die 7530 "durchschlagen" würde, hängt exakt von der gezeigten Einstellung ab.

Was genau hat das jetzt mit der Feststellung:
Was Du eingestellt hast
, die sich ja nur auf die 7530 beziehen kann, denn für die 7590 weißt Du ja gar nicht (wie alle anderen hier auch), was da eingestellt wurde, zu tun? Exakt diese setzt Du im nächsten zitierten Satz dann in Beziehung zu der Frage, ob das Telefon nun UPnP beherrscht oder nicht.

Die gezeigte Einstellung erlaubt es aber der 7590 nur, die bei ihr selbst freigegebenen bzw. freizugebenden Ports (sowohl für lokale Dienste auf der 7590 als auch für Services auf den Clients hinter dieser 7590) auch in der 7530 "durchzuschalten" ... wobei eben eine 1:1-Weiterleitung bei PCP generell nicht garantiert ist.

Wie diese Freigaben in der 7590 am Ende zustande gekommen sind (statisch oder dynamisch), interessiert dabei nicht die Bohne - kann man ja (sofern man zwei Versionen hat, deren PCP-Implementierungen zueinander passen) jederzeit selbst bei sich ausprobieren mit zwei kaskadierten Boxen.

Und dabei ist es vollkommen Bummi, ob die Geräte hinter dem zweiten Router in der Kaskade ihre Freigabewünsche dynamisch bei diesem (zweiten) Router anmelden oder nicht - beide Formen sollten zu einer (hier natürlich nur noch dynamischen) Freigabe im ersten Router in der Kaskade führen. Auch eine statische Freigabe im zweiten Router wird also dynamisch an den ersten weitergegeben ... und nicht etwa (wie bei Telefonie im Mesh o.ä. denkbar, je nachdem, wer da Master und wer Slave ist) die Einstellungen in der ersten Box ebenfalls statisch übernommen.

Die neue Prämisse, daß das Telefon jetzt, wo es direkt an der 7530 angeschlossen ist, sich seine Ports auch per UPnP in der 7530 freischalten könnte (sofern es das beherrscht), interessiert doch gar nicht ... die hat ja mit den Einstellungen aus #1, auf die Du Dich bezogen hast, nichts zu tun.
Wenn das Grandstream UPnP (oder PCP) hätte, könnte es diese Forwarding-Rule (in der 7530) nutzen, um sich die Ports freizuschalten
Das kann es auch kaum gewesen sein, was Du in #8 gemeint hast ... denn dort empfiehlst Du ja im Anschluß selbst noch, von der 7530 ausgehend, über die 7590 bis zum Telefon alles als "exposed host" freizugeben (wenn auch nur zum Test) und die Änderung der Topologie erfolgte erst in #14.

Ich weiß aber auch nicht so 100%ig, wie Du aus der Feststellung:
Ich habe das VoIP-Telefon nun über die Fritzbox verbunden.
jetzt schließt, daß als Registrar die 7530 dient:
das Grandstream direkt in die FRITZ!box angemeldet hat – also gar kein NAT bzw. Firewall mehr im Spiel ist. Ideal.
Ich lese da nichts, was dagegen sprechen würde, daß er immer noch die 7590 als Registrar verwendet. Da deren "SIP-Client" in Richtung Provider dann tatsächlich wieder ohne Freigaben auskommt (weil die Box als ein solcher UA all das kann, was dazu erforderlich ist, eine UDP-Connection eben nicht vorzeitig zu verlieren), würde das (erst recht mit der Erlaubnis für die 7590 zur automatischen Freigabe, auch wenn die hier wohl nicht benutzt wird) ebenso funktionieren.

Und da wäre dann sehr wohl noch NAT und auch eine Firewall - nämlich die in der 7530 - im Spiel ... ich sehe jedenfalls in diesem Thread nichts, was eine der beiden Annahmen ausschließen würde nach #14 und nur darauf kann ich mich hier beziehen (ggf. hast Du ja weitere Infos).
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.