Fehler im FW-Log Packet Droped

Halo Manfred Werner ,

Vielen Dank, dass Sie sich an die Community gewandt haben. Hat ISP Ihnen einen vollständigen /24-Subnetzpool bereitgestellt? Warum ist das Subnetz /24 ?

Haben Sie eine Masquerading-Regel für Ihre internen Subnetze erstellt?
Warum hat die Regel für VOIP-Dienste JEDE Äußere Regel?

Haben Sie eine DNAT-Regel für VoIP-Dienste erstellt?

Bitte beachten Sie die nützlichen Dokumente unten:

> Sophos UTM9 NAT Method
> https://support.sophos.com/support/s/article/KB-000034249?language=en_US
> https://docs.sophos.com/nsg/sophos-utm/utm/9.706/help/en-us/Content/utm/utmAdminGuide/NetProtNATMasquerading.htm

Halo Manfred Werner ,

Vielen Dank, dass Sie sich an die Community gewandt haben. Hat ISP Ihnen einen vollständigen /24-Subnetzpool bereitgestellt? Warum ist das Subnetz /24 ?

Haben Sie eine Masquerading-Regel für Ihre internen Subnetze erstellt?
Warum hat die Regel für VOIP-Dienste JEDE Äußere Regel?

Haben Sie eine DNAT-Regel für VoIP-Dienste erstellt?

Bitte beachten Sie die nützlichen Dokumente unten:

> Sophos UTM9 NAT Method
> https://support.sophos.com/support/s/article/KB-000034249?language=en_US
> https://docs.sophos.com/nsg/sophos-utm/utm/9.706/help/en-us/Content/utm/utmAdminGuide/NetProtNATMasquerading.htm

Halol Vivek Jagad

Danke für das Feedback,

Ich versuche mal deinen Fragen zu beantworten.

Hier erst mal ein Bild des Aufbaus:

Am ETH 0 schließe ich nur ein Gerät an falls ich die UTM nicht mehr erreichen kann.

Am ETH1 (IP 10.168.178.10 Name External (WAN)) hängt meine Fritzbox (10.168.178.1) welche die Einwahl beim ISP macht und das WLan berreit stellt.

Auf der Fritzbox ist die 10.168.178.10 als expostet Host eingestellt

Der Netzbereich 10.168.178.0/24  ist privat also nicht öffentlich

Auf dem ETH1 ist eine zusätzliche Adresse eingerichtet. 10.10.10.1 (Name Fritz!Box WLan)  auf dieser läuft der DHCP welcher die IP's an die Clients welche sich über das WLan der Fritzbos anmelden verteilt.

Für mich ist jetzt quasi der 10.10.10.1 (Fritz!Box WLan) das Private Subnetzt.

Daher habe ich die Masḱierung wie oben gezeigt eingerichtet.

Wanum die Regel für die Voip Dienste auf Any zeigt? Ich dachte das wäre so richtg

Nein eine DNat Regel habe ich für die Voip Dienste noch nicht erstellt

Wie müsst diese ausssehen wenn der VoipServer die filgenden IP's hat?

185.40.118.10, 91.198.60.180, 78.142.142.139

Basierend auf der aktuellen Topologie haben wir also keinen lokalen VoIP-Server, richtig? Und der einzige Datenverkehr, den wir behandeln werden, ist einfach LAN zu WAN, richtig?

Die Kommunikation wird zwischen den internen Client-IPs zu den genannten VoIP-Servern wie folgt hergestellt: 185.40.118.10, 91.198.60.180, 78.142.142.139

rechts ?

richtig, wir haben keinen lokalen Vopi server nur eine Voip client Software.
richtig Der Datenverkehr ist Lan zu Wan

Was meinst du mit dem letzen Satz ?  mit rechts?

Was ich im letzten Satz meinte, ist, dass die VoIP-Kommunikation zwischen der VoIP-Client-Software zu den folgenden IP-Adressen hergestellt wird - 185.40.118.10, 91.198.60.180, 78.142.142.139
Hab ich recht ?

Ja genau so .. :-)

Und der Kommunikationsport für das VoIP ist UDP 5060 für die Zieldienste richtig?
Haben Sie einen tcpdump auf Ziel-IPs/Port durchgeführt, um zu sehen, ob ein Handshake zwischen dem Softwareclient und dem Server hergestellt wird oder nicht.

Es gibt auch einen Befehl, mit dem wir das UDP-Timeout für die VoIP-Dienste erhöhen können. Standardmäßig ist das UDP-Timeout auf 30 eingestellt. Wir können versuchen, es auf 300 als Standardanforderung für die VoIP-Dienste zu erhöhen.

Ich habe noch keinen tcpdump durchgeführt.
Die Voip telefonie funktuiniert auch, Ich kann ganz Ohne Probleme Telefonieren

Mir sind nur die Einträge im FW-Log aufgefallen:

Hier nochmal ein aktueller Auszug

Das ist doch nicht alles Voip oder ?

Das ist richtig, das ist kein VoIP-Verkehr.

Hast du eine Idee was die Fehler verursachen könnte.

ein grundlegender Fehler von mir ist das sicher möglich

Es ist meine erste Firewall config

Thanks

Manfred

Stellen Sie sicher, dass die Firewall-Regel mit der richtigen Quelle und den richtigen VoIP-Diensten oben ist, und behalten Sie das Ziel bei.

Führen Sie im Backend/Shell-Zugriff den folgenden Befehl aus:

cc get packetfilter timeouts ip_conntrack_udp_timeout

Es gibt Ihnen eine Ausgabe für das aktuelle UDP-Timeout-Set.