SBC / Tunnel - up/down

[christianv]

Ich teste gerade die selbst gehostete 3cx Version auf einem Cloudserver von Hetzner.
Am Standort habe ich einen SBC, virtualisert, auf einem Proxmox Server laufen.

Ich bekomme andauernd die Meldung das der SBC / Tunnel up and down geht.
Parallel dazu habe ich einen SMB laufen, der aktiv genutzt wird. dessen SBC lauft auf dem selben Proxmox Server. Aber ohne dieses Up/Down Thema.

Info	4102	28.05.2025 06:10	SBC / Tunnel	Trunk SBC 'SBC925128-Büro' (80.187.64.172/192.168.5.120) has changed status to Up
Info	4102	28.05.2025 06:09	SBC / Tunnel	Trunk SBC 'SBC925128-Büro' (80.187.64.172/192.168.5.120) has changed status to Down
Warnung	4102	28.05.2025 04:15	SBC / Tunnel	Trunk SBC 'SBC925128-Büro' (80.187.64.172/192.168.5.120) has changed status to Up
Info	4102	28.05.2025 04:15	SBC / Tunnel	Trunk SBC 'SBC925128-Büro' (80.187.64.172/192.168.5.120) has changed status to Down
Warnung	4102	28.05.2025 04:12	SBC / Tunnel	Trunk SBC 'SBC925128-Büro' (80.187.64.70/192.168.5.120) has changed status to Up
Warnung	4102	28.05.2025 04:11	SBC / Tunnel	Trunk SBC 'SBC925128-Büro' (80.187.64.70/192.168.5.120) has changed status to Down

Der scheint DNS Probleme zu haben, wie gesagt der andere SBC läuft problemlos, gleiche Hardware, gleiche DNS Einstellungen.
Ipv4 und Ipv6 Konnektivität passt. Firewalltest von der PBX läuft ohne fehler durch.

 

[fxbastler]

Der scheint DNS Probleme zu haben,

richtig, so scheint es

 

[mbehrens]

Der scheint DNS Probleme zu haben, wie gesagt der andere SBC läuft problemlos, gleiche Hardware, gleiche DNS Einstellungen.

In der tat.

 

[christianv]

Falls es jemand wissen will, es lag am ipv6 des VPS (Hetzner)

Auf dem System funktionierte IPv6 nicht. Obwohl eine statische IPv6-Adresse konfiguriert war, schlug der Ping ins Internet fehl (Destination unreachable), und der Neighbor Cache zeigte das Gateway als FAILED.

Die Ursache:

Die NFTables-Firewall auf der 3CX-PBX war der Übeltäter. Sie blockierte essenzielle ICMPv6-Nachrichten für das Neighbor Discovery Protocol (NDP). Ohne diese Nachrichten konnte das System die MAC-Adresse des IPv6-Gateways nicht lernen, was die gesamte IPv6-Kommunikation außerhalb des lokalen Hosts verhinderte.

Die Lösung:

Nach dem Hinzufügen spezifischer Regeln für ICMPv6 in der /etc/nftables.conf (insbesondere für nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert sowie echo-request und echo-reply) und dem Neuladen der Firewall (nft -f /etc/nftables.conf) war die IPv6-Konnektivität sofort wiederhergestellt.

# ICMPv6 (Für Neighbor Discovery und Router Advertisements)
ip6 nexthdr icmpv6 icmpv6 type {
    nd-neighbor-solicit,    # Typ 135
    nd-neighbor-advert,     # Typ 136
    nd-router-solicit,         # Typ 133
    nd-router-advert           # Typ 134
} accept comment "Allow essential IPv6 Neighbor Discovery and Router Advertisements"

#IPv6 Ping zulassen
ip6 nexthdr icmpv6 icmpv6 type {
    echo-request,           # Typ 128
    echo-reply              # Typ 129
} accept comment "Allow IPv6 Ping (Echo-Request/Reply)"

Das DNS Problem des SBC hat sich nur auf ipv6 bezogen, deshalb ging es ab und zu, aber halt über ipv4...

Ich hatte das 3cx Image von Hetzner zur Installation benutzt. es war praktisch gar nichts IPV6 konfiguriert.

 

[fxbastler]

https://www.3cx.de/forum/threads/stun-fehler-in-logs.101470/post-339871

 

[christianv]

Dein Betrag bezieht sich auf eine Verbindungslokale (fe80:: ) IPv6. Nein es wurde schon die richtige IPv6 dem Netzwerkadapter zugewiesen und auch bei 3cx angezeigt. IPv6 einfach zu deaktivieren ist imho keine Lösung.
Das Problem war das die Standardeinstellungen der nfttabels Firewall des Offiziellen 3cx Debian Images das NDP von IPv6 verhindern. (ARP wäre das Pendant bei IPv4).
Eventuell ist das Hetzner Cloud Spezifisch.