Full cone test failed - aber nur auf Port 9000

Matschek

Customer
Mitglied seit
29. Juli 2024
Beiträge
33
Es geht um eine 3CX v20 U4, die als Appliance unter Hyper-V on Prem läuft.
Die Internetverbindung geht über einen Lancom, von dort aus geht der 3CX Traffic an einen Speedport Smart 4 und hier über DSL weiter.
Der Firewall-Test läuft komplett durch - bis auf den Port 9000. Mir ist schleierhaft, warum sich der anders verhält als bei den restlichen 2000 grünen Ports aus dem Bereich 9001-10999. Hat jemand einen Denkanstoß?

003028.png
003027.png
 
Hat jemand einen Denkanstoß?
Suche in dem Gerätepark der der 3CX vorangestellten Router nach dort eingerichteten Regeln und Weiterleitungen, eben u.a. für diese Ports. Da wird es vmtl. etwas geben.

NAT - NAT ist immer schlecht und kein unterstütztes Szenario. Die 3CX v20u4 ist akt. im Alpha Status, d.h. nicht für den produktiven Betrieb empfohlen.

und hier über DSL weiter.
Erkläre mir das bitte: was hat das hinter der Smart 4 mit DSL zu tun?
 
  • Like
Reaktionen: mbehrens und bitn2
Suche in dem Gerätepark der der 3CX vorangestellten Router nach dort eingerichteten Regeln und Weiterleitungen, eben u.a. für diese Ports. Da wird es vmtl. etwas geben.

NAT - NAT ist immer schlecht und kein unterstütztes Szenario.
Glaube mir, ich würde den "Park" aus 2 Geräten gerne mit einem einzigen Lancom ersetzen, aber für den 5G Hybrid Anschluss gibt es einzig den Smart 4. Wenn beide Geräte ordentlich voll NATen und die Port/FW-Regeln konsistent sind, sehe zwar kein Best-Case aber auch kein prinzipielles Problem.

> Die 3CX v20u4 ist akt. im Alpha Status, d.h. nicht für den produktiven Betrieb empfohlen.
Ich bin offen gestanden irritiert, wie ich mir das durch ein simples Drücken auf "Update" eingefangen habe. Das war im Zuge der Fehlersuche, und ich kann noch mal eine U3 drauf ziehen wenn es der Sache hilft. Noch ist das System nicht produktiv.

> Erkläre mir das bitte: was hat das hinter der Smart 4 mit DSL zu tun?
Man kann in dem Hybrid-Router definieren, dass bestimmte Pakete (hier: per DSCP geflaggt) immer über den DSL Kanal rausgehen, und nicht dynamisch auch über 5G gebondet. Das habe ich hier genutzt, der Traffic der 3CX darf nicht über 5G, sondern geht immer über DSL.

Ich habe bisher keine Regel im Speedport oder dem Lancom gefunden, die den 9000er Port besonders behandeln. Überall nur meine 9000-10999 Range.
Ich habe versucht mit einem Mitschnitt zu prüfen wer (Speedport oder Lancom) das Paket verfälscht und scheine das hier nicht richtig lesen zu können: Zeigt dieses Paket, geschnappt vom Lancom auf dem Weg zurück zur 3CX, nicht den korrekten unmodifizierten Port 9000?
 

Anhänge

  • 003031.png
    003031.png
    117,1 KB · Aufrufe: 6
Jetzt wird das Bild etwas deutlicher. Es ist ein Hybrid Anschluß (wg. NAT dahinter, Thema Verständnis In / Out bzw. davor / dahinter) ein Telekom Hybrid Router und dahinter ein Lancom. Eingehend also am Telekom Router und dann NAT auf den Lancom und dann NAT auf die 3CX u.a..

Wenn beide Geräte ordentlich voll NATen und die Port/FW-Regeln konsistent sind, sehe zwar kein Best-Case aber auch kein prinzipielles Problem.
Grundsätzlich richtig. Das habe ich aktuell in einem Testszenario anderswo auch, aber da gibt es eben nur 1x WAN und 2 Router vor der 3CX.

> Die 3CX v20u4 ist akt. im Alpha Status, d.h. nicht für den produktiven Betrieb empfohlen.
Ich bin offen gestanden irritiert, wie ich mir das durch ein simples Drücken auf "Update" eingefangen habe. Das war im Zuge der Fehlersuche, und ich kann noch mal eine U3 drauf ziehen wenn es der Sache hilft. Noch ist das System nicht produktiv.
So lange die 3CX nicht produktiv ist: testen und hier berichten. Dafür sind diese Versionen u.a. gedacht ;)

> Erkläre mir das bitte: was hat das hinter der Smart 4 mit DSL zu tun?
Man kann in dem Hybrid-Router definieren, dass bestimmte Pakete (hier: per DSCP geflaggt) immer über den DSL Kanal rausgehen, und nicht dynamisch auch über 5G gebondet. Das habe ich hier genutzt, der Traffic der 3CX darf nicht über 5G, sondern geht immer über DSL.
Da würde ich mich fragen: Woher kommt das DSCP Flag der Päckchen, bleibt das erhalten am Multi WAN Router und kann dieser nach diesem Kriterium verlässlich und für die 3CX duchgehend routen? Lässt sich das nicht anders durchreichen? RTP Port Nutzung läuft nach SIP und Verhandlung.

In einem ähnlichen (nur zeitweilig benutztem) Szenario haben wir die 3CX hinter den Hybrid Router und neben die FW (bei dir Lancom) gestellt und im Hybrid Router die IP der 3CX durchgehend auf den DSL laufen lassen. Split DNS liess sich so auch handhaben: lief durch die FW. Hat alles funktioniert. War suboptimal. Wurde inzwischen besser angebunden und das Szenario gibt es nicht mehr.

Ich habe bisher keine Regel im Speedport oder dem Lancom gefunden, die den 9000er Port besonders behandeln. Überall nur meine 9000-10999 Range.
Ich habe vorhin kurz quer gesucht und auch nicht spezielles über eine anderweitige fest verplante Nutzung des 9000 UDP gefunden. Das heißt nicht, dass es das nicht gibt.

Ich habe versucht mit einem Mitschnitt zu prüfen wer (Speedport oder Lancom) das Paket verfälscht und scheine das hier nicht richtig lesen zu können: Zeigt dieses Paket, geschnappt vom Lancom auf dem Weg zurück zur 3CX, nicht den korrekten unmodifizierten Port 9000?
keine Ahnung, kann ich nicht beurteilen, s.o., wird verhandelt
 
So lange die 3CX nicht produktiv ist: testen und hier berichten. Dafür sind diese Versionen u.a. gedacht ;)
Mit Backup von der U3 getestet, gleiches Verhalten. (Dort konnte ich auch noch mal einen Blick in die Update-Sektion werfen: In der ersten Spalte steht weiterhin deutlich "Alpha". Ich habe wohl nur das "Release" hinter dem Versionstext gelesen und gedacht die Alpha sei zum Release geworden)

Woher kommt das DSCP Flag der Päckchen, bleibt das erhalten am Multi WAN Router [...]
Das Flag drückt der Lancom auf, und lt. Mitschnitt klappt das auch. Der Speedport entscheidet damit nur über den DSL-Weg zu gehen, für nichts sonst ist es ab dieser Stelle gut. Ich glaube nicht, dass die Telekom meinen Wunsch nach AF21 im weiteren Netz berücksichtigt, tut hier aber nichts zur Sache. Auch, dass die zurückkommenden Pakete erst mal keinen DSCP mehr haben ist hier Wurscht.

keine Ahnung, kann ich nicht beurteilen, s.o., wird verhandelt
Bin mir mittlerweile recht sicher, dass das Paket so in Ordnung ist, und wir nicht von einer Port-Änderung sprechen. Da habe ich mich von den Beschreibungen in den Hilfetexten etwas fehlleiten lassen. Verfälschte Ports werden wohl explizit benannt. Nach Vergleich von den Paketen zu Test Port 9000 (fail) und 9002 (ok) bin ich nun der Auffassung, dass bei Port 9000 das zweite Antwortpaket nicht zurückkommt. Test 1 ist ja mit den Flags "no not change IP/Port", Test 2 mit dem Gegenteil. Test 1 klappt noch, aber bei Test 2 kommt nix mehr zurück.
Damit hab ich es zwar technisch etwas präziser vorliegen, neue Ursachen sind mir aber immer noch nicht eingefallen. Hab auch schon das Post-Forwarding bei 8999 beginnen lassen um einen Bug im Speedport mit dem ersten gezählten Port auszuschließen, aber auch das ergibt keine Änderung.
 

Anhänge

  • 3cx.png
    3cx.png
    73,6 KB · Aufrufe: 1
Das Flag drückt der Lancom auf, und lt. Mitschnitt klappt das auch. Der Speedport entscheidet damit nur über den DSL-Weg zu gehen, für nichts sonst ist es ab dieser Stelle gut.
i.O., wir haben das damals per IP lösen müssen.
Ich glaube nicht, dass die Telekom meinen Wunsch nach AF21 im weiteren Netz berücksichtigt, ...
:)
Auch, dass die zurückkommenden Pakete erst mal keinen DSCP mehr haben ist hier Wurscht.
richtig, das interessiert dich vmtl. nicht mehr
Bin mir mittlerweile recht sicher, dass das Paket so in Ordnung ist, und wir nicht von einer Port-Änderung sprechen. Da habe ich mich von den Beschreibungen in den Hilfetexten etwas fehlleiten lassen. Verfälschte Ports werden wohl explizit benannt. Nach Vergleich von den Paketen zu Test Port 9000 (fail) und 9002 (ok) bin ich nun der Auffassung, dass bei Port 9000 das zweite Antwortpaket nicht zurückkommt. Test 1 ist ja mit den Flags "no not change IP/Port", Test 2 mit dem Gegenteil. Test 1 klappt noch, aber bei Test 2 kommt nix mehr zurück.
Damit hab ich es zwar technisch etwas präziser vorliegen, neue Ursachen sind mir aber immer noch nicht eingefallen. Hab auch schon das Post-Forwarding bei 8999 beginnen lassen um einen Bug im Speedport mit dem ersten gezählten Port auszuschließen, aber auch das ergibt keine Änderung.
Das Problem wird hier evtl. nicht gelöst werden können.

Interessehalber könnte man folgendes testen: Da die Anlage noch nicht produktiv ist, könnte man die UDP Port Range für RTP und WebRTC ändern. Such mal in den Parametern nach dem Wort Port, ändere die Angaben und pass auf dass es keine Überlappungen gibt. Dann noch die 3CX nftables Firewall anpassen und neu starten. Eventuell reicht das, habe ich seit langem nicht mehr getestet. Sonst: Backup Restore ...
 
  • Like
Reaktionen: Matschek
Interessehalber könnte man folgendes testen: Da die Anlage noch nicht produktiv ist, könnte man die UDP Port Range für RTP und WebRTC ändern.
Danke, gute Idee!
Wenn ich bei 9002 beginnen lasse, wird plötzlich 9002 rot und der Rest OK. Wenn ich auf 9010 gehe, ist alles grün. Logik? Ne. Klingt nach einem echt schrägen Bug im Speedport...
Mit der kleineren Portrange kann ich bei der Anlage leben, mehr als 20 Nebenstellen werden das nicht.
Muss ich dann an WebRTC und nftables überhaupt ran? Habe ja nur den Bereich etwas verkleinert, keine Range verschoben und keine neue Range geschaffen.
 
Dann herzlichen Dank fxbastler ! :-)
 
  • Like
Reaktionen: fxbastler
Ergänzung: Nach einigen weiteren Tests komme ich zum Ergebnis, dass der Speedport Bug leider nicht so greifbar ist wie oben beschrieben. Wenn er Antwort-Pakete beim Firewall-Check verwirft, dann beim ersten Port der RTC Range, aber es passiert nicht immer. Ich könnte auch mir vorstellen, dass das irgendein IDS Ding ist was im Speedport anschlägt. Ich muss jetzt einfach hoffen, dass während der Test- und Umstellungsphase es hier kein Problem in der Praxis gibt, und am Ende kommt die 3CX an eine separate DSL Line ohne den Speedport.
 
und am Ende kommt die 3CX an eine separate DSL Line ohne den Speedport.
Richtig: den DSL Anschluss per Modem als 2. WAN am Router (des LAN, bei dir Lancom) anbinden, mit passenden Regeln alles von der 3CX darüber laufen lassen und den Rest nur wenn WAN 1 (LTE) doch mal offline ist. Dann ist der Hybrid Router eben nur noch für LTE da.

Müsste ich aktuell so ein Hybrid Szenario umsetzen, dann würde ich das mit einer pfSense als Router umsetzen und DSL und LTE wie o.b. als Multi WAN anbinden. Uns kommt so schnell kein Lancom mehr vor eine 3CX.
 
  • Like
Reaktionen: bitn2
Ja, so ähnlich ist tatsächlich auch die Ausgangskonfiguration. Den später frei werdenden zweiten DSL, an dem zzt. noch der alte Mediaconverter hängt, hatte ich zur Vereinfachung hier in der Beschreibung weggelassen.

Hast Du Stichworte oder Foren-Links zu Deinen Lancom Fails im Kontext von 3CX? Bisher komme mit den Dingern ganz gut zurecht.
 
Nur mein Senf:

Ich habe sogar noch Anleitungen hinterher für deren Geräte hier geschrieben und anderen geholfen. Aber wir setzen sie dafür nicht mehr ein. Es gibt auch noch genug Beiträge anderer zu diesem Thema hier im Forum.
 
  • Like
Reaktionen: mbehrens und Matschek
Ich hatte Anfang diesen Jahres noch so ein unschönes Erlebnis, wo sich in einer Bürogemeinschaft mehr. Firmen einen Internetzugang mit einem Lancom Router (und aktivierter und genutzter All-IP Option) teilen. Gründe für sein Vorhandensein sind eine Site2Site Verbindung zu einer fremden (nicht von uns administrierten) Gegenstelle welche ebenfalls einen Lancom Router einsetzt (und nicht gewillt ist diese EOL Geräte zu wechseln) und die ALL-IP Option des Lancom damit eine alte ISDN Anlage dahinter noch betrieben werden kann. Den Lancom haben sogar wir selber vor ganz vielen Jahren dort eingebaut inkl. späterer Umrüstung auf ALL-IP.
Es war mir schon zu Testzwecken nicht möglich sauber einen Easybell bzw. DTS SIP Trunk dort irgendwo irgendwie für eine geplante Telefonieumstellung einer der Firmen in Betrieb zu nehmen ohne den Lancom auszuwechseln. Egal was ich gemacht habe, irgend etwas ging immer nicht. Wir haben es dann erstmal sein lassen. Wenn es nach uns geht fliegt der raus und wir stellen um auf eine Gemeinschaftsanlage aller Firmen (mit 3CX). Die Erkenntnis bei denen ist halt noch nicht da. Bin gespannt wann die alte ISDN Anlage abraucht.
 

Statistik des Forums

Themen
44.413
Beiträge
232.713
Mitglieder
78.328
Neuestes Mitglied
as7h