21
Konfiguration VOIP: Grundsätzliche Fragen
Hallo,
Ziel: IP-Telefon (Gigaset C430A Go) hinter einer pfsense als "Festnetztelefon" betreiben
Mein Router/Firewall ist ein Apu2, darauf pfsense installiert.
Mein Switch ist ein Cisco SG350-28
Ich habe mehrere VLANs konfiguriert, natürlich auf den Switch und dem Router.
Diese sind verbunden über einen "tagged Trunk Port"
Als Firewallregel habe ich in allen VLANs das "Scheunentor" geöffnet, um jene als Fehlerquelle auszuschließen.
Die Basisstation des IP-Telefons liegt im VLAN30 (DMZ)
Mein Internetanbieter ist: Deutsche Glasfaser
In den Anleitungen im Internet (leider ist mein Anwendungsfall nirgendwo konkret beschrieben), sind vier Werte von Bedeutung:
IP des Telefons: 192.168.30.155 (als statische IP eingerichtet)
SIP-Port: 5060
RTP-Ports: 7078:7109 (diese wurden in der fritzbox verwendet)
Registrar: de.voip.dg-w.de (nslookup sagt: 185.22.44.186)
Durch Firewall Regeln müssen diese so konfiguriert werden, dass ein Verbindung zustande kommt.
Hier ist mein Problem. Ich verstehe das Prinzip dahinter nicht.
In einer Anleitung >hier< (weiter unten) wird ein ähnlicher Anwendungsfall beschrieben.
Der Verfasser setzt folgende Schritte um:
(1) Der Datenverkehr vom Gigaset zum SIP-Port und den RTP-Ports muss über das VLAN-Gatenway erfolgen
(2) Der Datenverkehr über das VLAN zum Gigaset SIP- und RTP-Port wird geregelt
(3) Ausgehende NAT-Regeln werden konfiguriert
(4) Eingehende NAT-Regeln: Zum Schluss leiten wir noch die SIP und RTP-Ports eingehend an das Gigaset-Telefon weiter
Diese Angaben sind für mich sehr abstrakt.
Ich wäre sehr dankbar, wenn mir jemand für meinen Anwendungsfall nützliche Tipps zu Vorgehensweise geben könnte ...
Ziel: IP-Telefon (Gigaset C430A Go) hinter einer pfsense als "Festnetztelefon" betreiben
Mein Router/Firewall ist ein Apu2, darauf pfsense installiert.
Mein Switch ist ein Cisco SG350-28
Ich habe mehrere VLANs konfiguriert, natürlich auf den Switch und dem Router.
Diese sind verbunden über einen "tagged Trunk Port"
Als Firewallregel habe ich in allen VLANs das "Scheunentor" geöffnet, um jene als Fehlerquelle auszuschließen.
Die Basisstation des IP-Telefons liegt im VLAN30 (DMZ)
Mein Internetanbieter ist: Deutsche Glasfaser
In den Anleitungen im Internet (leider ist mein Anwendungsfall nirgendwo konkret beschrieben), sind vier Werte von Bedeutung:
IP des Telefons: 192.168.30.155 (als statische IP eingerichtet)
SIP-Port: 5060
RTP-Ports: 7078:7109 (diese wurden in der fritzbox verwendet)
Registrar: de.voip.dg-w.de (nslookup sagt: 185.22.44.186)
Durch Firewall Regeln müssen diese so konfiguriert werden, dass ein Verbindung zustande kommt.
Hier ist mein Problem. Ich verstehe das Prinzip dahinter nicht.
In einer Anleitung >hier< (weiter unten) wird ein ähnlicher Anwendungsfall beschrieben.
Der Verfasser setzt folgende Schritte um:
(1) Der Datenverkehr vom Gigaset zum SIP-Port und den RTP-Ports muss über das VLAN-Gatenway erfolgen
(2) Der Datenverkehr über das VLAN zum Gigaset SIP- und RTP-Port wird geregelt
(3) Ausgehende NAT-Regeln werden konfiguriert
(4) Eingehende NAT-Regeln: Zum Schluss leiten wir noch die SIP und RTP-Ports eingehend an das Gigaset-Telefon weiter
Diese Angaben sind für mich sehr abstrakt.
Ich wäre sehr dankbar, wenn mir jemand für meinen Anwendungsfall nützliche Tipps zu Vorgehensweise geben könnte ...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 574177
Url: https://administrator.de/contentid/574177
Ausgedruckt am: 22.11.2024 um 13:11 Uhr
21 Kommentare
Neuester Kommentar
Tut mir leid, aber selbst beim vierten durchlesen finde ich keine Frage.
Funktioniert es nicht, bekommst du es nicht eingerichtet oder was?
Funktioniert es nicht, bekommst du es nicht eingerichtet oder was?
Ja, richtig, entschuldige, die konkrete Frage dahinter ist:
Wie richte die Firewall-Regeln so ein, dass eine Verbindung zustande kommt?
Ich kann nirgendwo ansetzen, weil ich das Prinzip dahinter nicht verstehe.
Ansonsten könnte ich mir vielleicht die Anwendungsschritte "zusammen googlen".
Wie richte die Firewall-Regeln so ein, dass eine Verbindung zustande kommt?
Ich kann nirgendwo ansetzen, weil ich das Prinzip dahinter nicht verstehe.
Ansonsten könnte ich mir vielleicht die Anwendungsschritte "zusammen googlen".
Funktioniert denn die Telefonie, wenn du alles von dem LAN, in dem das Telefon steht, ins WAN erlaubst? Heutzutage ist meist nicht mehr notwendig, da die Telefoniesysteme der Provider mit NAT umgehen können und im Gegensatz zu meiner Anfangszeit mit VoIP (vor etwa 15 Jahren) keine Portweiterleitungen mehr benötigen.
Knackpunkt ist der STUN Server. Wenn möglich sollte der immer konfiguriert werden im Telefon.
Die Einrichtung wird hier sehr gut erklärt:
https://bergs.biz/blog/2017/02/18/deutsche-glasfaser-sip-account-manuell ...
Der STUN Server bewirkt das es an der Firewall keinen Stress mit den dynmaischen RTP Ports gibt. Kann man kein STUN definieren müssen die RTP Ports freigegeben werden.
Die entsprechenden Einstellungen findet man im [ pfSense_Tutorial] in den weiterführenden Links unter "VoIP bzw. Telefonie mit FritzBox oder Anlage hinter pfSense Firewall:"
An den Standard Default NAT Regeln muss man nicht rumfummeln !
Heisser Tip:
Nimm zum Testen immer ein Softphone wie z.B. Phoner:
http://phoner.de/index.htm
oder Phoner Lite:
https://lite.phoner.de/index_de.htm
Phoner bevorzugt da bessere Logging Optionen. Den Phoner konfigurierst du mit deinen SIP Credentials und STUN und los gehts wie beim Gigaset.
Damit kannst du auf einem Test PC im Test VLAN 30 dann erstmal üben.
Phoner hat sehr gite Logging Optionen die dir genau sagen wo es kneift und was du anpassen musst.
Klappt das alles überträgst du schlicht und einfach nur die Daten aufs Gigaset und gut iss...
Eigentlich kein Hexenwerk !
Die Einrichtung wird hier sehr gut erklärt:
https://bergs.biz/blog/2017/02/18/deutsche-glasfaser-sip-account-manuell ...
Der STUN Server bewirkt das es an der Firewall keinen Stress mit den dynmaischen RTP Ports gibt. Kann man kein STUN definieren müssen die RTP Ports freigegeben werden.
Die entsprechenden Einstellungen findet man im [ pfSense_Tutorial] in den weiterführenden Links unter "VoIP bzw. Telefonie mit FritzBox oder Anlage hinter pfSense Firewall:"
An den Standard Default NAT Regeln muss man nicht rumfummeln !
Heisser Tip:
Nimm zum Testen immer ein Softphone wie z.B. Phoner:
http://phoner.de/index.htm
oder Phoner Lite:
https://lite.phoner.de/index_de.htm
Phoner bevorzugt da bessere Logging Optionen. Den Phoner konfigurierst du mit deinen SIP Credentials und STUN und los gehts wie beim Gigaset.
Damit kannst du auf einem Test PC im Test VLAN 30 dann erstmal üben.
Phoner hat sehr gite Logging Optionen die dir genau sagen wo es kneift und was du anpassen musst.
Klappt das alles überträgst du schlicht und einfach nur die Daten aufs Gigaset und gut iss...
Eigentlich kein Hexenwerk !
@aqui: Pass mit der Aussage auf, bei Unitymedia sollte man es nicht machen, weil die IPv4-Adressen der Telefonie selbst private IP-Adressen sind, auch wenn man einen IPv4 oder einen echten Dual-Stack-Anschluss hat. Hier ist man z.B. gezwungen, die Telefonie auf dem Router laufen zu lassen, weil mit STUN geht es nicht, ohne auch nicht und ein SIP-ALG im Router machts kaputt.
Ein ordentlicher Telefonieanbieter bietet entsprechende Möglichkeiten, also STUN oder die Technik selbst ist NAT-fähig (easybell benötigt z.B. kein STUN oder SIP-ALG, sondern die passen die SIP-Payload anhand des IP-Headers an., QSC verbietet strikt SIP-ALGs und können mit NAT umgehen). Die Provider, insbesondere die Zwangsrouterbefürworter wie Telefonica, Vodafone (inkl. Unitymedia) und DG, haben kein Interesse daran. Deren Router sind IADs, also die Telefonie liegt direkt am WAN-Interface und benötigt kein NAT, daher gibt es hier keine Transitionstechniken und wenn es nicht funktioniert, ist es ja eh Problem des Kunden, weil Eigenrouter nicht unterstützt werden.
@scriptorius: Betreibst du ein eigenes ONT statt dem DG-Router am Anschluss? Weil dieses ist ja Pflichtprogramm, um die SIP-Zugangsdaten zu erhalten.
Ein ordentlicher Telefonieanbieter bietet entsprechende Möglichkeiten, also STUN oder die Technik selbst ist NAT-fähig (easybell benötigt z.B. kein STUN oder SIP-ALG, sondern die passen die SIP-Payload anhand des IP-Headers an., QSC verbietet strikt SIP-ALGs und können mit NAT umgehen). Die Provider, insbesondere die Zwangsrouterbefürworter wie Telefonica, Vodafone (inkl. Unitymedia) und DG, haben kein Interesse daran. Deren Router sind IADs, also die Telefonie liegt direkt am WAN-Interface und benötigt kein NAT, daher gibt es hier keine Transitionstechniken und wenn es nicht funktioniert, ist es ja eh Problem des Kunden, weil Eigenrouter nicht unterstützt werden.
@scriptorius: Betreibst du ein eigenes ONT statt dem DG-Router am Anschluss? Weil dieses ist ja Pflichtprogramm, um die SIP-Zugangsdaten zu erhalten.
Wird ja immer gruseliger bei Unitymedia und diesen pestigen DS-Lite Anschlüssen. Danke fürs Feedback. Wieder was gelernt und wieder mal froh KEIN Kunde dieses Providers zu sein ! 
Vielen Dank für die Hilfsbereitschaft
Ja, ich habe damals bei der Anmeldung gesagt, dass ich einen eigenen Router habe.
Die pfsense hängt auch gleich am ONT ohne weiteren Router dazwischen.
Bei der Standard-Erstkonfiguration mit Assistent kann ich meine Daten eingeben, es kommt allerdings: Anmeldung bei Provider nicht erfolgreich.
Ja, ich habe damals bei der Anmeldung gesagt, dass ich einen eigenen Router habe.
Die pfsense hängt auch gleich am ONT ohne weiteren Router dazwischen.
Bei der Standard-Erstkonfiguration mit Assistent kann ich meine Daten eingeben, es kommt allerdings: Anmeldung bei Provider nicht erfolgreich.
Bleibt das stehen? Die Gigasets sind ###e langsam und man muss die Seite nach ein paar Sekunden neu laden. Direkt nach dem Speichern steht da immer "Anmeldung beim Provider nicht erfolgreich".
Das hat mit DS-Lite nix zu tun. Ich hab hier einen richtigen DS-Anschluss und das gleiche Problem. Gibt aber einen Trick, wenn das Netz und die Endgeräte IPv6-tauglich sind (Gigasets gehören da nicht zu). Wenn man den Registrar von Unitymedia bekommt, steht bei den Zugangsdaten irgendwo was nach dem Schema ssl91-v4.telefon.unitymedia.de oder ssl91.telefon.unitymedia.de (die Zahl hinter ssl ändert sich). Wenn man hinter das sslXX ein -v6 macht, kann man eine IPv6-Registrierung erzwingen.
Wundert mich, dass das der alte Nortel CS2000 schon kann.
Bei mir ging es nicht und die OpenScape Business kann kein IPv6, also registriert sich jetzt mein Router als SBC und gibt es an die Telefonanlage weiter.
Wundert mich, dass das der alte Nortel CS2000 schon kann.
Bei mir ging es nicht und die OpenScape Business kann kein IPv6, also registriert sich jetzt mein Router als SBC und gibt es an die Telefonanlage weiter.
So, in der Zwischenzeit habe ich alles mögliche versucht.
Immer das gleiche Ergebnis: Anmeldung bei Provider nicht erfolgreich.
Keine Ahnung, woran es liegt.
Das bleibt auch da stehen.
Immer das gleiche Ergebnis: Anmeldung bei Provider nicht erfolgreich.
Keine Ahnung, woran es liegt.
Das bleibt auch da stehen.
Ist die Firewall von dem LAN, in dem das Telefon steht in Richtung WAN komplett offen? Hast du eventuell auf der WAN-Verbindung die RFC1918-Netze verboten? Passiert überhaupt irgendwas, wenn du in Wireshark nachschaust? Wie hast du das Telefon konfiguriert?
O, man ...
Das war es.
Hatte den Zusammenhang nicht auf dem Schirm.
Ich danke Dir.
Hast du eventuell auf der WAN-Verbindung die RFC1918-Netze verboten?
Das war es.
Hatte den Zusammenhang nicht auf dem Schirm.
Ich danke Dir.
Hallo,
der "Leidensweg" ist leider doch noch nicht vorbei.
Nachdem ich die Anmeldung beim Provider gestern kurzzeitig klappte, sieht es heute wieder anders aus.
WAN und LAN30 Regeln sind so:
Die Basisstation habe ich mit Assistenten eingerichtet.
Der Weg ist ja in dem Beispiel von aqui oben beschrieben.
Wo könnte denn das Problem noch liegen?
der "Leidensweg" ist leider doch noch nicht vorbei.
Nachdem ich die Anmeldung beim Provider gestern kurzzeitig klappte, sieht es heute wieder anders aus.
WAN und LAN30 Regeln sind so:
Die Basisstation habe ich mit Assistenten eingerichtet.
Der Weg ist ja in dem Beispiel von aqui oben beschrieben.
Wo könnte denn das Problem noch liegen?
Hatte den Zusammenhang nicht auf dem Schirm.
Und das obwohl es in riesigen Lettern im pfSense Tutorial hier steht !!! Tzzz...WAN und LAN30 Regeln sind so:
Sind richtig. Ist ja mehr oder minder Standard.Nur nochmal doof nachgefragt: Arbeitest du in einer Router Kaskade, sprich ist ggf. VOR der Firewall noch ein Router ? Im schlimmsten Fall ein VoIP Router mit einem eigenen VoIP Gateway ?
Wenn ja "denkt" der vermitlich das alle Voice relevanten Frames für ihn sind und macht dann kein Forwarding dieser Pakete so das die an der pfSense bzw. dem VLAN 30 gar nicht mehr ankommen.
Nochmals: Mache einen Test mit einem Softphone und sieh dir da das Log an. Noch besser wäre dann auf dem Softphone Rechner den SIP Verbindungsaufbau mit dem Wireshark oder tcpdump zu protokollieren.
Dann weiss man ohne wild zu raten und zu spekulieren sofort WO der Fehler ist. So stocherst du doch nur weiter im Dunkeln und probierst sinnfrei im freien Fall alles aus ohne wirklich die Ursache zu kennen.
Stell dir mal vor dein Hausarzt ginge so vor...?!
Sorry für dieses ewige hin und her.
Aber nach weiteren Versuchen habe ich es jetzt hinbekommen.
Ich habe den Anschluss manuell konfiguriert
Mit diesen Einstellungen (s.u.) und den VLAN und WAN Einstellungen (s.o.) verbindet sich jetzt das Gigaset c430a mit dem Anschluss der Deutschen Glasfaser:
Anmeldename ist der SIP_USERNAME
Anmeldepasswort SIP_PASSWORT
Benutzername = Telefonnummer mit Vorwahl
Angezeigter Name = Telefonnummer mit Vorwahl
Die IP Adressen habe ich aufgelöst mit nslookup ( also: dg.voip.dg-w.de)
Aber nach weiteren Versuchen habe ich es jetzt hinbekommen.
Ich habe den Anschluss manuell konfiguriert
Mit diesen Einstellungen (s.u.) und den VLAN und WAN Einstellungen (s.o.) verbindet sich jetzt das Gigaset c430a mit dem Anschluss der Deutschen Glasfaser:
Anmeldename ist der SIP_USERNAME
Anmeldepasswort SIP_PASSWORT
Benutzername = Telefonnummer mit Vorwahl
Angezeigter Name = Telefonnummer mit Vorwahl
Die IP Adressen habe ich aufgelöst mit nslookup ( also: dg.voip.dg-w.de)
Nur nochmal doof nachgefragt: Arbeitest du in einer Router Kaskade, sprich ist ggf. VOR der Firewall noch ein Router ? Im schlimmsten Fall ein VoIP Router mit einem eigenen VoIP Gateway ?
Nein, die Firewall hängt direkt am Internetanschluss ohne Router davorNochmals: Mache einen Test mit einem Softphone und sieh dir da das Log an. Noch besser wäre dann auf dem Softphone Rechner den SIP Verbindungsaufbau mit dem Wireshark oder tcpdump zu protokollieren.
Danke für den Tipp.Hätte ich auch als nächstes gemacht, aber ich wusste ja, dass gestern eine Einstellung die richtige war.
Stell dir mal vor dein Hausarzt ginge so vor...?!
Ja, dann musst Du nur einmal zum Arzt, dann fällt der Deckel zu
Vielen Dank aber trotzdem, VOIP läuft jetzt.
Das heißt, ich kann mit diesen Einstellungen erstmal das Netzwerk hier so betreiben, ohne ständig zwischen frotz.bix und pfsense hin und her zu stöpseln.
Das nächste wird sein, meine kleinen Wireguard- und Nextcloud-Server ins Netzwerk einzubinden.
Dann wäre ich erstmal grundlegend durch.
Klar, die Firewall-Regeln muss ich dann nach und nach enger ziehen ...
Vielen Dank aber trotzdem, VOIP läuft jetzt.
Bingo !! 👍Und das dann auch ganz ohne STUN, oder ??
Wenn du oben den Haken bei DNS Lookup auf "Ja" setzt sollte er auch den Hostnamen dg.voip.dg-w.de statt der 185.22er IP Adressen auflösen können.
Gut wenn's nun rennt wie es soll. !
Das nächste wird sein, meine kleinen Wireguard- und Nextcloud-Server ins Netzwerk einzubinden.
Na ja Wirequard wäre ja Blödsinn bei einer pfSense. Siehe dazu:IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Beim Nextcloud Server freuen wir uns dann auf den nächsten Thread...!
Und das dann auch ganz ohne STUN, oder ??
Ja, ist soWenn du oben den Haken bei DNS Lookup auf "Ja" setzt sollte er auch den Hostnamen dg.voip.dg-w.de statt der 185.22er IP Adressen auflösen können.
Für solche Tipps bin ich immer dankbar.Ich habe es gleich auch mal getestet, aber da kam wieder: Anmeldung fehlgeschlagen.
Kannst Du Dir erklären warum?
Na ja Wirequard wäre ja Blödsinn bei einer pfSense. Siehe dazu:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Das will ich dann mal testen.IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Beim Nextcloud Server freuen wir uns dann auf den nächsten Thread...!
Ja, der kommt bestimmt
Kannst Du Dir erklären warum?
Kann dann nur sein wenn das Telefon keine oder eine falsche DNS Server IP bekommen hat. Wenn du DHCP dort nutzt sollte das immer die pfSense IP sein.Aber egal, wenns mit der IP geht alles so lassen. Never touch a running System
Kannst Du Dir erklären warum?
Kann dann nur sein wenn das Telefon keine oder eine falsche DNS Server IP bekommen hat. Wenn du DHCP dort nutzt sollte das immer die pfSense IP sein.Aber egal, wenns mit der IP geht alles so lassen. Never touch a running System
Ich hoffe nur, die ändern die IP nicht ..
kleiner NACHTRAG:
wenn: > Services > DNS Resolver > General Settings > DNS Query Forwarding
markiert wird, dann muss oben die IP (185.22.44.186) nicht eingetragen werden.
Wenn zusätzlich oben der Haken bei DNS Lookup auf "Ja" gesetzt ist, wird die DNS dg.voip.dg-w.de aufgelöst.
wenn: > Services > DNS Resolver > General Settings > DNS Query Forwarding
markiert wird, dann muss oben die IP (185.22.44.186) nicht eingetragen werden.
Wenn zusätzlich oben der Haken bei DNS Lookup auf "Ja" gesetzt ist, wird die DNS dg.voip.dg-w.de aufgelöst.
