Probleme mit IPTV / WIFI Telefonie

[eric1905]

Hallo zusammen,

ich bin "relativ" neu bei OPNsense. Ich nutze es zwar schon eine Weile und es funktioniert großteils, allerdings scheint es noch an manchen Stellen zu "drücken". Dies macht sich dadurch bemerkbar, dass vor allem IPTV und Telefonie über WLAN nicht gut funktionieren und der Stream oft aussetzt und meine Gesprächspartner nur abgehackt zu verstehen sind.

Auch hakt es manchmal beim Casten von Spotify auf meinen Smartspeakern. Das hat mal besser geklappt, allerdings ist mir meine Festplatte in der OPNSense abgeraucht und ich durfte alles nochmal aufsetzen, da ich kein Backup hatte.

Kurz zu meinem Setup:
Ich habe folgende Interfaces definiert

[LAN]                          192.168.1.1 /24 lan   igc0
[SmartHome]           192.168.2.1 /24 opt3  vlan02
[Privat]                      192.168.3.1 /24 opt1  vlan03
[Management]      192.168.10.1/24 opt2  vlan010
[Gast]                        192.168.20.1/24 opt4  vlan020
[WAN]           pppoe0 igc1


Die Geräte die IPTV und WIFI Telefonie nutzen sind in den VLAN Privat und SmartHome.

Die Rules meiner VLANs sehen wie folgt aus:
LAN:

You cannot view this attachment.

Management:
You cannot view this attachment.

Gast:


Privat:


SmartHome:


Damit Spotify und Sonos / Google Home über mehrere VLAN funktioniert habe ich folgende Plugins noch installiert:
os-mdns-repeater (installed)
os-udpbroadcastrelay (installed)

Ich habe gelesen, dass man Upstream und Downstream begrenzen soll für besseres IPTV, allerdings hat das auch nicht viel geholfen. Dafür habe ich unter Firewall - Shaper folgendes angelegt:

Pipes:

Bandwidth   
180 Mbit/s Downstream FQCoDel
38 Mbit/s  Upstream FQCoDel

Queues für beides mit Weight 100

Rules:
Sequence 1 Download Queue
Sequence 2 Upload Queue

Generell zu meinem Setup:
Ich habe an meiner OPNSense einen TP-Link tp-SG108E hängen. An diesem hängen an den Ports 7 und 8 noch ein tp-SG108E bzw. tp-SG108PE, an dem 3 Unifi Accesspoints hängen.


Was muss ich noch tun, damit ich vollends zufrieden bin?
Kann ich noch weitere Einstellungen teilen?

Vielen Dank schon mal im Voraus.

[Zapad]

hatte mal das Problem mit Streaming Abbrüchen.

eingehandelt mit shaper, gelöst mit Shaper weg..... (Shaper war mal wegen Gaming Latenzen eingeführt)

habe z.Z Kabel Internet mit 400/20, also nicht das Beste.

Wie sehen deine Livelogs aus, viele "Default denys"? wenn ja weswegen? DF Flags!?

man kann in den Regeln besonders bei TCP zb. "Jegliche Flags" einstellen was mmn. viele "Fehler" eliminiert und Sloppy State bei Zustandstyp.

aber aufs Ausprobieren kommt es an.

Einstellen und Testen.... testen.... testen....

[eric1905]

hatte mal das Problem mit Streaming Abbrüchen.

eingehandelt mit shaper, gelöst mit Shaper weg..... (Shaper war mal wegen Gaming Latenzen eingeführt)

habe z.Z Kabel Internet mit 400/20, also nicht das Beste.

Wie sehen deine Livelogs aus, viele "Default denys"? wenn ja weswegen? DF Flags!?

man kann in den Regeln besonders bei TCP zb. "Jegliche Flags" einstellen was mmn. viele "Fehler" eliminiert und Sloppy State bei Zustandstyp.

aber aufs Ausprobieren kommt es an.

Einstellen und Testen.... testen.... testen....

Den Shaper habe ich ja nur eingebaut, weil ich ja vorher schon Probleme mit der Verbindung habe, also sollte das eher nicht der Auslöser sein.

Ich habe ca 10 deny pro Minute.
Hauptsächlich: block all targeting port 0 und Default deny / state violation rule.

Wo sehe ich das mit den DF Flags?

[Zapad]

DF Flags sind Packete mit "Dont fragment" option, das siehst du wenn du einen Eintag anklickst direkt unter Interface Eintrag.


Das ist nur ein hinweis unter Andreren, das was nicht stimmt...


Leider hast du nicht angegeben wie die Vans angebunden sind, es ist öfters "Asymmetric Routing" die ursache für das Problem.

[fastboot]

Hallo,

ein paar grundsätzliche Hinweise, die aus meiner Sicht unabhängig von einzelnen Optionen oder Plugins wichtig sind.

Der zentrale Punkt ist das Grundverständnis des Firewall-Konzepts von OPNsense. Regeln sind strikt interfacebezogen und ingress-basiert. Das bedeutet: Regeln unter Firewall → Rules → LAN wirken ausschließlich auf Traffic, der vom LAN in die Firewall hinein kommt. Pakete aus anderen Netzen können dort technisch nicht matchen. Entsprechende Regeln haben daher keine Wirkung.

Zusätzlich fallen auf mehreren Interfaces sehr früh platzierte any -> any-Regeln auf. Da pf nach dem Prinzip first match wins arbeitet, machen diese Regeln sämtliches nachgelagertes Filtering wirkungslos. Feinere Regeln für VLAN-Übergänge oder Multicast greifen in diesem Fall praktisch nicht mehr. Die VLAN-Trennung existiert damit nur noch logisch, nicht aber durch eine wirksame Policy.

Ein weiterer Punkt ist die Behandlung von Multicast. Sehr offene Firewall-Regeln werden mit mDNS-Repeater und UDP-Broadcast-Relay kombiniert. Das erschwert die Nachvollziehbarkeit und führt häufig zu unnötigem Multicast-Traffic. Gerade WLAN-Clients reagieren darauf sehr empfindlich.

Wichtig ist außerdem die Einordnung der Symptome:
Die beschriebenen Probleme betreffen vor allem WLAN-basierte Dienste (WLAN-Telefonie, IPTV über WLAN, Cast-Funktionen). Die eigentliche Funkstrecke, Airtime-Auslastung, Multicast-Handling der Accesspoints und der Switches liegen jedoch außerhalb der Kontrolle von OPNsense. Wenn diese Ebenen nicht getrennt betrachtet werden, sucht man schnell an der falschen Stelle.

Mein Eindruck ist daher, dass es weniger um einzelne Stellschrauben geht, sondern darum, das Grundkonzept (Segmentierung, Regelrichtung, State-Logik, Multicast-Design) klar zu verstehen und konsequent danach zu konfigurieren. In der Praxis hilft es oft, das Regelwerk zunächst deutlich zu vereinfachen:

- pro VLAN nur Regeln auf dem jeweiligen Quell-Interface,

- keine pauschalen any:any-Regeln,

- Multicast gezielt und sparsam behandeln,

- WLAN-Probleme bewusst auch auf WLAN- und Switch-Ebene analysieren.

Das ist nicht als Kritik gemeint, sondern als konstruktiver Hinweis. Ein sauberes Grundkonzept erspart am Ende viel Zeit bei der Fehlersuche.


Niemand wird wirklich bei so einen Setup helfen wollen, besonders wenn elementare Dinge fehlen.

[Zapad]

Also mal ganz von Anfang.

Das was ich oben geschrieben habe Vergessen! ausser Shaper ;)

Es sollte so sein dass wenn man die Sense aufsetzt. sollte man zuerst alle lans/vlans (nicht WAN) auf pass any setzen.

Das heisst: quelle beliebig, ziel beliebig, protokolle alle, ports alle.

für Anfang Vlan(s) an ein Parent interface binden, und natürlich any regel setzen wie oben.

Auf dem Switch Trunk erstellen der Tagged Vlans enthält, die auf der Sense konfiguriert sind und untag PVID für Client Ports setzen.

Clients ip's von jeweiligen Vlan Range zuweisen mit Gateway Adresse vom Vlan/Sense.

Somit sollte Grundgerüst fertig sein.


Danach kann man auf dem Vlan zb Regel setzen Quelle Gast.lan deny Destination Management.lan

Somit sollte Streaming, Phoning, etc. laufen.

Zusatzdienste wie Broadcast/Multicast Relay braucht man mmn. nur wenn man übergreifend steamt/empfängt, zb. quelle Vlan 10
(Spotify) ziel (Smart Lautsprecher) Vlan 20 und Sense soll das routen. (Mcast,ssdp,Dlna)

in dem zusammenhang können auch Switche die nicht korrekt IGMP konfiguriert haben probleme machen.

Wenn man das hat kann man sich auf die Fehlersuche begeben:

Livelog begutachten,  welche quelle>ziel geblockt? (Quelle>Ziel legal? gelockt warum?)

Klappt alles!?

jetzt kann man an das Schraubendrehen gehen, schauen welche Ports/Protokolle benutzt?
Aliase erstellen und die Regeln any langsam gegen Regeln mit restriktivem Setting austauschen, dabei immer livelog im Auge haben.

Die Regeln die "IP4 any any allow" haben, brauchen keine ziel spezifizierung wie 239.255.255.250 pass dazu, das ist dann schon inbegriffen.

...und wenn dann bei legalen Quelle>zielen Default deny auftaucht mit zb DF Flag als reason, kann man mit tieferen Fehlersuche beginnen.