"Recent posts
#1
German - Deutsch / Re: Probleme mit IPTV / WIFI T...
Last post by Zapad - Today at 09:16:21 AMAlso 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.
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.
#2
General Discussion / Re: assigning static IP addres...
Last post by passeri - Today at 08:27:12 AMISC was responsible for "ISC DHCP" which is superseded by Kea, especially for larger installations. DNSmasq is an alternative. Please ignore "ISC DHCP" in the menus, whatever else you do (other than making sure it is disabled of course).
I prefer Opnsense official documentation, which is generally well written. If it proves a little terse then ask for clarification here. Videos and other secondary documentation can be out of date or wrong (or both) so if video is your preferred instructional method you should still verify every step against the official documentation. You will find the relevant part here.
The advice I am giving you is based also on my own working Kea with different subnets and reservations in each. It worked first time by following the docs.
I prefer Opnsense official documentation, which is generally well written. If it proves a little terse then ask for clarification here. Videos and other secondary documentation can be out of date or wrong (or both) so if video is your preferred instructional method you should still verify every step against the official documentation. You will find the relevant part here.
The advice I am giving you is based also on my own working Kea with different subnets and reservations in each. It worked first time by following the docs.
#3
25.7, 25.10 Series / Re: OpenVPN clients with multi...
Last post by fastboot - Today at 08:22:02 AMThis behavior is normal with OpenVPN when clients use a dynamic address pool. persist-ip alone does not guarantee a fixed address per user; it only helps reuse addresses within the same server runtime and does not survive restarts or guarantee per-user consistency.
If you want the same user to always receive the same IP, you must use client-specific configuration (CCD) and assign the address explicitly with ifconfig-push, making sure that each user has a unique Common Name and that username-as-common-name is enabled if you authenticate via user/password. Alternatively, enable pool-persist with a persistent file so the server remembers past assignments across restarts, but this still does not strictly bind an IP to a specific user identity.
In short: what you see is expected, and the reliable solution is per-user static IP assignment via CCD, not persist-ip.
My other two cents. Wireguard is way more reliable, not so picky in configuration and as well way faster.
If you want the same user to always receive the same IP, you must use client-specific configuration (CCD) and assign the address explicitly with ifconfig-push, making sure that each user has a unique Common Name and that username-as-common-name is enabled if you authenticate via user/password. Alternatively, enable pool-persist with a persistent file so the server remembers past assignments across restarts, but this still does not strictly bind an IP to a specific user identity.
In short: what you see is expected, and the reliable solution is per-user static IP assignment via CCD, not persist-ip.
My other two cents. Wireguard is way more reliable, not so picky in configuration and as well way faster.
#4
25.7, 25.10 Series / Re: Specific Websites not reac...
Last post by fastboot - Today at 08:18:52 AMcheck if your allow rules apply and make as well a dump and check it via wireshark
#5
General Discussion / Re: Opnsense vs mainstream rou...
Last post by Hollywood - Today at 08:17:05 AM@OPNenthu
Great reply and just what i hoped. Thank you so much for the detailed answer and explanation!
Great reply and just what i hoped. Thank you so much for the detailed answer and explanation!
#6
German - Deutsch / Re: Sporadischer Ausfall Firew...
Last post by fastboot - Today at 08:16:51 AMSystem log angeschaut? Zum eingrenzen der exakten Zeit nen ping laufen lassen? Ergo Ping wech = Firewall platt?
#7
German - Deutsch / Re: Suricata Richtlinie
Last post by fastboot - Today at 08:09:54 AMOb deine Suricata-Konfiguration tatsächlich aktiv blockiert, lässt sich nicht anhand der Regelwerke oder der gesetzten Aktion allein beurteilen. Entscheidend ist, dass Suricata in OPNsense im IPS-Modus (Inline/Netmap) läuft und auf den relevanten Interfaces aktiv ist. Andernfalls werden auch Regeln mit Aktion ,,Verwerfen" nur alarmieren, aber keinen Traffic blockieren.
Am sinnvollsten testest du das mit einer gezielten Testsignatur oder einem reproduzierbaren Testtraffic, bei dem du erwartest, dass die Verbindung aktiv abbricht. Wenn der Traffic weiterhin durchgeht und nur Alerts erzeugt werden, greift die Blockierung nicht. Erst wenn du in den Suricata-Logs eindeutig ,,drop" siehst und die Verbindung tatsächlich scheitert, ist sichergestellt, dass IPS aktiv arbeitet.
Am sinnvollsten testest du das mit einer gezielten Testsignatur oder einem reproduzierbaren Testtraffic, bei dem du erwartest, dass die Verbindung aktiv abbricht. Wenn der Traffic weiterhin durchgeht und nur Alerts erzeugt werden, greift die Blockierung nicht. Erst wenn du in den Suricata-Logs eindeutig ,,drop" siehst und die Verbindung tatsächlich scheitert, ist sichergestellt, dass IPS aktiv arbeitet.
#8
German - Deutsch / Re: Kein Zugriff auf Weboberfl...
Last post by fastboot - Today at 08:05:30 AMNotfalls mal nen Dump erstellen und sich mit Wireshark anschauen. Damit sollte klar ersichtlich sein, wo es klemmt.
#9
German - Deutsch / Re: Probleme mit IPTV / WIFI T...
Last post by fastboot - Today at 07:59:19 AMHallo,
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.
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.
#10
General Discussion / Re: Opnsense vs mainstream rou...
Last post by OPNenthu - Today at 07:12:59 AMIf you just installed OPNsense and you do nothing else with rules, it will out of the box:
- block all unsolicited incoming packets
- allow all outgoing (so you can use the internet freely with nothing being blocked for you or any devices in your LAN)
- allow replies (so that the internet servers you talk to can talk back and serve you data)
In other words, it keeps track of connection states in a state table and uses that information to make decisions about which incoming traffic is expected (pass) and which is not (deny).
The "Default deny / state violation" rule on WAN is what provides the protection and it's applied on all ports in OPNsense by default.
It's up to you to expose things if you decide to, but nothing is open by default and there's no UPnP out of the box to worry about. That also means there's no UPnP helping game consoles and other things to initiate p2p connections on their own, which you would need to configure yourself in OPNsense.
So it's at least as good, if not better, than consumer routers... maybe? The danger comes when you need to do something beyond the default configuration and then can easily make mistakes. OPNsense won't warn you about misconfigurations or unintended consequences because it assumes you already know and it stays out of your way.
You picked a good firewall. You can rest easy for now ;)
- block all unsolicited incoming packets
- allow all outgoing (so you can use the internet freely with nothing being blocked for you or any devices in your LAN)
- allow replies (so that the internet servers you talk to can talk back and serve you data)
In other words, it keeps track of connection states in a state table and uses that information to make decisions about which incoming traffic is expected (pass) and which is not (deny).
The "Default deny / state violation" rule on WAN is what provides the protection and it's applied on all ports in OPNsense by default.
It's up to you to expose things if you decide to, but nothing is open by default and there's no UPnP out of the box to worry about. That also means there's no UPnP helping game consoles and other things to initiate p2p connections on their own, which you would need to configure yourself in OPNsense.
So it's at least as good, if not better, than consumer routers... maybe? The danger comes when you need to do something beyond the default configuration and then can easily make mistakes. OPNsense won't warn you about misconfigurations or unintended consequences because it assumes you already know and it stays out of your way.
You picked a good firewall. You can rest easy for now ;)
