Fritzbox hinter Zyxel USG210 - alles von erreichbar - nicht erreichbar - kein Audio
Hallo, kämpfe leider seit geraumer Zeit mit dem oben genannten Problem. Habe eine USG210 mit 1xWAN1 Internet 1&1 (VDSL 50.000/10.000 - VOIP Provider) sowie 1xWAN2 KabelD (100.000/6.000 - kein VOIP). Die Fritzbox 7390 läuft als IP Client in der DMZ. Habe bereits vieles probiert, SIP ALG an/aus, 1:1 NAT, Firewall Regeln, Policy Routes etc.
Meist geht es kurz, doch kurz darauf bin ich entweder gar nicht ereichbar, erreichbar aber kein Audio. Rausrufen geht in der Regel zu 95%.
Bin um jeden Hinweis oder Hilfestellung dankbar - gern auch gegen adequate Bezahlung sofern sich das Problem dauerhaft löst.
Meist geht es kurz, doch kurz darauf bin ich entweder gar nicht ereichbar, erreichbar aber kein Audio. Rausrufen geht in der Regel zu 95%.
Bin um jeden Hinweis oder Hilfestellung dankbar - gern auch gegen adequate Bezahlung sofern sich das Problem dauerhaft löst.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 249783
Url: https://administrator.de/forum/fritzbox-hinter-zyxel-usg210-alles-von-erreichbar-nicht-erreichbar-kein-audio-249783.html
Ausgedruckt am: 15.04.2025 um 22:04 Uhr
10 Kommentare
Neuester Kommentar
Die USG210 hat ja kein internes VDSL Modem. Die Frage ist also WIE du diese an den VDSL Anschluss bekommen hast ??
Ist dort ein reines VDSL Modem davor ?
Das generelle Problem ist bei SIP (VoIP) das es dynamische Ports benutzt. Die SIP Antwort vom Provider will also einen anderen Port connecten als den in der NAT Session Tabelle der Firewall die das Packet dann blockt.
Am einfachsten ist es wenn du einen entsprechenden STUN Server definierst. Dadurch kann dann SIP durchs NAT der Firewall passieren.
Andernfalls musst du mal sehen ob die Zyxel FW einen speziellen Ruleset für SIP/RTP hat. Fast alle Firewalls haben es mittlerweile durch die Verbreitung von VoIP.
Dr. Google hilft auch wenn man ihn fragt:
http://www.lmdfdg.at/?q=zyxel+usg+voip
Ist dort ein reines VDSL Modem davor ?
- Wenn nein ist dort ein Router davor ?
- Wenn es ein Modem ist macht das das VDSL VLAN ID 7 Tagging oder macht das deine USG210 analog wie es hier beschrieben ist ?
- Wenn es eine Router Kaskade ist, dann musst du natürlich 2 mal Port Forwarding machen !
Das generelle Problem ist bei SIP (VoIP) das es dynamische Ports benutzt. Die SIP Antwort vom Provider will also einen anderen Port connecten als den in der NAT Session Tabelle der Firewall die das Packet dann blockt.
Am einfachsten ist es wenn du einen entsprechenden STUN Server definierst. Dadurch kann dann SIP durchs NAT der Firewall passieren.
Andernfalls musst du mal sehen ob die Zyxel FW einen speziellen Ruleset für SIP/RTP hat. Fast alle Firewalls haben es mittlerweile durch die Verbreitung von VoIP.
Dr. Google hilft auch wenn man ihn fragt:
http://www.lmdfdg.at/?q=zyxel+usg+voip
Das VDSL von 1&1 wird am WAN1 der USG durch einen ZyXEL VMG1312-B30A im Bridge Modus bereitgestellt (In der USG210 sind die Anmeldedaten für die Einwahl hinterlegt). An WAN2 hängt das Kabelmodem von KabelDeutschland, ebenfalls gebridget.
Perfekt, das limitiert die ganzen Settings dann einzig auf die USG.Machs dir doch ganz einfach und nimm einen Wireshark zur Hand. Damit snifferst du mal vor und hinter der Firewall und vergleichst die SIP/RTP Pakete was durchkommt und was nicht.
Testweise machts du erstmal die USG ganz auf um überhaupt erstmal einen funktionieren SIP Sessionaufbau mit der FB hinzubekommen. Idealerweise snifferst du den auch gleich mit mit dem Wireshark um den Flow einer sauberen SIP Session zu haben und mit dem Blocking Verhalten der USG zu vergleichen.
So kannst du dich wunderbar rantasten was du öffnen musst und was nicht !
Wenn die Zyxel keinen entsprechenden VoIP Ruleset hat, dann wirds natürlich etwas böse, da du dann den gesamten möglichen Port Bereich vom SIP UDP eingehend öffnen musst.
Damit konterkariert man quasi eine Firewall zur Bedeutungslosigkeit und es würde die Zyxel für den VoIP Bereich vollkommen disqualifizieren.
Wie gesagt am elegantesten löst du das mit Angabe eines STUN Servers auf dem VoIP Endgerät also hier der Fritzbox. So musst du keine Scheunentor großen Löcher in die Firewall bohren !
entsprechend dieser Doku in der Fritte hinterlget - hilft nur nichts:
Hast du mal mit dem Kabelhai geprüft ob die Fritte sich denn STUN konform verhält ?? Benutzt sie STUN ? Wenn nicht ist das ja dann klar ein Bug in der AVM Firmware, was aber echt ungewöhnlich wäre.Oder blockt die USG auch noch die STUN Pakete ?? Wenn das der Fall ist ist klar das das dann auch fehlschlägt....!
Wie bereits gesagt: Nimm dir den Kabelhai und miss das einmal mit USG einmal ohne bzw. davor und dahinter.
Dann weisst du doch sofort was los ist !
In einem Forum duzt man sich in der Regel ! <editiert vom Verfasser
>
Die Vorgehensweise ist schon richtig. Vor der FW einen Mirrorport einrichten oder mit einem Hub den Traffic spiegeln. PPPoE encasulierte Frames sind ja nicht verschlüsselt und ohne FW kann man so einen vollständigen SIP Aufbau mitsniffern der zu einer bestehenden und funktionierenden SIP Verbindung führt.
Danach dann mit der FW im Pfad. So kann man sehen welche Pakete die FW wegfiltert und das entsprechend anpassen das das SIP sauber funktioniert.
Die Vorgehensweise ist schon richtig. Vor der FW einen Mirrorport einrichten oder mit einem Hub den Traffic spiegeln. PPPoE encasulierte Frames sind ja nicht verschlüsselt und ohne FW kann man so einen vollständigen SIP Aufbau mitsniffern der zu einer bestehenden und funktionierenden SIP Verbindung führt.
Danach dann mit der FW im Pfad. So kann man sehen welche Pakete die FW wegfiltert und das entsprechend anpassen das das SIP sauber funktioniert.
Szenario1
DSL Modem --> Hub -->USG-->Fritzbox
-->Wireshark
Nein, der Hub dient nur dazu den Traffic zu speigeln. Wie willst du sonst den Wireshark in die Datenverbindung bringen ??DSL Modem --> Hub -->USG-->Fritzbox
-->Wireshark
Die USG hat doch kein Mirrorport, oder ? Würd mich wundern bei dem Billigprodukt !
Ausnahme du betreibst den Wireshark mit 2 NICs als Probe:
http://www.heise.de/netze/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22 ...
Über einen Hub spiegelst du ja den Traffic an alle Hub Ports ohne Bridge
Der Wireshark muss also immer an den Hub. Ggf. meintest du das auch so und hast das nur falsch dargestellt.
So sind dann beide Szenarios richtig !