Agfeo-TK-Anlage hinter pfsense
-
Schönen guten Tag,
bei uns wurde heute die Telefonie von Telekom (lief über eine Fritzbox) auf GVG-Glasfaser umgestellt. Nun möchte ich die Telefonanlage mit dem Glasfasernetz hinter meiner pfSense betreiben. Anrufe gehen auch raus, aber die Teilnehmer können sich nicht hören und eingehende Anrufe funktionieren leider gar nicht.
Ich habe mir den folgenden Artikel angesehen (https://forum.netgate.com/topic/106986/howto-telekom-voip-einstellungen)
und daraus die folgende NAT-Regel abgeleitet:Außerdem habe ich in der Firewall unter WAN die folgende Regel:
und unter dem Netz der TK-Anlage folgende Regel:
Abschließend sind hier meine Aliase zu Ports und IPs:
Hab ihr eine Idee, wie ich dieses Problem lösen kann, bzw. wo bei mir in der Konfiguration der Fehler liegt?
-
@oktech said in Agfeo-TK-Anlage hinter pfsense:
Anrufe gehen auch raus, aber die Teilnehmer können sich nicht hören und eingehende Anrufe funktionieren leider gar nicht.
Kleines Update hierzu:
Ausgehende Anrufe verhalten sich immer noch, wie oben beschrieben.
Bei eingehenden Anrufen erhalte ich, wenn ein Teilnehmer ran geht die Ansage, dass die Rufnummer nicht vergeben ist. -
Hallo,
gibt es auch einen Eintrag unter Firewall / NAT / Port Forward?
So sieht das bei mir aus:
-
@root32 Der Eintrag fehlte mir noch.
Welche Ports sind in deinem Alias VoIP_ports zu finden? -
@oktech bei dir heißt der Alias Telefonie_UDP
Die RTP Ports, weiß grad nicht welche, und der SIP Port 5060. -
@root32 Ist der Port Forward bei dir eine Linked Rule oder ein Pass?
Leider scheint es noch immer nicht zu funktionieren.
Hast du bei dir NAT oder nur den Port Forward eingerichtet?
Was mich am meisten wundert ist, sobald ich das Gespräach auf einem der Telefone annehme, auf meinem Handy die folgende Ansage kommt:
"Die gewählte Nummer ist nicht vergeben" -
@oktech Pass, die Regel bestehen schon, so wie bei dir.
Über SIP Port 5060 bzw. SIPS Port 5061 meldet sich die Telefonanlage beim Provider an. Wenn das nicht funktioniert, dann bekommt man deine Ansage.
Steht irgendwas in der Firwall logs?Wenn der SIP Server nicht als IP hinterlegt ist:
Die DNS Auflösung des SIP-Servernamen vom Provider funktioniert für die Telefonanlage? -
@root32 Das SIP-Konto ist angemeldet:
Und die Firewall Logs sehen auch ganz gut aus:
Aber weiterhin habe ich das selbe Fehlerbild.
-
@oktech Ist ein STUN Server in Verwendung? Den mal testweise rausnehmen.
Ansonsten mal mitscheiden was über das SIP Protokoll gesprochen wird. -
@oktech Die eingehenden Firewallregeln sind falsch. Regeln alleine bringen dir nichts, du nimmst da einfach (sinnfrei) die VoIP Ports auf der Firewall(!) an weil du nur die IP eingehend erlaubt hast. Das bringt aber nichts, denn die Firewall kann mit den Ports nichts anfangen. Darum wird wohl auch eingehend nichts gehen.
Du musst wie @root32 das gemacht hat entsprechende Port Forwards erstellen und deine VoIP Ports jeweils UDP und TCP (zwei getrennte Forwards) auf der WAN IP annehmen und zur VoIP Anlange durchreichen.
Wenn du die Regeln drin hast, bitte nochmal NAT und Regeln posten :)
Ansonsten ist es ganz oft recht angenehm, mal einen TCPDump zu machen auf dem WAN und dann mal von außen anzurufen. Dann sieht man eigentlich, was in dem Moment reinkommt und ob es angenommen wird bzw. ob es geblockt wird (wenn man die Firewallregeln dazu anschaut).
Außerdem die Regeln die erstellt werden durch die Port Forwards nochmal editieren und das Logging einschalten, damit man sie im Log sieht und weiß ob sie getriggert werden oder nicht.
@root32 said in Agfeo-TK-Anlage hinter pfsense:
@oktech Ist ein STUN Server in Verwendung? Den mal testweise rausnehmen.
Zumindest sieht man States zu udp/3478 was klassischerweise der STUN Server Port ist, daher würde ich vermuten ja.
Cheers
\jens -
@jegr @root32 Erst einmal vielen Dank für eure Unterstützung.
Nachfolgende habe ich die NAT-Regeln und Firewall-Regeln noch einmal angepasst:
PortForward:
NAT Outbound:
Firewall-Regel WAN:
Bei meinem Test-Anruf bekomme ich in den Packet-Capture folgende Fehlermeldung:
Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION"Ich denke irgendwo ist in meinen Regeln noch ein Denkfehler auf meiner Seite und ich sehe den Wald vor lauter Bäumen einfach nicht.
-
@oktech NAT -> Outbound
Die Destination Ports würde ich mal entfernen.
Der STUN ist deaktiviert? -
Hi,
nach meiner Anleitung 'Fritze hinter pfSense' ist nur wichtig, dass im Mapping die ports auf static stehen.
Sollte bei der Agfeo auch so sein.
Ein eigehender Portforward ist nicht noetig, bzw macht eher Probleme.
In der Sense sollten die UDP NAT Timeouts vieleicht noch eingestellt werden.
Eine wichtigere Frage ist: Wer ist der Voip Provider und was hat der fuer Besonderheiten?HTH
LG
CAT
-
@root32 Habe ich so umgesetzt und auch STUN ist deaktivert. Leider ohne Erfolg.
-
@cat1510 Ich habe die Portweiterleitung einmal deaktiviert. Leider keine Veränderung.
Der Voip-Anbieter kann mir leider keine Besonderheiten nennen.Ich habe gerade auf einem der User-PCs Phoner installiert und mich mit den Zugangsdaten eingewählt.
Damit hat die Telefonie ohne Probleme funktioniert. Sowohl eingehend als auch ausgehend. -
@cat1510 said in Agfeo-TK-Anlage hinter pfsense:
Eine wichtigere Frage ist: Wer ist der Voip Provider und was hat der fuer Besonderheiten?
?
Diese beiden habe ich noch fuer Dich gefunden, aber die wirst Du schon gecheckt haben:
https://administrator.de/forum/voip-hinter-pfsense-ohne-portfreigaben-und-auch-ohne-stun-und-sip-alg-541698.html
https://www.joerg-leuschner.de/sicherheit/agfeo-elements-am-all-ip-anschluss-hinter-einer-firewall/Ist aber ueberall auch das Gleiche beschrieben.
Bleibt noch die Frage nach dem Voip Provider.
Wir hatten auch mal den Fall, dass die Random ports vom RTP auf der Firwall zumindest zugelassen werden mussten. Haben wir dann aber nur von den IPs des Provider zugelassen, logisch.CAT
-
@cat1510 Der Anschluss läuft über GVG-Glasfaser.
Die IP, die ich über Wireshark herausbekomme gehört anscheinend Purtel.
Eine Suche im Zusammenhang mit meiner Agfeo ES516 hat leider auch keine Lösung hervorgebracht.Für mich sieht es nach einem Problem zwischen dem Provider und der TK-Anlage aus, gerade weil ein Softphone ohne Anbindung an die Telefonanlage mit den Zugangsdaten einwandfrei funktioniert.
Hier einmal die Ansicht des Packets:
Frame 10: 684 bytes on wire (5472 bits), 684 bytes captured (5472 bits) Null/Loopback Internet Protocol Version 4, Src: 185.39.85.42, Dst: <wanip> User Datagram Protocol, Src Port: 5060, Dst Port: 6878 Session Initiation Protocol (BYE) Request-Line: BYE sip:453688@<wanip>:6878 SIP/2.0 Message Header Via: SIP/2.0/UDP 185.39.85.42;branch=z9hG4bK7263.709c6da2d8d5c6ec77700753e97e7419.0 Via: SIP/2.0/UDP 185.39.85.42:5072;received=185.39.85.42;rport=5072;branch=z9hG4bKNvZB8QBmFX6tD Max-Forwards: 69 From: <sip:telefonnummer@sip.gvg-glasfaser.de>;tag=y7m36XD1HU37a To: <sip:telefonnummer@<wanip>:6878>;tag=123fd73b Call-ID: e7ee4526-8e6e-123a-32ad-b6253dec2fb7 [Generated Call-ID: e7ee4526-8e6e-123a-32ad-b6253dec2fb7] CSeq: 41172594 BYE User-Agent: FreeSWITCH Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, NOTIFY Supported: timer, path, replaces Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION" Content-Length: 0
-
Ja, dann scheint die Agfeo aber nicht ‘richtig’ eingestellt zu sein oder der fehlt was anderes.
Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION"
https://www.tek-tips.com/viewthread.cfm?qid=1768690
https://community.cisco.com/t5/atas-gateways-and-accessories/incoming-sip-calls-on-spa3102-disconnecting/m-p/3004065#M8302Was macht der Phoner anders als die Agfeo?
Vielleicht mal wireshark mit phoner um zu sehen was der setzt…
Nur so als Idee.CAT
-
https://telekomhilft.telekom.de/t5/Telefonie-Internet/VOIP-SIP-606-Fehler/td-p/2846378
Hier auch ein Codec Fehler.
Was handelt der Phoner denn aus?
Ist der Codec auch bei der Agfeo eingestellt? -
@cat1510 Ich habe gerade bei Phoner und bei der Agfeo die selben Codecs verwendet und bekomme leider immer noch kein Gespräch mit der Agfeo zu Stande.
Folgenden Eintrag bekomme ich bei Phoner, welcher mich etwas stutzig macht:
Record-Route URI: sip:185.39.85.42;lr=on;nat=yesIch habe keine Einstellungen für Phone vorgenommen. Also kein NAT oder ähnliches.
Für die Agfeo sieht der Eintrag wie folgt aus:
Record-Route URI: sip:185.39.85.42;lr=on