Firewall Checker: „Full Cone Test failed“, obwohl die STUN-Probes nachweislich bei der PBX ankommen

[m.morath]

Hallo zusammen,


der Firewall Checker meldet bei mir „Full Cone Test failed“. Ich habe das Problem Schritt für Schritt eingegrenzt. Soweit ich es beurteilen kann, liegt die Ursache nicht an der Firewall, sondern in der PBX bzw. im Checker selbst. Vielleicht kann jemand von 3CX mitlesen und das einordnen.


Umgebung

• 3CX als VM auf Proxmox VE, virtio-NIC (Version 20.0 Update 9 (Build 995 Release - AI 1.4.48))
• Firewall: OPNsense 26.7.1, ebenfalls als VM auf demselben Host
• Die PBX hat eine eigene öffentliche IP
• RTP-Portbereich: 20000–50000 UDP
• Alle SIP-Trunks sind registriert, Telefonie funktioniert einwandfrei

Konfiguration

• Source-NAT: 3CX → öffenltiche IP mit Static Port, Quellports bleiben also 1:1 erhalten
• Policy Routing: Ausgehender Verkehr der PBX läuft über deren eigene öffentliche IP
• Portweiterleitungen auf die PBX mit unveränderten Ports: 5060 UDP/TCP, 5061 TCP, 5090 UDP/TCP, 443 TCP, 20000–50000 UDP/TCP, dazu passende Allow-Regeln

Ergebnis des Checkers

• Die Port-Mapping-Tests sind bestanden, es gibt keine „Mapping does not match“-Meldungen mehr.
• Der Full-Cone-Test schlägt fehl.

Was ich per tcpdump nachvollzogen habe

1. Die Probes kommen an der öffentlichen IP an. Ein zweiter STUN-Server schickt während des Tests Pakete an die zuvor gemappten Ports. Beobachtet habe ich 34.159.93.50:3479 und in einem anderen Lauf 34.73.139.160:3479.

34.159.93.50.3479 > öffentliche IP.20012: UDP, length 68
34.159.93.50.3479 > öffentliche IP.20002: UDP, length 68
...

1. Die Firewall leitet sie korrekt an die PBX weiter, und zwar mit unverändertem Port:

34.159.93.50.3479 > 3CX-VM.20012: UDP, length 68
34.159.93.50.3479 > 3CX-VM.20002: UDP, length 68

In der State-Tabelle der Firewall ist die Rückrichtung durchgehend NO_TRAFFIC.

1. Die Probes erreichen die Netzwerkkarte der PBX-VM intakt. Das habe ich auf dem Proxmox-Host direkt am tap-Interface der VM mitgeschnitten: Die Ziel-MAC ist die der PBX, alle Pakete haben udp sum ok, Probes auf 5060, 5090 und 20000–20298 kommen an.

34.159.93.50.3479 > 3CX-VM.20006: [udp sum ok] UDP, length 68
34.159.93.50.3479 > 3CX-VM.5090: [udp sum ok] UDP, length 68

1. Zum Vergleich: Normaler eingehender Tunnel-Verkehr auf 5090 läuft über denselben Weg. Er hat dieselbe Quell- und Ziel-MAC, gültige Prüfsummen und wird von der PBX beantwortet. Auf Layer 2 bis 4 unterscheiden sich die Full-Cone-Probes davon nicht.
2. Die PBX antwortet auf keine einzige Probe. Der STUN-Server wiederholt jede Anfrage dreimal im Abstand von etwa einer Sekunde und macht dann mit den nächsten Ports weiter.

Fazit


Die Pakete liegen nachweislich korrekt an der Netzwerkkarte der PBX an. Firewall und Hypervisor kann ich damit als Ursache ausschließen. Die PBX-VM wird von 3CX verwaltet, dort habe ich nichts verändert.


Meine Fragen

1. Gibt es auf der PBX einen lokalen Paketfilter (nftables/iptables), der unaufgeforderte UDP-Pakete von neuen Absendern im RTP-Bereich verwirft?
2. Erwartet der Checker die Full-Cone-Probes auf einem anderen Socket oder zu einem anderen Zeitpunkt?
3. Ist das Full-Cone-Ergebnis für den Betrieb relevant, wenn Trunks registriert sind und Telefonie funktioniert, oder ist es rein informativ?

Vollständige Mitschnitte und die Regelauszüge kann ich bei Bedarf gerne per PN an einen 3CX-Mitarbeiter schicken.

 

[avraammich_3CX]

Hi @m.morath,

schau dir folgende Anleitung an:

Why the Firewall Checker Does Not Lie

Firewall & Router Configuration

Configure your firewall router to use remote extensions or a VoIP Provider succesfully. Read our guide to find out.

www.3cx.com

 

[m.morath]

Danke für den Link, die Punkte dort habe ich alle geprüft. Portweiterleitungen und Static Port sind eingerichtet, Test 1 besteht, ein SIP ALG ist nicht aktiv. Wie im Beitrag beschrieben, kommen die Full-Cone-Probes nachweislich unverändert an der Netzwerkkarte der PBX an, die PBX antwortet aber nicht.


Dabei ist mir aufgefallen: Die Probes kommen von 34.159.93.50:3479 bzw. 34.73.139.160:3479. Keine der beiden Adressen steht in der Liste der STUN-Server-IPs in der Doku (34.40.60.101, 34.40.164.62, 34.83.212.229, 34.138.123.132). Filtert die PBX eingehende STUN-Antworten womöglich anhand dieser Liste, oder ist die Doku an dieser Stelle veraltet?

 

[Josef L]

es wäre übersichtlicher gewesen, wenn du ein Screenshot über deine Firewall Einstellung gepostet hättest

RTP-Portbereich: 20000–50000 UDP

ich denke das dieser falsch ist, der müsste von 9000 bis 10999 behinhalten @avraammich_3CX hat dir ja den Link gesendet,
und hier ist die deutschsprachige Seite: https://www.3cx.de/docs/adminhandbuch/firewall-router-konfiguration/

 

[avraammich_3CX]

Dabei ist mir aufgefallen: Die Probes kommen von 34.159.93.50:3479 bzw. 34.73.139.160:3479. Keine der beiden Adressen steht in der Liste der STUN-Server-IPs in der Doku (34.40.60.101, 34.40.164.62, 34.83.212.229, 34.138.123.132). Filtert die PBX eingehende STUN-Antworten womöglich anhand dieser Liste, oder ist die Doku an dieser Stelle veraltet?

Unter Admin Ansicht->Erweitert->Netzwerk welche Stun Server sind hinterlegt?

 

[m.morath]

Vielen Dank für den Hinweis. Ich habe die Port-Range zurückgesetzt. Wir haben easybell als Provider. Dort wird 20000 bis 50000 erwartet. Das hat auch tadellos funktioniert. Also kein One-Way-Audio. Nur der Firewall-Checker kam damit nicht klar.
Wie bereits in einem anderen Thread erwähnt, erwartet 3CX offenbar 9000 - 10999 eingehend und easybell 20000-50000 ausgehend. Wenn man static-port im Outbound-NAT konfiguriert, könnte das mal zum Problem werden, oder?
Bisher scheint es auch so zu funktionieren. Der Firewall-Checker ist jetzt erfolgreich durchgelaufen. Bidirektionales Audio funktioniert auch. Ich bin mir nur nicht sicher, ob die Konfiguration unter den gegebenen Umständen vonseiten easybell so passt.

 

[m.morath]

Unter Admin Ansicht->Erweitert->Netzwerk welche Stun Server sind hinterlegt?

Die STUN-Funktion ist nicht aktiv. Ich verwende eine statische IP.

 

[fxbastler]

@m.morath
Ich weiß nicht wo dein Problem liegt, aber ich kann dir aus der gelebten Praxis heraus versichern: das Full Cone Problem wird nicht in der 3CX erzeugt.

Wir betreiben beinahe alle bei unseren Kunden und uns selber eingesetzten 3CX hinter einer pfSense. Einige der 3CX sind auf einem Proxmox VE virtualisiert, teilweise gar mehrere nebeneinander. Das funktioniert seit über 10 Jahren gut.

Vorausgesetzt die wenigen beschriebenen Schritte in der Firewall werden richtig eingestellt (Firewall / NAT / Outbound für die 3CX mit Static Port, System / Advanced / Firewall & NAT / Firewall Optimization Options auf Conservative und dann noch die div. NAT Portweiterleitungen), dann läuft auch der 3CX Firewall Test erfolgreich durch.

Wenn man static-port im Outbound-NAT konfiguriert, könnte das mal zum Problem werden, oder?

wenn es richtig eingerichtet ist: nein

 

[m.morath]

@m.morath
Ich weiß nicht wo dein Problem liegt, aber ich kann dir aus der gelebten Praxis heraus versichern: das Full Cone Problem wird nicht in der 3CX erzeugt.

Ich hab eigentlich kein Problem. ;-) Bei mir läuft die Anlage ja auch schon lange und problemlos. Ich bin heute eher zufällig über den Firewall-Test gestolpert.
Als damals auf easybell umgestellt wurde, wurde die Port-Range von 9000-10999 auf 20000-50000 umgestellt. Offenbar damals ohne Probleme. Bisher lief das Setup problemlos.

Jetzt erfolgte auf der OPNsense ein Update auf die Version 26.7.1. Das brachte ein Portmapping-Problem mit sich, das wiederum eine neue Regel in der Firewall erforderlich machte. Das Portmapping-Problem war dann gelöst, aber der full-cone-Test scheiterte. Der ist jetzt - durch die Rückstellung von 20000-50000 auf 9000-10999 gelöst.
Mir ist nur nicht klar, ob die unterschiedlichen Portbereiche irgendwann mal zum Problem werden.

In der easybell-Info (https://www.easybell.de/hilfe/telefon-konfiguration/allgemein/voip-experteneinstellungen/) wird 20000-50000 für Rufnummern angegeben. Das liegt nicht im Portbereich der 3CX-Anlage (9000-10999). Wobei zu unterschieden ist, dass 9000-10999 in der Firewall eingehend ist und 20000-50000 ausgehend sein soll. Bei einer Static-Port-Einstellung wird der Ausgang jedoch auf dem Port ausgegeben, auf dem er eingeht. Kommt also ein Signal auf 10345 an, wird es auch auf 10345 ausgegeben - das entspricht nicht der Vorgabe von easybell.

 

[fxbastler]

Mir ist nur nicht klar, ob die unterschiedlichen Portbereiche irgendwann mal zum Problem werden.

nein:

1. das ist Verhandlungssache
2. ist das ein Unterschied weil:
   1. ausgehend zum Provider (20000-50000 wird mit dem verhandelt), muss halt funktionieren
   2. eingehend zur 3CX von irgendwelchen derere eigenen Clients (9000-10999 legt die 3CX beim Verbindungsaufbau fest), diese NAT Weiterleitung ist an sich entbehrlich

Merke:
Wenn du schon den 3CX SIP Port weiterleitest, dann beschränke das auf den IP Adressbereich des VOIP Providers (wenn überhaupt, bei Nicht-IP-VOIP-Anschlüssen unnötig) und ggf. noch auf die wenigen IP die 3CX für den Firewall Checker verwendet.

 

[m.morath]

OK, vielen Dank für die Aufklärung. Dann sollte das Setup so störungsfrei arbeiten.