"Recent posts
#1
General Discussion / Re: Best way to set up DMZ wit...
Last post by JamesFrisch - Today at 09:32:53 AMQuote from: User074357 on April 03, 2026, 12:54:13 AMI have a /59 prefix from my ISP with a FritzBox and am using prefix delegation to delegate a /60 prefix for my OPNsense box
You sure it is /59?
That is pretty odd. And not following RIPE recommendations. What is the name of that ISP?
Is it at least static? Or does your ISP there also not follow RIPE recommendations?
@drosophila IP based tracking? Isn't that something from the yearli 2000ens and long gone?
#2
General Discussion / Re: Port OPNsense to Linux?
Last post by meyergru - Today at 09:21:24 AM@drosophila: But that does not change the way how most of this is done within OpnSense, by creating the interfaces aorund the specific implementation of the various services, like that currently, even the actual MAC->IPv4 tables are edited and saved for each service individually. @pfry put it right: There currently is no abstraction layer.
Also, that abstraction layer could catch even more than the uniform usage of different services, but also the jump from the MAC->IP to the IP->DNS layer, including aliases. It could also cover the problems around the dynamic to static transition of devices.
What I mean by that is that now, with Kea, when you first put a device on the network, it will get a dynamic IPv4. Yes, you can make that static - but that does not work at all, because the lease is not deleted and conflicts with the static reservation, thus creating a big problem in its wake.
Imagine a "client" entry that can be created manually or automatically upon first contact, where you just fill in the blanks, like change the DNS name, add DHCP options or DNS aliases and so forth, thereby creating a static reservation, while deleting the Kea lease underneath.
But doing that would be an initial design choice, trading limiting capabilities for ease of use. I doubt that it could or even should be tried in OpnSense.
Also, that abstraction layer could catch even more than the uniform usage of different services, but also the jump from the MAC->IP to the IP->DNS layer, including aliases. It could also cover the problems around the dynamic to static transition of devices.
What I mean by that is that now, with Kea, when you first put a device on the network, it will get a dynamic IPv4. Yes, you can make that static - but that does not work at all, because the lease is not deleted and conflicts with the static reservation, thus creating a big problem in its wake.
Imagine a "client" entry that can be created manually or automatically upon first contact, where you just fill in the blanks, like change the DNS name, add DHCP options or DNS aliases and so forth, thereby creating a static reservation, while deleting the Kea lease underneath.
But doing that would be an initial design choice, trading limiting capabilities for ease of use. I doubt that it could or even should be tried in OpnSense.
#3
General Discussion / Re: Which trigger for new IPv6...
Last post by meyergru - Today at 09:05:31 AMI do not understand your problem with the reordering, because dynv6.com allows you to use the variable "ipv6", which you can have derived from any EUI-64 that you like, like I depicted in my screendump above. You only need to specify the EUI-64 part that you want plus the interface that it should be combined with. No scripting needed.
And you would never, ever use a temporary (dynamically-created) EUI-64, always the "mgmtaddr", because OpnSense would not know when a tempaddr changes, so you must know in advance which EUI-64 to use and which interface it is connected to.
And you would never, ever use a temporary (dynamically-created) EUI-64, always the "mgmtaddr", because OpnSense would not know when a tempaddr changes, so you must know in advance which EUI-64 to use and which interface it is connected to.
#4
General Discussion / Re: DNS, DoH, DoT, DoQ, DNSCry...
Last post by OPNenthu - Today at 08:23:39 AMThe privacy question is something we can debate endlessly. For every argument on why one thing is better, there is likely a valid counterargument. A lot depends on your specific context.
- Where do you live?
- What is your threat model?
- Who are you trying to hide your DNS queries from? Who are you OK giving them to?
For example, one argument could be that using Unbound in recursive resolver mode is better for privacy because it spreads your queries and no one server has your full query.
A counterpoint to that is that your ISP can see those and maybe you don't want them selling your data. In that case, DoT to an upstream resolver like
Quad9 might be better. (In which case you probably also want a VPN so they don't see the dest. IP in your connections.)
And then someone else will counter-counter with an argument that encryption can be broken and "they" can man-in-the-middle you or decrypt your data anyway.
...
Pick your poison. At the end of the day someone is going to get your queries. You choose who you intend to give them to and how, but also accept that unintended audiences can and probably will get them.
- Where do you live?
- What is your threat model?
- Who are you trying to hide your DNS queries from? Who are you OK giving them to?
For example, one argument could be that using Unbound in recursive resolver mode is better for privacy because it spreads your queries and no one server has your full query.
A counterpoint to that is that your ISP can see those and maybe you don't want them selling your data. In that case, DoT to an upstream resolver like
Quad9 might be better. (In which case you probably also want a VPN so they don't see the dest. IP in your connections.)
And then someone else will counter-counter with an argument that encryption can be broken and "they" can man-in-the-middle you or decrypt your data anyway.
...
Pick your poison. At the end of the day someone is going to get your queries. You choose who you intend to give them to and how, but also accept that unintended audiences can and probably will get them.
#5
General Discussion / Re: DNS, DoH, DoT, DoQ, DNSCry...
Last post by RamSense - Today at 07:48:04 AMHi, good ask. From my point of view there is not one way to go. There are multiple roads to follow, just what you like most.
I'm no pro on this topic, but after my extended search/reading/trying; I came to this setup:
Opnsense with Adguard Home plugin + as upstream DNS Opnsense Bind (with DNSSEC) (with NO DNS Forwarders)
This way only the DNS Root servers get queried, and not one DNS server has all your queries, most privacy other than with DoH DoT DNSCrypt.
I'm no pro on this topic, but after my extended search/reading/trying; I came to this setup:
Opnsense with Adguard Home plugin + as upstream DNS Opnsense Bind (with DNSSEC) (with NO DNS Forwarders)
This way only the DNS Root servers get queried, and not one DNS server has all your queries, most privacy other than with DoH DoT DNSCrypt.
#6
German - Deutsch / Re: OPNsense mit Caddy, VLans ...
Last post by spooner.arthur - Today at 06:54:35 AMVielen Dank für eure Rückmeldungen.
Nein, ich hab keine Abneigung von intern die WAN IP anzusprechen, es bisher nicht funktioniert bzw. bei der 3CX wurde immer empfohlen das über Unbound DNS zu lösen.
Also mit dem Caddy kann man kein Verbindungslimit einrichten, mmh, mal schauen ob das interessant ist oder nicht.
Hab ich sonst noch sinnvolle Möglichkeiten die System mit der OPNsense abzusichern?
Wollte auch noch GeoIP Blocking einrichten, aber mehr fällt mir persönlich nicht ein.
Nein, ich hab keine Abneigung von intern die WAN IP anzusprechen, es bisher nicht funktioniert bzw. bei der 3CX wurde immer empfohlen das über Unbound DNS zu lösen.
Also mit dem Caddy kann man kein Verbindungslimit einrichten, mmh, mal schauen ob das interessant ist oder nicht.
Hab ich sonst noch sinnvolle Möglichkeiten die System mit der OPNsense abzusichern?
Wollte auch noch GeoIP Blocking einrichten, aber mehr fällt mir persönlich nicht ein.
#7
General Discussion / Re: Which trigger for new IPv6...
Last post by drosophila - Today at 05:50:58 AMThe good news: custom GET with dynamic host works on dynv6.com. I had to enter the password in the URL string, the variable "__PASSWORD__" that I tried didn't work, but I didn't try other possible variants.
I also found that in the "advanced" configuration, you can set a Dynamic IPv6 host natively without Custom GET.
The bad news: whatever I tried, all of them would use the first matching address it finds, which sadly always are the deprecated ones with the old prefix. So for this, too, I need my reordering script to run promptly. I'll see if it recovers when the prefix times out, but even if it does, that is 1 hour of downtime each time unless the script runs (which it doesn't because I've obviously screwed that up by trying to integrate it with the plugin system *sigh*)
I also found that in the "advanced" configuration, you can set a Dynamic IPv6 host natively without Custom GET.
The bad news: whatever I tried, all of them would use the first matching address it finds, which sadly always are the deprecated ones with the old prefix. So for this, too, I need my reordering script to run promptly. I'll see if it recovers when the prefix times out, but even if it does, that is 1 hour of downtime each time unless the script runs (which it doesn't because I've obviously screwed that up by trying to integrate it with the plugin system *sigh*)
#8
Tutorials and FAQs / Re: IPv6 Control Plane with FQ...
Last post by OPNenthu - Today at 05:03:05 AMI think the CoDel options outside of the FQ_CoDel scheduler are not effective, based on some preliminary testing.
I tried two things:
1)
Pipes set to WFQ
Queues set to CoDel + ECN
Result: bufferbloat score went way down (B-C range, +80ms on upload latency)
2)
Pipes set to WFQ + CoDel + ECN
Queues set plain (no options)
Result: same as above
There seems to be something special about the FQ_CoDel scheduler on pipes that makes them effective for Bufferbloat management which other CoDel options do not have.
If that's the case, then it won't be practical to classify and prioritize traffic types as the latency won't be acceptable.
The only way might be to use separate pipes with FQ_CoDel but I don't want to carve up my bandwidth.
Are you seeing the same?
I tried two things:
1)
Pipes set to WFQ
Queues set to CoDel + ECN
Result: bufferbloat score went way down (B-C range, +80ms on upload latency)
2)
Pipes set to WFQ + CoDel + ECN
Queues set plain (no options)
Result: same as above
There seems to be something special about the FQ_CoDel scheduler on pipes that makes them effective for Bufferbloat management which other CoDel options do not have.
If that's the case, then it won't be practical to classify and prioritize traffic types as the latency won't be acceptable.
The only way might be to use separate pipes with FQ_CoDel but I don't want to carve up my bandwidth.
Are you seeing the same?
#9
General Discussion / Re: Port OPNsense to Linux?
Last post by drosophila - Today at 04:25:34 AMSo Draytek still are good? I had one once and it was pretty solid. It had to be decommissioned due to lack of updates in the end. It even looked and felt like it was indestructible despite being plastic only. Everything else looks and feels flimsy compared to that (except the ancient Cisco rackmount switches with their "snake skin" finish :) ).
BTT: that sort of confusion probably arises from the default (unchangeable?) install coming with these options preinstalled without a default(?). Maybe the confusion would go away without reducing flexibility if you'd have a page "DHCP", on which you have an "enable" and then a dropbox to select which one, with one (say, Dnsmasq) preselected, and it's options appearing below that depending on what is chosen, with the rest auto-disabled but keeps its config stored so that you can go back and forth without losing settings.
So if you enable "DHCP" you'd just get Dnsmasq unless you change it and most would probably go with that preselected choice, but for those who care the option is there and immediately visible because the dropbox is a common way to do this and thus intuitive.
This would probably even make the UI cleaner because now services are sorted alphabetically instead of by function.
BTT: that sort of confusion probably arises from the default (unchangeable?) install coming with these options preinstalled without a default(?). Maybe the confusion would go away without reducing flexibility if you'd have a page "DHCP", on which you have an "enable" and then a dropbox to select which one, with one (say, Dnsmasq) preselected, and it's options appearing below that depending on what is chosen, with the rest auto-disabled but keeps its config stored so that you can go back and forth without losing settings.
So if you enable "DHCP" you'd just get Dnsmasq unless you change it and most would probably go with that preselected choice, but for those who care the option is there and immediately visible because the dropbox is a common way to do this and thus intuitive.
This would probably even make the UI cleaner because now services are sorted alphabetically instead of by function.
#10
General Discussion / Re: Best way to set up DMZ wit...
Last post by drosophila - Today at 04:05:07 AMQuote from: User074357 on April 03, 2026, 07:56:35 PMUsing "Firewall: Diagnostics: Aliases" I can confirm __wan_network includes the /64 prefix of the network the opnsense is in. However it does not include any other delegated prefixes by the FritzBox. Ideally I'd want it to block the entire /59 prefix.This was what I've been looking for, so thanks for pointing that out to me! :)
I wonder however, shouldn't the default "block any from any" last match rule catch everything already? It should, so you wouldn't need to create aliases for this, is the LAN even reachable from the OPT8 interface by default? This won't show from the OPNsense box due to the "let out anything from the firewall host itself" rule, so you'd need to test it with an actual device on OPT8. From what I see, it should work that way, but I cannot test this because I only have WAN and LAN interfaces.
Quote from: nero355 on April 03, 2026, 10:37:24 PMIn case your IPv6 Prefix changes the amount of editing you need to do is minimal this way :)This won't do, the prefix must be expected to change any time, unless the OP pays for a static prefix, which is unlikely. Mine changes every time I reconnect (and I like it that way for privacy reasons so I enforce daily reconnects just like with IPv4).
Quote from: nero355 on April 03, 2026, 10:37:24 PMI can't find any information about the ID that I am mentioning here @ https://docs.opnsense.org/ so I feel like I am saying something wrong here, but I am pretty sure I am not ?!What you probably have in mind will be the VLAN ID. The OP doesn't seem to utilize VLANs but the traditional topology of physically distinct subnets. Of course, you can assign a VLAN-ID-like infix to the subnet but contrary to VLANs this is optional.
