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 - cami09

#1
Yes, ipset is part of Linux Netfilter: https://en.wikipedia.org/wiki/Netfilter#ipset

dnsmasq under (Free)BSD just re-uses this name in the config file, but internally implements ip-based storage via BSD's Packet filter (PF) tables. And OPNsense itself can reference PF tables via external firewall alias.

Not sure (and also wondered), where this documentation is. But I can confirm it definitely works. There already was a post in this forum, let me search for it.

// Edit
https://github.com/opnsense/core/issues/4145#issuecomment-1208889357
https://forum.opnsense.org/index.php?topic=27650.0

// Edit 2:
To clarify, as terminology is a bit confusing: ipset and PF don't work together. Rather dnsmasq uses a different implementation under BSD (PF tables) than under Linux (ipset) to manage IP sets. dnsmasq in BSD just re-uses the term "ipset" to refer to general concept of fast IP lookup storages.
#2
Yes, indirectly I would say 😉 . dnsmasq basically leverages BSD PF tables (for OPNsense) to store resolved IPs, which can be referenced in OPNsense firewall rules via external alias.
Great thing is, this allows for domain-based tracking and filtering, no need to deal with hardcoded IPs, or IP white-/blacklists (*that* is the mess in my view).
#3
Quote from: Patrick M. Hausen on March 24, 2025, 09:25:23 AMWhy not place the domain override in unbound instead of DNSmasq?

Indeed a good suggestion, thanks! I will investigate this case, too.

The only downside is, that config now is scattered across dnsmasq and Unbound.
To elaborate: There is custom processing logic for specific domains in place, which includes a) forwarding requests to different DNS server b) firewall rules for resolved IP via ipset.
In dnsmasq it looks like this:

ipset=/mydomain.com/ipset-mydomain-com
server=/mydomain.com/8.8.8.8

With Unbound domain override, filtering logic about mydomain.com etc. would now reside in two different places (not DRY).
Nonetheless it certainly appears to be a reasonable workaround to mitigate dnsmasq issues in short-term.

Btw I am using dnsmasq mainly for its great ipset feature. Unbound now seems to support ipset via compile flag `--enable-ipset` as well: https://fossies.org/linux/unbound/doc/README.ipset.md, https://github.com/NLnetLabs/unbound/blob/master/ipset/ipset.c . Credit to post from different forum: https://community.ipfire.org/t/unbound-with-ipset-support/13140  Maybe that could be useful addition for OPNsense.
#4
Appreciate the quick feedback from both of you.

Quote from: gspannu on March 23, 2025, 08:06:00 PM- Why is your exact need for strict-order?
If you are trying to specify different servers for different domains

Yes, exactly.
Conceptually I have two mutually exclusive cases: 1) forward to local Unbound as default, except 2) specific domains get conditional forwarding.
Optimally dnsmasq should only forward to 8.8.8.8 for mydomain.com and not use generic server=127.0.0.1#5335, if there already is a conditional forwarding match.
Unfortunatelly there seems no setting for this, so strict-order is best option we have right now.

I am using a custom config file /usr/local/etc/dnsmasq.conf.d/custom.conf as well.

Quote from: gspannu on March 23, 2025, 08:06:00 PMdo 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.

Good idea. So basically you are suggesting
 
- Services -> Dnsmasq DNS -> Query DNS servers sequentially (Enabled)
- Services -> Dnsmasq DNS -> Domains
  - First entry
    Domain: mydomain.com
    IP address: 8.8.8.8
  - Second entry
    Domain: *
    IP address: 127.0.0.1
    Port: 5335

I somewhere read about * / asterisk support in UI, so I'd imagine this entry will mimic server=127.0.0.1#5335?
What also would be nice to know: Are entries are processed from top-bottom or reverse? There are controversial discussions...

Regarding custom config file issues:
Did only /usr/local/etc/dnsmasq.conf.d/0-custom.conf cause problems for you, or also using default /usr/local/etc/dnsmasq.conf?
I definitely still need a custom config file, as dnsmasq's ipset functionality cannot be configured within OPNsense web interface.

Also thanks for mentioning the changelog, good to know there are continuing improvements. Not sure though, what the relevant feature/fix for OP case is.
#5
"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.
#6
Big thank you first!

Now a question: what is the best practice in case of multiple (Mullvad) WiregGuard instances?

When doing step 5 with a second instance:
| IP Address                      | .conf > [interface] > address (-1)*               |
| Monitor IP                       | 10.64.0.1 or one of the DNS servers              |

I get errors
> This Gateway IP address already exists.
> This Monitor IP address already exists.

For GW IP, we probably can just decrement one more: address (-2), ... , address (-n).
But what should I configure for "Monitor IP", given DNS IP is always the same?
#7
Thanks for yours suggestions.

*Regarding DHCP/VLAN:*
I forgot to add one thing - conditional forwarding should be done for specific clients *and* domains.
Hence DNS server assigned over DHCP or enforced DNAT of all requests to a DNS server is not suitable here.

*Regarding external server:*
OPNsense is my main router and a firewall rule is created based on ipsets (using alias with type "External").
So, DNS resolver needs to reside within same machine to fill this corresponding BSD `pf` (Packet Filter) table for ipsets.

---

In dnsmasq you can do:
```
server=/example.com/1.1.1.1         # forward domain example.com to 1.1.1.1 DNS
ipset=/example.com/my_whitelist_alias         # whitelisting IPs with firewall rule
```
But this misses forwarding decisions based on client IP - and dnsmasq can't do that to my knowledge.
After more research: dnsmasq at least seems to be able to forward the original client IP via `--add-subnet=32,128`, which is ECS (https://en.wikipedia.org/wiki/EDNS_Client_Subnet). So it might delegate this job to another resolver like BIND.

1. Is os-bind (BIND) plugin mature enough and safe to use? I'd like to not resort to external plugins, where possible - but if that's the way, I am OK with it.
2. Can BIND plugin configure a view based on this original IP delivered over ECS?
3. Alternatively: any experience with starting a second dnsmasq instance manually? Does OPNsense UI provide a way to configure CLI startup/boot scripts?
#8
Hi, I have two basic requirements in my home-lab:

1. conditional forwarding of DNS requests to different servers, depending on client IP
2. firewall rule with whitelist of IPs, whose domains were resolved by my DNS server       

Specific clients should be forwarded to different DNS servers, e.g. the one from VPN (might also be called source IP-based forwarding of DNS requests).                         
The firewall rule is usually done via ipsets/nftsets (I've read the implementation on FreeBSD are pf tables).             

Some thoughts on possible solutions:             
- Unbound can act as recursive resolver, but neither supports ipset nor source-based IP forwarding
- dnsmasq supports ipset, but no source-based IP routing; also only DNS forwarder
- BIND to my knowledge supports conditional forwarding of source IPs via views, but no ipset support; also only plugin and not part of core OPNsense

So, what I am doing now is using dnsmasq together with Unbound:       
Client -> dnsmasq (forwarder) -> Unbound (rec. res.) -> nameservers (Inet)

I am missing conditional forwarding here. On first sight, we could use BIND:       
Client -> dnsmasq (forwarder) -> BIND -> Unbound (rec. res.) -> nameservers (Inet)

But that probably doesn't make so much sense, as BIND gets the source IP from downstream dnsmasq, not the original client IP.

That leaves one remaining solution: spawn an additional dnsmasq instance for conditional forwarding (given two groups of clients).
Having explored OPNsense web GUI, it seems I can only have one instance of dnsmasq though.
 
Hence, not sure, what is the best solution here. Any thoughts?
#9
Hm still no solution. Might this be a OPNsense (and/or Unbound) bug?
Imagine your internet being disrupted for a couple hours or so, and you are not able to resolve local host names, despite having a local resolver responsible for this private domain.
I can't believe, DNSSEC would not support such cases - just want to ignore for private domain.
#10
Hi together,

I am currently using a private, LAN-only domain "home.arpa" with Unbound recursive resolver and DNSSEC for validation of public domains.
First off, this setup works well most of the time: Public domains supporting DNSSEC are answered with SECURE, others with INSECURE. Besides, DNSSEC responses for home.arpa addresses are labeled as INSECURE and just work.

Issues arise, when upstream internet router is powered off periodically for some hours: In this time (after cache invalidation), not only public names like NTP domains are not resolved: responses to *internal* hostnames like mail.home.arpa are also discarded as BOGUS (refused upstream) with SERVFAIL. For example this leads to batch jobs not sending mails.

My assumption so far is (no expert, please correct me): DS record from arpa. cannot be fetched, which leads chain to invalidate sub-domain home.arpa.
But settings "Private Domains" and "Insecure Domains" under Unbound tab are already set to home.arpa.
Hence I am asking: Isn't the purpose of these settings to ignore any missing/invalid DNSSEC report for home.arpa, or am I missing some setting?

Current setup:
- System - Settings - General
    - Domain: home.arpa
- Services - Unbound DNS
    - General
        - Enable DNSSEC Support: checked
        - Local Zone Type: static
    - Advanced
        - Private Domains: home.arpa
        - Insecure Domains: home.arpa
        - Harden DNSSEC Data: checked
        - Aggressive NSEC: checked

OPNsense 24.7.10_2

Thanks for any hints.