"Recent posts
#1
General Discussion / Re: VLAN with Synology RT600AX...
Last post by nero355 - Today at 07:53:44 PMQuote from: Tobanja on Today at 06:28:52 PMWith the help of AI, I have created a guest VLANNext time skip the Machine Learning Chatbot and just read the OPNsense Documentation : https://docs.opnsense.org/manual/how-tos/guestnet.html
I think my Guest VLAN was done in 5 to 10 minutes by just following the steps in the document ;)
You can skip the Guest Portal stuff ofcourse!
#2
Tutorials and FAQs / Re: HOWTO - Redirect all DNS R...
Last post by nero355 - Today at 07:47:56 PMQuote from: Tismofied on Today at 05:26:53 PMhow would unbound on OPNsense fit in this scenario if one were to use it as upstream server?The same as it does now for me but you enter the IP Address of OPNsense on the Default LAN network instead of 127.0.0.1:5335 in the Pi-Hole webGUI :)
#3
General Discussion / Re: VLAN with Synology RT600AX...
Last post by Seimus - Today at 07:09:15 PMThe best practice is to block and permit ingress (IN). But the critical part is what you found yourself.
This basically means that the traffic, devices from the SSID guest is not beying forwarded with the guest VLAN ID 10.
You need to bind the SSID to that VLAN if its possible for the RT6600AX. Usually this is done in a way that you create an interface that has the proper VLAN TAG (unnumbered) and attach on it the SSID. I don't use synology so I cant be more specific.
Regards
S.
QuoteWhen checking the opnsense live log, I notice the ping is present from the phone, but coming from the standard LAN interface in spite of all my struggles.
This basically means that the traffic, devices from the SSID guest is not beying forwarded with the guest VLAN ID 10.
You need to bind the SSID to that VLAN if its possible for the RT6600AX. Usually this is done in a way that you create an interface that has the proper VLAN TAG (unnumbered) and attach on it the SSID. I don't use synology so I cant be more specific.
Regards
S.
#4
25.7, 25.10 Series / Re: BIOS halted with 0x06 Inva...
Last post by alex303 - Today at 07:08:20 PMQuote from: txr13 on February 26, 2026, 05:14:26 PMQuote from: alex303 on February 26, 2026, 04:34:34 PMThis is why your firewall should always use open source BIOS like core boot or libreboot. UEFI is just too much hassle and insecure.
I would agree that using coreboot is an excellent option, particularly where the hardware vendor officially supports it. I find the Protectli boxen are very good on that point, and any of those which run OPNsense for me are indeed using coreboot.
...which boots using UEFI.
Older FW series from Protectli boot into legacy mode.
#5
General Discussion / Re: The OPNsense Plugins Syste...
Last post by Majx - Today at 07:05:42 PM> Your idea makes sense, but it would give legitimacy to plugins that are not vetted.
That concern is valid, and I agree it is one of the main risks in the current proposal. However, I do not think the proposal has to be adopted exactly as written. It can be refined and improved.
The objective is to shift responsibility and maintenance burden to plugin authors while allowing the core team to focus more on OPNsense itself. If we can design a model that makes plugin creators clearly responsible for their own code, without implying endorsement or legitimacy by the core project, then we could achieve that goal without compromising security standards.
At the moment, the team spends significant time reviewing PRs, vetting plugins, and maintaining a large and growing ecosystem. As OPNsense continues to grow in popularity, that workload will only increase. Reducing that overhead would directly benefit the core product and its long term stability.
> I just wanted to make this part clear, because it is an uncontrollable risk in your suggestion, because nobody is vetting the code.
It is indeed an uncontrollable risk to some extent. The real question is who owns that risk.
If third party plugins are clearly separated from the OPNsense core, both technically and in terms of branding and messaging, then the responsibility shifts to the user who decides to install them. Many software ecosystems operate this way. Not every extension is vetted by core maintainers, but they are clearly identified as community maintained or third party.
As long as there is no implied endorsement and users are clearly informed that these plugins are not reviewed by the core team, the responsibility model becomes much clearer.
> A GUI click is NOT a responsibility shift in the minds of (some) users.
That is true to a certain degree. Some users will always assume that if something appears in the GUI, it is officially supported.
However, we also have to define reasonable boundaries. It is not realistic to eliminate every possible misunderstanding. At some point, clear labeling and explicit warnings have to be considered sufficient.
If the interface clearly states that certain plugins are community maintained, not reviewed by the core team, and installed at the user's own risk, then the project has taken reasonable steps to communicate that distinction.
Ultimately, this is about balance. We need to protect the reputation and security posture of OPNsense, avoid an unsustainable maintenance burden for the core team, and still allow the ecosystem to grow without becoming a bottleneck.
I am not arguing for removing safeguards. I am just suggesting that we explore a structure that preserves the security expectations while enabling the project to scale. If we do not adjust the model, the maintenance burden of plugins will only continue to grow, and that may become a larger long term risk than clearly marked third party plugins.
/Majx
That concern is valid, and I agree it is one of the main risks in the current proposal. However, I do not think the proposal has to be adopted exactly as written. It can be refined and improved.
The objective is to shift responsibility and maintenance burden to plugin authors while allowing the core team to focus more on OPNsense itself. If we can design a model that makes plugin creators clearly responsible for their own code, without implying endorsement or legitimacy by the core project, then we could achieve that goal without compromising security standards.
At the moment, the team spends significant time reviewing PRs, vetting plugins, and maintaining a large and growing ecosystem. As OPNsense continues to grow in popularity, that workload will only increase. Reducing that overhead would directly benefit the core product and its long term stability.
> I just wanted to make this part clear, because it is an uncontrollable risk in your suggestion, because nobody is vetting the code.
It is indeed an uncontrollable risk to some extent. The real question is who owns that risk.
If third party plugins are clearly separated from the OPNsense core, both technically and in terms of branding and messaging, then the responsibility shifts to the user who decides to install them. Many software ecosystems operate this way. Not every extension is vetted by core maintainers, but they are clearly identified as community maintained or third party.
As long as there is no implied endorsement and users are clearly informed that these plugins are not reviewed by the core team, the responsibility model becomes much clearer.
> A GUI click is NOT a responsibility shift in the minds of (some) users.
That is true to a certain degree. Some users will always assume that if something appears in the GUI, it is officially supported.
However, we also have to define reasonable boundaries. It is not realistic to eliminate every possible misunderstanding. At some point, clear labeling and explicit warnings have to be considered sufficient.
If the interface clearly states that certain plugins are community maintained, not reviewed by the core team, and installed at the user's own risk, then the project has taken reasonable steps to communicate that distinction.
Ultimately, this is about balance. We need to protect the reputation and security posture of OPNsense, avoid an unsustainable maintenance burden for the core team, and still allow the ecosystem to grow without becoming a bottleneck.
I am not arguing for removing safeguards. I am just suggesting that we explore a structure that preserves the security expectations while enabling the project to scale. If we do not adjust the model, the maintenance burden of plugins will only continue to grow, and that may become a larger long term risk than clearly marked third party plugins.
/Majx
#6
26.1 Series / Re: Unbound Query Forwarding ....
Last post by kasper93 - Today at 07:03:33 PMDisable `Register ISC DHCP4 Leases` option in Unbound. Even if ISC is disabled, this option will still affect Unbound, and register dummy tables, which in turn breaks query forwarding.
#7
26.1 Series / Re: WiFi interface broken afte...
Last post by tcris - Today at 06:57:45 PMQuote from: franco on February 07, 2026, 06:44:42 PMYes, make sure you are on 26.1.1 and run this from the console:
# opnsense-patch 4912a67
Cheers,
Franco
Hey Franco,
does the above still make sense on opnsense 26.1.2_5? (where I still have the wifi issue)
only the above patch (4912a67), or maybe both of these?
# opnsense-patch 45597a9
# opnsense-patch 4912a67
Thanks
#8
High availability / Re: Little Confused
Last post by Seimus - Today at 06:36:50 PMQuote from: falken on Today at 04:31:16 PMYou can force the interface name by using device hints.
Edit device.hints from the shell and edit (or create) the file /boot/device.hints
Add entries to bind the MAC address to a specific device name.
Example: To make a specific Intel card (igb0) always be lan0:
hint.igb.0.mac="00:11:22:33:44:55"
hint.igb.0.name="lan0"
This will keep the interface names identical between your boxes.
ooookay this is sick. Thanks for the tip!
I know the answer, but.... Why This is not a thing directly in the GUI? :)
Regards,
S.
#9
26.1 Series / Re: VoIP outbound calls not wo...
Last post by olmo1501 - Today at 06:33:43 PMI would recommend using IPv6. That would simplify things a lot.
If you really need IPv4 make sure to create an Outbound NAT rule that sets static ports for your VoIP device.
If you really need IPv4 make sure to create an Outbound NAT rule that sets static ports for your VoIP device.
#10
General Discussion / VLAN with Synology RT600AX in ...
Last post by Tobanja - Today at 06:28:52 PMHey everybody! First post here. So, first of all, I'm pretty new to networking in general, but I fell in love with opnsense and want to learn more. So I quickly converted my old router, the RT6600AX, into an AP and happily started to create a VLAN network tagged 10. I'm using a TP-Link SG2210P switch, and have made sure to set the port from the AP to the switch, and also the one from switch to opnsense, into "tagged".
With the help of AI, I have created a guest VLAN, tagged 10, the same as on the AP and switch, however no matter how I try, I don't seem to be able to create an isolated VLAN in spite of correct rules (I believe). When connecting to the guest network on 192.168.10.x, I can still ping devices on 192.168.1.x although my first rule is to block traffic to 192.168.0.0/16 "in" from the guest interface. Grok suggested floating rules in "out" direction, but I tried that as well.
When checking the opnsense live log, I notice the ping is present from the phone, but coming from the standard LAN interface in spite of all my struggles. Grok's theory is that the synology AP simply doesn't send the tag correctly so it all ends up on the same network in opnsense anyway.
I'm not sure if anyone understands what I'm writing here. I guess I'm interested in knowing if anyone else has had any luck with the synology AP for isolated VLAN, or if it rather belongs in the trash can?
With the help of AI, I have created a guest VLAN, tagged 10, the same as on the AP and switch, however no matter how I try, I don't seem to be able to create an isolated VLAN in spite of correct rules (I believe). When connecting to the guest network on 192.168.10.x, I can still ping devices on 192.168.1.x although my first rule is to block traffic to 192.168.0.0/16 "in" from the guest interface. Grok suggested floating rules in "out" direction, but I tried that as well.
When checking the opnsense live log, I notice the ping is present from the phone, but coming from the standard LAN interface in spite of all my struggles. Grok's theory is that the synology AP simply doesn't send the tag correctly so it all ends up on the same network in opnsense anyway.
I'm not sure if anyone understands what I'm writing here. I guess I'm interested in knowing if anyone else has had any luck with the synology AP for isolated VLAN, or if it rather belongs in the trash can?
