Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - gspannu

#1
Quote from: Firewire on May 25, 2025, 09:03:44 PMHi gspannu, any plans to update Blocky to the latest version?
Thanks so much for providing the packages, OPNsense and Blocky are a perfect match!

Oh... I did not realise that Blocky has been updated. I am on holiday until 04 June, will update it over the next available weekend.

Thanks for the ping...
#2
Quote from: Patrick M. Hausen on May 21, 2025, 09:57:22 PM
Quote from: gspannu on May 21, 2025, 03:57:28 PM
QuoteOk, I find myself confused about this, again.
If I have no VLANs and I am simply using the OPNsense default ".localdomain" for my LAN, would you recommend I be using .localdomain or lan.internal?


You can use either of the two... both will work.

Mind you that there can be a minor downside to using "localdomain". If you want to run your own local CA - on OPNsense or anywhere else - and you also want to use a wildcard certificate for a variety of devices that for some reason cannot use a real FQDN and Letsencrypt, then ...

- *.home.arpa will work while
- *.localdomain will not work

with current browsers. There have to be at least two dots in there.

I prefer - at work just like at home - to use a subdomain of a real domain I own.

So if I own e.g. company.com, then for the internal network I use internal.company.com. I know this will never conflict with anybody else, I do not publish this domain anywhere outside on the Internet, therefore I will not have leaks of any kind ... perfect solution but for the slightly longer FQDNs.

Also *.internal.company.com works with certificates as well as with MS Active Directory. Using your official Internet domain company.com with AD leads to all sorts of unexpected constraints.

HTH,
Patrick

Thanks for the great tip about browsers possibly having an issue with .localdomain 👍
#3
Quote from: Ground_0 on May 21, 2025, 05:10:04 PMThank you meyergru and gspannu for the straightforward answers, they help immensely for my style of connecting the dots.
And, thank you for your patience; I do realize I don't really belong here and I appreciate your kind assistance.
Although I can gather facts and knowledge, I freely admit that I lack the level of intelligence for a deep insight into networking.
Trying not to be a help vampire.

Anyone who uses OPNsense belongs here... let no one make you think otherwise !
#4
QuoteOk, I find myself confused about this, again.
If I have no VLANs and I am simply using the OPNsense default ".localdomain" for my LAN, would you recommend I be using .localdomain or lan.internal?


You can use either of the two... both will work.
#5
Quote from: meyergru on May 13, 2025, 08:56:52 AMConstructive criticism or suggestions for improvements are not bad at all. I do this all the time and also did it on this topic, because I think that the DHCP options could be made more user-friendly. The amount of comments about DNSmasq seems logical to me, because there are some areas that could be improved, as the Github issues section also shows.

It is more the constant whining about how bad this and generally showing an egoistic attitude (I want to have it right now) won't help.

I think some people should start by understanding how things like Proxmox and OpnSense work: If you want great software for free, you have to put in some effort, like accepting to use the less proven und in some respects "immature" community version.

If you want to have it another way, get ready to pay for the business version and then you may start complaining, preferably directly to the manufacturer.

And as mentioned: With this specific topic, there is even less reason to complain, because DNS and DHCP still works with ISC DHCP and Unbound.


👍
#6
Quote from: xofer on May 13, 2025, 11:35:39 AMAfter upgrade 25.1.5_5 -> 25.1.6_4 we noticed that Dnsmasq now tries to load /usr/local/etc/dnsmasq.conf.d/* while previously it loaded only *.conf

If there are files it cannot parse in this folder, Dnsmasq service fails to start.

I am not sure if it is an intentional change as /usr/local/etc/dnsmasq.conf.d/README still talks about .conf files:
# Dnsmasq plugin directory:
# Add your *.conf files here, read in alphabetical order

Yes, this is a bug and did not exist prior to 25.1.6 release.

Best is to raise this on Github... so that it can hopefully be fixed in next iteration
#7
Quote from: meyergru on May 12, 2025, 09:46:02 PMAt this time, ISC DHCP plus Unbound is still viable, so if anyone deems other (new) combinations of services to be too unstable as of yet: stay with something that still works fine. If you used the business version, which is more matured and lags behind the community version, you would automatically be at this point, anyway. So, if you expect production-ready quality - please buy it!

Other than than, who would really use DNSmasq DHCP, but expect Unbound DNS to be supported registering DNSmasq leases, when DNSmasq supports this out-of-the-box?

As I noted, DNSmasq alone can handle DHCP, (local) DNS and RA, and also non-recursive DNS. If you really need recursive DNS or want DoH on top, you are free to choose Unbound (as is the current recommendation) or, if you do not like that (as myself), go along with something like DNSCrypt-Proxy. I just tried that and it also works just fine.

Like @Monviech said: It is just anybody's choice on what to use, IDK why there seems so much undeserved fuzz made about it.

I, at least, appreciate the effort to have those services integrated more closely - but I do not expect it to be perfect from the get-go.


Very well said, @meyergru

I too do not understand what the fuss is all about at the moment. There are choices available; and the best part is if one does not change anything and just upgrades - everything works anyway and the existing setups remain as they were.

Do not understand the amount of comments being made about dnsmasq. It is just being improved without any detriment to either ISC/Kea at the moment.
#8
Quote from: franco on May 08, 2025, 04:01:51 PM> Unclear and contradictory ideas in the management of DHCP in Opnsense by the developers.

That's unfair and untrue.  ISC discontinued DHCPD and left everyone with Kea, but it's not as good as DHCPD still is.  Period.


Cheers,
Franco

100% agree with Franco.

The comment "Unclear and contradictory ideas in the management of DHCP in Opnsense by the developers" is not justified and rude to the development team.

The dev team tries very hard to support both personal users & large users - and each has different requirements.

ISC discontinued DHCPD; and a good choice at that time was Kea.
However, Kea is not very well suited for smaller users; and neither did Kea really develop into a full fledged dnsmasq alternative.

What we have today is a plethora of choices:
- ISC (as is)
- dnsmasq (with dhcpd now!)
- Kea (with IPv6 now!)

Unbound continues to work as is.

What could be better? Everyone has a choice ! Use whatever you fancy and whatever works best for your use case/ environment.

The fact that dnsmasq will be the default in 25.7 is really a non-issue. Everything that existed is still being supported.

Thank you @franco, @monviech(cedrik), @patrick and all contributors for this wonderful software and your hard work.
#9
Quote from: franco on April 30, 2025, 12:21:44 PMWait for 25.1.6 next week or use the development version which is very easy to install.


Cheers,
Franco

Awesome... thanks for the update.
#10
Quote from: newsense on April 20, 2025, 02:21:27 AMUntil hearing otherwise and should there be no critical issues discovered last minute I would still expect it Wednesday-Thursday next week in 25.1.6

Any news...
I too am keenly looking forward for the `dnsmasq dhcp` features to drop, so that I could start setting up everything. I know dnsmasq-dhcp is available in the dev build, but wanted to avoid going that route...
#11
Have you tried playing with the OPNsense GUI > Settings > Administration > Console

I had to set the Secondary Console to Serial Console and the Serial Speed to 115200 and it worked !

#12
Quote from: cami09 on March 23, 2025, 03:22:56 PM"strict-order" does not work at all for my case:

server=127.0.0.1#5335
strict-order
server=/mydomain.com/8.8.8.8

I'd expect dnsmasq to only forward queries to 8.8.8.8 for mydomain.com here, but Unbound (running on port 5335) is used as well - mydomain.com also appears in its log file.

Did you do something apart from above config?

It might also be the combination of conditional forwarding + generic `server` directive, but this setting doesn't seem to be mature enough.


I think the dnsmasq settings will (hopefully) all be sorted in next few OPNsense builds, as dnsmasq support in OPNsense is going through major development.

To assist you in your queries, could you help me understand your setup?
- Why is your exact need for strict-order?
If you are trying to specify different servers for different domains, then do this in the GUI itself. You can manage your setting in the GUI itself and should not require a custom .conf file.
- Also, if you need to specify strict-order, do this in the GUI itself (not in the custom .conf file). OPNsense does not work well with custom definitions that already exist in the GUI.

Share some more details about your end objective, and I will try and help with your setup...
#13
Quote from: epoch on March 21, 2025, 11:40:03 AMHi. I hit this pretty crippling bug after upgrading

I concur with user gspannu. The solution for me was to edit every line of the domains tab that included the exclamation mark, and save it without any change. That removed the ! character from the domains tab and allowed dnsmasq to start

When editing, removing ! does not work bc an empty field is not allowed. Replacing ! with a blank allows saving but I did not check if dnsmasq would work in this case

The help tips are not in line with what's required of the user

Thanks to all!

You can still enter the ! character and hit Save. The issue only happens when you are upgrading to 25.x. The ! will be accepted but not shown once saved.
#14
Quote from: roman6904 on March 20, 2025, 02:01:05 PMHa! I can't believe that didn't occur to me. Thank you both very much, the world once again makes sense! The testers for quad9 and cloudflare indeed show I am using their services (after I isolate them to make sure I'm only using one). Thanks again!

Just another observation... unrelated to your actual question however.

You are using AGH as your primary resolver on Port 53 to forward your queries to Unbound which then again forwards your queries to upstream servers at 9.9.9.9/ 1.1.1.1

You maybe better off by specifying the upstream servers in AGH itself (and remove the extra Unbound hop) and achieve the same end result.

In AGH > Settings > DNS Settings

1) Upstream DNS servers:

#Add or remove upstreams as appropriate
tls://one.one.one.one
https://dns.google/dns-query
https://cloudflare-dns.com/dns-query
quic://unfiltered.adguard-dns.com
# ————- #
# Local resolution via Unbound on Port 5353
[//]127.0.0.1:5353
[/use-application-dns.net/]127.0.0.1:5353
[/dns.resolver.arpa/]127.0.0.1:5353
[/in-addr.arpa/]127.0.0.1:5353

2) Private reverse DNS servers

127.0.0.1:5353

3) Use private reverse DNS resolvers: Checked

4) Enable reverse resolving of clients' IP addresses: Checked

This helps you avoid the unnecessary Unbound hop for external dns resolution, but will use Unbound for local client resolution.



However, if your intent was to use Unbound as a recursive authoritative DNS server; then you should keep your setup as is, but remove the DNS TLS entries (9.9.9.9:853/1.1.1.1:853) in Unbound settings and let Unbound resolve the queries itself (without sending these upstream).



Hopefully, gives you some food for thought...
#15
Quote from: Monviech (Cedrik) on March 14, 2025, 08:53:26 PMLike said in github, please create a issue with a feature request for these options.

They seem generally useful yet if you always ask between the lines it wont get added since theres no ticket to solve.

As advised, I have just created a ticket on GitHub requesting the GUI features.

Many thanks for your support.