"Recent posts
#1
Hardware and Performance / Re: quad interface fierwall PC...
Last post by qarkhs - Today at 10:47:30 PMQuote from: passeri on May 12, 2026, 02:24:12 AMJust pausing to mention existence of other places on the planet at which point simplicity is down the gurgler, decisions need to be made.
Yes, I started out with a Fitlet2 and then moved to a GigaIPC box. The latter company is the industrial PC division of Gigabyte. There are lots of options. There's also AAEON which is the industrial PC division of ASUS. AAEON also now owns Jetway, another IPC maker. There's also Lanner, which have at various times made boxes for certain firewall companies. They don't sell directly to consumers but you can get their stuff used, with their name or another name on the box. And, of course there's Supermicro.
#2
General Discussion / Re: need help with wol api
Last post by groove21 - Today at 10:13:48 PMOk my fault. Playbook is working fine. Just mistakenly used description as interface instead of interface name.... After changing, everything is perfect.
#3
General Discussion / Re: youtube going offline
Last post by oriagranat9 - Today at 10:13:18 PMok issue is still happening even after setting the mtu.
even when using https://inv.nadeko.net/ the video loads super slow at the star, but once its loaded and started everything is working ok
even when using https://inv.nadeko.net/ the video loads super slow at the star, but once its loaded and started everything is working ok
#4
26.1, 26,4 Series / Re: Virtual IP
Last post by cookiemonster - Today at 10:09:01 PMWell I learned something today. I will need to read up on these concepts.
Seems like I was thinking wrong about how the OP could have wanted to see if possible with OPN. My thinkng was along the lines as I said of F5 BigIP hardware load balancers ie https://f5-agility-labs-adc.readthedocs.io/en/latest/class1/module1/lab1.html https://clouddocs.f5.com/training/community/adc/html/class1/module1/lab1.html
Seems like I was thinking wrong about how the OP could have wanted to see if possible with OPN. My thinkng was along the lines as I said of F5 BigIP hardware load balancers ie https://f5-agility-labs-adc.readthedocs.io/en/latest/class1/module1/lab1.html https://clouddocs.f5.com/training/community/adc/html/class1/module1/lab1.html
#5
26.1, 26,4 Series / Re: A firewalll rule pattern t...
Last post by opnseeker - Today at 09:38:23 PMFirewall Interface group: IG
IG: VL1, VL2, WG1
VL1 and VL2 are VLAN interfaces
WG1 is a Wireguard interface used for incoming connections with multiple peers: WGP1, WGP2 & WGP3
Rules
Quick off
Dir: In
Action: Pass
Interface: IG
Version: IP4
Protocols: TCP/UDP
Source:any
Source port: any
Dest: not private networks
Dest port: any
Gateway: default
Quick on
Dir: In
Action: Pass
Interface: WG1
Version: IP4/IP6
Protocols: TCP/UDP
Source:WGP1
Source port: any
Dest: not private networks
Dest port: any
Gateway: VPN gateway
First rule sends all traffic to internet over the ISP connection using IP4 (IP6 is not supported by the ISP).
Second rule is supposed to override that for one of the incoming wireguard connections and send its internet traffic over VPN using both IP4 and IP6.
Problem:
When WGP1 and WGP2 are both connected behavior is unpredictable. Sometimes everything works. Sometimes both cannot get to the internet. Sometimes, one gets to the internet and the other doesn't. I can't think of any specific pattern when one happens vs another.
For internal clients not connected over wireguard, this pattern seems to work.
Hopefully, this provides enough detail. Thanks in advance for the help.
IG: VL1, VL2, WG1
VL1 and VL2 are VLAN interfaces
WG1 is a Wireguard interface used for incoming connections with multiple peers: WGP1, WGP2 & WGP3
Rules
Quick off
Dir: In
Action: Pass
Interface: IG
Version: IP4
Protocols: TCP/UDP
Source:any
Source port: any
Dest: not private networks
Dest port: any
Gateway: default
Quick on
Dir: In
Action: Pass
Interface: WG1
Version: IP4/IP6
Protocols: TCP/UDP
Source:WGP1
Source port: any
Dest: not private networks
Dest port: any
Gateway: VPN gateway
First rule sends all traffic to internet over the ISP connection using IP4 (IP6 is not supported by the ISP).
Second rule is supposed to override that for one of the incoming wireguard connections and send its internet traffic over VPN using both IP4 and IP6.
Problem:
When WGP1 and WGP2 are both connected behavior is unpredictable. Sometimes everything works. Sometimes both cannot get to the internet. Sometimes, one gets to the internet and the other doesn't. I can't think of any specific pattern when one happens vs another.
For internal clients not connected over wireguard, this pattern seems to work.
Hopefully, this provides enough detail. Thanks in advance for the help.
#6
26.1, 26,4 Series / Re: OPNBEcore 1.8_2 Update wit...
Last post by mooh - Today at 09:20:16 PMThank you very much for answering at this time of day!
#7
26.1, 26,4 Series / Re: OPNBEcore 1.8_2 Update wit...
Last post by Monviech (Cedrik) - Today at 09:15:20 PMHello, yes the update is legitimate. Its a small hotfix that fixes this issue:
https://forum.opnsense.org/index.php?topic=51905.0
https://forum.opnsense.org/index.php?topic=51905.0
#8
German - Deutsch / Re: Umgang mit VLAN
Last post by meyergru - Today at 09:02:00 PMMehrere.
Also zunächst: Deine aktuelle Situation ist offensichtlich so, dass die Fritzbox der Eingangsrouter und die OpnSense liegt als zweiter Router dahinter. Dann kommt es darauf an, ob die OpnSense NAT für die angeschlossenen LAN und WLANx macht - ich gehe davon aus, dass ja.
Somit nutzt Du (hoffentlich) das WLAN der Fritzbox NICHT. Falls doch, sind die dort angemeldeten WLAN-Clients nämlich gar nicht durch die OpnSense geschützt / kontrolliert - es ist lediglich so, das die "hinter" der OpnSense liegenden Subnetze für WLAN-Clients an der Fritzbox unerreichbar sind (modulo Port-Forwarding oder Regeln für das Fritzbox-Subnetz).
Das ließe sich natürlich dahingehend nutzen (ich würde eher sagen: schmutzen), dass das die "unzuverlässigen" Geräte sind, eben weil sie aus der Sicht von OpnSense "außen" liegen. Keep in mind: OpnSense kontrolliert diese Geräte dann nicht - die können unbegrenzt "nach Hause telefonieren" - direkt über die Fritzbox.
Ich weiß nicht, wie der Fritzrepeater funktioniert, aber ein echtes Gastnetz kann er nicht stellen, außer er spielt irgendwie mit der Fritzbox zusammen (aber dann werden angeschlossende Geräte nicht durch die Fritzbox kontrolliert). Letztlich reicht er als transparente Bridge einfach Pakete durch. Falls er am LAN hängt, sieht er auch nur das und nicht das "Gast"-LAN der Fritzbox - außer, AVM hat da irgendwas gezaubert. Was er eventuell tun kann, ist, ein eigenes Gast-WLAN aufziehen und dafür sorgen, dass sich Geräte links und rechts nicht "sehen" - das kann man in vielen APs auch tun, nennt sich "Client Isolation".
Also: Die genaue Topologie und die Rollen der eingesetzten Hardware sind mir unklar.
Die "saubere" Variante ist wie folgt:
1. Die Fritzbox als Router "loswerden". Stattdessen eine reine DSL-Bridge oder einen ONT verwenden und die OpnSense den Internetzugriff regeln lassen. Das bewirkt gleichzeitig auch, dass man "Router-hinter-Router" loswird. Bei mir z.B. macht die Fritzbox als LAN-Client nur noch Telefonie und Smart Home, kein Internet, kein WLAN. Näheres siehe hier.
2. Einen managebaren Switch beschaffen. Dort ein LAN (VLAN 1) und GAST (VLAN x) anlegen (oder eventuell weitere). OpnSense und alle APs (wichtig: VLAN-fähig) werden auf Trunk-Ports geschaltet, die Endgeräte je nach Vertrauensstellung auf VLAN 1 oder x.
3. Auf den APs werden pro VLAN jeweils SSIDs angelegt mit unterschiedlichen Passworten. Somit kann man bei WLAN-Clients durch Auswahl der SSID bestimmen, was sie dürfen.
4. Devolo ist keine so gute Idee, die können m.W. auch keine VLANs. Und ja, Du könntest einen an einen Anschluss packen und den anderen an den anderen, nur will man (=ich) normalerweise durch Einsatz mehrerer APs nicht mehrere SSIDs/VLANs/Subnetze erzeugen, sondern eine höhere Funkabdeckung. Also wenn, sollten alle APs alle SSId aufliegen haben. Und dann kommen sie eben nicht an unterschiedliche Ports der OpnSense, sondern an Trunk-Ports am Switch (idealerweise mit PoE).
5. Randbemerkung: Man sollte niemals Tagged mit Untagged auf dem selben FreeBSD-Netzwerkanschluss mischen. Deshalb bietet es sich an, OpnSense mit einem Trunk-Port (für getaggte VLANs) und einem zweiten LAN-Port (untagged) zu verbinden. Damit ist a. die Bandbreite von LAN <-> VLANs nicht halbiert und b. ist die Regel eingehalten. Ich sage das nur, weil z.B. Unifi das normale LAN normalerweise untagged haben will. Ich empfehle Unifi, weil der Mix verschiedener Hersteller gerade beim Einsatz von VLANs extremst verwirrend sein kann. Bei Unifi werden Switches und APs mit dem selben Tool konfiguriert.
P.S.: Das heißt nicht, dass das einfach ist. Für einen Anfänger sind das dicke Bretter zu bohren - da hast Du wochenlang was von und so richtig durchcoachen wird Dich da keiner... das erhöht die Anzahl Deiner Postings locker auf >100.
Also zunächst: Deine aktuelle Situation ist offensichtlich so, dass die Fritzbox der Eingangsrouter und die OpnSense liegt als zweiter Router dahinter. Dann kommt es darauf an, ob die OpnSense NAT für die angeschlossenen LAN und WLANx macht - ich gehe davon aus, dass ja.
Somit nutzt Du (hoffentlich) das WLAN der Fritzbox NICHT. Falls doch, sind die dort angemeldeten WLAN-Clients nämlich gar nicht durch die OpnSense geschützt / kontrolliert - es ist lediglich so, das die "hinter" der OpnSense liegenden Subnetze für WLAN-Clients an der Fritzbox unerreichbar sind (modulo Port-Forwarding oder Regeln für das Fritzbox-Subnetz).
Das ließe sich natürlich dahingehend nutzen (ich würde eher sagen: schmutzen), dass das die "unzuverlässigen" Geräte sind, eben weil sie aus der Sicht von OpnSense "außen" liegen. Keep in mind: OpnSense kontrolliert diese Geräte dann nicht - die können unbegrenzt "nach Hause telefonieren" - direkt über die Fritzbox.
Ich weiß nicht, wie der Fritzrepeater funktioniert, aber ein echtes Gastnetz kann er nicht stellen, außer er spielt irgendwie mit der Fritzbox zusammen (aber dann werden angeschlossende Geräte nicht durch die Fritzbox kontrolliert). Letztlich reicht er als transparente Bridge einfach Pakete durch. Falls er am LAN hängt, sieht er auch nur das und nicht das "Gast"-LAN der Fritzbox - außer, AVM hat da irgendwas gezaubert. Was er eventuell tun kann, ist, ein eigenes Gast-WLAN aufziehen und dafür sorgen, dass sich Geräte links und rechts nicht "sehen" - das kann man in vielen APs auch tun, nennt sich "Client Isolation".
Also: Die genaue Topologie und die Rollen der eingesetzten Hardware sind mir unklar.
Die "saubere" Variante ist wie folgt:
1. Die Fritzbox als Router "loswerden". Stattdessen eine reine DSL-Bridge oder einen ONT verwenden und die OpnSense den Internetzugriff regeln lassen. Das bewirkt gleichzeitig auch, dass man "Router-hinter-Router" loswird. Bei mir z.B. macht die Fritzbox als LAN-Client nur noch Telefonie und Smart Home, kein Internet, kein WLAN. Näheres siehe hier.
2. Einen managebaren Switch beschaffen. Dort ein LAN (VLAN 1) und GAST (VLAN x) anlegen (oder eventuell weitere). OpnSense und alle APs (wichtig: VLAN-fähig) werden auf Trunk-Ports geschaltet, die Endgeräte je nach Vertrauensstellung auf VLAN 1 oder x.
3. Auf den APs werden pro VLAN jeweils SSIDs angelegt mit unterschiedlichen Passworten. Somit kann man bei WLAN-Clients durch Auswahl der SSID bestimmen, was sie dürfen.
4. Devolo ist keine so gute Idee, die können m.W. auch keine VLANs. Und ja, Du könntest einen an einen Anschluss packen und den anderen an den anderen, nur will man (=ich) normalerweise durch Einsatz mehrerer APs nicht mehrere SSIDs/VLANs/Subnetze erzeugen, sondern eine höhere Funkabdeckung. Also wenn, sollten alle APs alle SSId aufliegen haben. Und dann kommen sie eben nicht an unterschiedliche Ports der OpnSense, sondern an Trunk-Ports am Switch (idealerweise mit PoE).
5. Randbemerkung: Man sollte niemals Tagged mit Untagged auf dem selben FreeBSD-Netzwerkanschluss mischen. Deshalb bietet es sich an, OpnSense mit einem Trunk-Port (für getaggte VLANs) und einem zweiten LAN-Port (untagged) zu verbinden. Damit ist a. die Bandbreite von LAN <-> VLANs nicht halbiert und b. ist die Regel eingehalten. Ich sage das nur, weil z.B. Unifi das normale LAN normalerweise untagged haben will. Ich empfehle Unifi, weil der Mix verschiedener Hersteller gerade beim Einsatz von VLANs extremst verwirrend sein kann. Bei Unifi werden Switches und APs mit dem selben Tool konfiguriert.
P.S.: Das heißt nicht, dass das einfach ist. Für einen Anfänger sind das dicke Bretter zu bohren - da hast Du wochenlang was von und so richtig durchcoachen wird Dich da keiner... das erhöht die Anzahl Deiner Postings locker auf >100.
#9
26.1, 26,4 Series / OPNBEcore 1.8_2 Update without...
Last post by mooh - Today at 08:41:29 PMJust saw this update without announcement here. Is it legitimate? How to check the validity of plugin updates?
#10
General Discussion / Re: Unsense - new GUI theme
Last post by lnet.admin - Today at 08:35:15 PMSame here, I don't see Unsense
