Messages

Add a tunable:
hw.pci.honor_msi_blacklist=0

(See e.g. https://forum.netgate.com/topic/157688/remove-vmware-msi-x-from-the-pci-blacklist)

Any plans to impelement automatic snapshots before any opnsense-code or opnsense-update? I saw this on TrueNAS.

Same mechanics (automatic boot environment creation upon pkg updates) are in Illumos/OmniOS; and probably in FreeBSD itself, too. So maybe some code / concepts can be re-used for this.

There is no easy interface for unbound DNSBL.

Better install adguard home from the community repo - it offers similar functionality to pihole, including a nice Interface.

Not an unbound issue - it only does DNS. And your resolves work apparently.

Do you use IP blocklists?

*push* - This would certainly help with keeping a "whitelist" of IP addresses that should not be blocked by IP blocklists.

I had some github.com IPs showing up on some IP blocklists I used for example.

Works fine for me (latest opnsense version); these are the public NTS servers known to me:

Name/IP address             Mode KeyID Type KLen Last Atmp  NAK Cook CLen
=========================================================================
time.cloudflare.com          NTS     3   15  256   4d    0    0    8  100
sth1.nts.netnod.se           NTS     1   15  256   8d    0    0    8  100
sth2.nts.netnod.se           NTS     1   15  256  10d    0    0    8  100
ptbtime1.ptb.de              NTS     1   15  256  10d    0    0    8  100
ptbtime2.ptb.de              NTS     1   15  256  10d    0    0    8  100
ptbtime3.ptb.de              NTS     1   15  256  10d    0    0    8  100
nts1.time.nl                 NTS     1   15  256  10d    0    0    8  104
nts.ntp.se                   NTS     1   15  256  10d    0    0    8  100
ntp1.glypnod.com             NTS    19   15  256 447m    0    0    3  104
ntp2.glypnod.com             NTS     1   15  256   7d    0    0    8  104
ntpmon.dcs1.biz              NTS     1   15  256   7d    0    0    8  104

Cloudflare could be blocking it.

But what's stage is that you seem to be able to ping it under its domain name, so it does get resolved?

Anyway, since I had my own issues with unbound: check whether strict qname minimisation is enabled and if so turn it off - it's a likely culprit.

Thanks but that's not it - the option is unchecked..

Probably more of a firewall issue I guess?

To be more specific, chrome could be using DoH = DNS over Https, which would bypass your redirect of port 53 traffic.

Also consider that you may need to block/redirect ports 784 / 853 (?) For DNS over Quic / TLS traffic.

Thank you both! Indeed I have strict QNAME minimisation enabled.

Going on holiday this weekend so will only be able to follow up later, but thank you very much for the pointers!

Thanks -

1. I was afraid of this question - it was a website for Germany's far-right party (I don't like them, I did not vote them, but I had to look up their site nonetheless). Need to reset Unbound to resolver mode to check.

I have also had these issues, I think, with Apple and Microsoft sites (though no DNSBL enabled).

I have Adguard Home as primary DNS on :53 which then forwards to unbound at 127.0.0.1:5553.

Response seen in Adguard Home e.g. for www.bing.com:

Response details
Status
Allowed
DNS server
127.0.0.1:5553
Elapsed
115 ms
Response code
NXDOMAIN
Rule(s)

www.bing.com
hl2guide

Response
CNAME: a-0001.a-afdentry.net.trafficmanager.net. (ttl=21600)

Later Adguard shows proper resolution:

Response details
Status
Allowed
Elapsed
0.06 ms
Response code
NOERROR
Rule(s)

    www.bing.com
hl2guide

Response
CNAME: a-0001.a-afdentry.net.trafficmanager.net. (ttl=60)
CNAME: www-bing-com.dual-a-0001.a-msedge.net. (ttl=60)
CNAME: dual-a-0001.a-msedge.net. (ttl=60)
A: 13.107.21.200 (ttl=60)
A: 204.79.197.200 (ttl=60)

2. Statistics got reset to zero and resolve times shot up again. So: No thorough checking.

[I see "ca.pem" being copied over]

Unfortunately (1) that is not my issue and (2) the error persists (on 21.7.2).

The key pair and scp/sftp work.

I see "ca.pem" being copied over, and the upload test manages to put the test file on the sftp server:

[root@esxi:/etc/vmware/ssl] ls -la
[...]
-rw-------    1 root     root            11 Sep 11 20:40 sftp-upload-4Q85Il
-rw-------    1 root     root            11 Sep 11 20:40 sftp-upload-HC3pkO
-rw-------    1 root     root            11 Sep 11 20:39 sftp-upload-Q5ZeG2

[root@esxi:/etc/vmware/ssl] cat sftp-upload-Q5ZeG2
upload-test

The issue seems to be that the upload script fails to execute the proper command on the sftp server (ESXi) / that ESXi does not support fsetstat:

2021-09-11T22:23:26   opnsense[84570]   /usr/local/opnsense/scripts/OPNsense/AcmeClient/upload_sftp.php: Failed uploading file '/tmp/sftp-upload-YzGRyN' to 'ca.pem' ; Cause: {"file_not_found":true,"error":"Couldn't fsetstat: No such file or directory"}

How can I get the ACME client to execute a a short script to scp the files over? i.e. how do I change the "Run Command" of the ACME client from the limited pre-defined actions to executing a local script?

Redirecting DNS to 127.0.0.1 seem to fail for me:

Whereas a redirect to the relevant LAN/VLAN's gateway (e.g. 192.168.1.1:53) works, a redirect to 127.0.0.1:53 does not:

nslookup www.ft.com ns2.google.com.
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  216.239.34.10

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown.

The DNS request shows up in my (adguard home) logs, but apparently the response to my client is faulty.

If redirecting to 192.168.1.1, the redirect works and the client "does not notice":

nslookup www.ft.com ns2.google.com.
Server:  ns2.google.com
Address:  216.239.34.10

Nicht autorisierende Antwort:
Name:    ft2.map.fastly.net
Addresses:  151.101.2.209
          151.101.66.209
          151.101.130.209
          151.101.194.209
Aliases:  www.ft.com

What could be the reason?

Redirecting to 127.0.0.1 would be favourable as I could apply it globally to all local LAN/VLAN/VPN interfaces, whereas redirecting to a gateway address would require individual rules for each interface (bleh!).

[un]

While running Unbound as a local resolver, I had come across three issues:

1. Unbound fails to resolve certain domains. I have no DNSBL in Unbound. Unbound only delivers the CNAME, but no A record. When using Unbound as DoT forwarder, it resolves the hostname normally.

2. Even though I have unchecked "Flush DNS cache during reload", the statistics and cache are cleared with every Unbound reload. This should not happen.

3. Unbound failing to start, see https://github.com/opnsense/core/issues/5150 -  I don't experience this anymore, though.

Has anyone experienced similar issues or could suggest possible (configuration) errors?

Had the same issue. It can be resolved as follows:
- disable VLAN hardware filtering. REBOOT (!!).
- enable IDS, enable promiscuous mode and only apply IDS on physical interfaces.

Then it works.

Can't stress the "REBOOT" bit enough.