Messages

Indeed some form of permission error on the SSL cert file:

The following was set:

root@OPNsense:/usr/local/etc # ls -la /etc/ssl/
total 454
drwxr-xr-x 2 root wheel 4 Nov 29 11:30 .
drwxr-xr-x 25 root wheel 99 Nov 25 21:09 .. -
rw-r----- 1 root wheel 698890 Nov 29 11:30 cert.pem
-rw-r--r-- 1 root wheel 10921 Nov 10 11:08 openssl.cnf

with cert.pem set to "rw-r-----", I had the described issues

If the cert.pem is set to "rw-r--r--" (mask 644), chrony can connect to all NTS servers just fine (like before).

Note: under the new 21.7.6, all automations are being reset to "restart GUI".

Since [some time], chrony hardly connects to any servers anymore:

Code Select Expand

MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* time.cloudflare.com           3   6    37    11    -36us[ +469us] +/-   17ms
^? sth1.nts.netnod.se            0   8     0     -     +0ns[   +0ns] +/-    0ns
^? sth2.nts.netnod.se            0   8     0     -     +0ns[   +0ns] +/-    0ns
^? ptbtime1.ptb.de               0   8     0     -     +0ns[   +0ns] +/-    0ns
^? ptbtime2.ptb.de               0   8     0     -     +0ns[   +0ns] +/-    0ns
^? ptbtime3.ptb.de               0   8     0     -     +0ns[   +0ns] +/-    0ns
^- nts1.time.nl                  2   6    37    10  -2907us[-2907us] +/-   39ms
^? nts.ntp.se                    0   8     0     -     +0ns[   +0ns] +/-    0ns
^? ntp2.glypnod.com              0   8     0     -     +0ns[   +0ns] +/-    0ns
^? ntpmon.dcs1.biz               0   8     0     -     +0ns[   +0ns] +/-    0ns
^? netmon2.dcs1.biz              0   8     0     -     +0ns[   +0ns] +/-    0ns
^? sth-ts.nts.netnod.se          0   8     0     -     +0ns[   +0ns] +/-    0ns


I can DNS-resolve all and ping most of the above domains

It seems to be an issue with file access rights? System log shows:

Code Select Expand

2021-12-02T14:15:43 chronyd[5971] Selected source 162.159.200.123 (time.cloudflare.com)
2021-12-02T14:15:41 chronyd[5971] Selected source 94.198.159.11 (nts1.time.nl)
2021-12-02T14:15:36 chronyd[5971] Could not set credentials : Error while reading file.
2021-12-02T14:15:35 chronyd[5971] Could not set credentials : Error while reading file.
2021-12-02T14:15:35 chronyd[5971] Could not set credentials : Error while reading file.
2021-12-02T14:15:35 chronyd[5971] Could not set credentials : Error while reading file.
2021-12-02T14:15:35 chronyd[5971] Could not set credentials : Error while reading file.
2021-12-02T14:15:35 chronyd[5971] Could not set credentials : Error while reading file.
2021-12-02T14:15:34 chronyd[5971] Could not set credentials : Error while reading file.
2021-12-02T14:15:34 chronyd[5971] Could not set credentials : Error while reading file.
2021-12-02T14:15:34 chronyd[5971] Could not set credentials : Error while reading file.
2021-12-02T14:15:34 chronyd[5971] Could not set credentials : Error while reading file.
2021-12-02T14:15:34 chronyd[5971] Source 194.58.202.203 changed to 194.58.202.202 (nts.netnod.se)
2021-12-02T14:15:20 configctl[3020] event @ 1638450920.24 exec: system event config_changed
[ Chrony restart ]

It used to run fine; so I am suspecting the latest updates 21.7.5 or 21.7.6 -- or the recent update of my SSL certificate by the new ACME?

Easiest solution (probably):

1. Enter some DNS servers under System\Settings\General\DNS Servers
2. Tick "Do not use the local DNS service as a nameserver for this system"
3. Now opnsense itself will use the configured ones. Your DHCP clients will still use the DNS server distributed by DHCP, i.e. UnBound/dnsmasq/AdGuardHome/...

(edit: so mostly what cookiemonster already said _but_ entering DNS servers for opnsense upstream use)

I would use Unbound listen to localhost only and System : Settings : General DNS Server empty so it uses unbound. AdGuardHome only listen to LAN address. Should work best

I have not found a way to set this up from GUI unfortunately. Otherwise, would be the "cleanest" IMHO.

In particular, it would still be better to have an internal resolver like Dnsmasq or Unbound that is properly wired to provide the system with a way to resolve DNS during boot up and then rather use port forwards to capture DNS traffic from attached networks to funnel through AdGuard which uses the local service as a forward.

For the time being I have a port forward but the other way round: DNS queries to port 53 _from_ the local firewall get forwarded to Unbound at 127.0.0.1:5553; anything else goes to adguard at 53 first (and Adguard then queries 127.0.0.1:5553).

Franco's reverse setup (unbound at 53, adguard at 5553, NAT port forward ensuring that all client traffic goes to adguard first) probably does not work easily as adguard, as per standard setup, listens on 53 (and you can't change it from GUI)?

Kann ich leider ebenfalls bestätigen für 21.7.4.

Clients lösen per Ping problemlos auf, ein nslookup oder dig scheitert aber auch bei mir - sowohl auf der Opnsense als auch auf clients.

Code Select Expand

root@OPNsense:~ # nslookup photon
Server:         10.10.100.1
Address:        10.10.100.1#53

** server can't find photon: NXDOMAIN

Für IDS brauchst Du keine einzige Policy. Du musst die gewünschten Rules "enable"n und dann "Download"en. Danach gelten die automatisch (so wie halt von Emerging Threats, snort o.ä. eingestellt).

Für IPS brauchst Du ggfs. Policies, um Regeln von alert zu drop umzustellen.

Generell wären IP blocklists in der Firewall performanter und wichtiger als IDS/IPS. Also dshield, Spamhaus drop/edrop, botcc
Etc pp nicht über IDS/IPS tracken sondern direkt durch die Firewall blocken lassen.

Why does OPNsense treat traffic on my WireGuard interface as "in" traffic on WAN?

Code Select Expand

WAN Oct 19 18:08:48 10.10.100.1:5353 224.0.0.251:5353 udp Block private networks from WAN

Code Select Expand

__timestamp__ Oct 19 18:08:48
action [block]
anchorname
datalen 69
dir [in]
dst 224.0.0.251
dstport 5353
ecn
id 46266
interface igb0
interface_name WAN
ipflags none
ipversion 4
label Block private networks from WAN
length 89
offset 0
protoname udp
protonum 17
reason match
rid 1eb94a38e58994641aff378c21d5984f
rulenr 69
src 10.10.100.1
srcport 5353
subrulenr
tos 0x0
ttl 1

This is the mDNS repeater listening on my LAN, VLAN and WireGuard interfaces which all form part of my LocalNet interface group and are generally considered as local interfaces. My OPNsense wireguard interface/endpoint has IP 10.10.100.1.

I would have expected the mDNS repeater repeating DNS traffic emitting from the LAN/VLAN interfaces to the WireGuard interface and vice versa, however this shows as WireGuard mDNS traffic flowing "in WAN" which seems wrong.

Why does this trigger a "WAN in" rule? Seems like a bug to me ....?

Vermutlich NEIN, ausser Du routest auch VLANs über die OPNsense oder hast einen Internetanschluß mit mehr als 1GBit ...

@KHE, THANK YOU - this did the trick!

I had already re-created my LE certificates and done some of the steps recommended on here to get my GUI certificate running again (with the new root certificate), but your and Felix' steps now permit importing the ntopng repo as well!

Du musst auch noch "DNS over TLS" konfigurieren.

Das stimmt nicht. DNSSEC muss auch ohne DNS-over-TLS funktionieren. Die Funktionen haben nichts miteinander zu tun.

@michael_g: Hast Du evtl. "Strict QNAME minimisation" eingeschaltet? Das kann bekanntlich für Fehler bei der DNS-Auflösung sorgen.

Oder evtl. ein Problem mit Deinem DNS-upstream? siehe zB https://github.com/nextdns/nextdns/issues/279 oder https://arstechnica.com/civis/viewtopic.php?t=1138284? Sind IP Fragments erlaubt?

Same error here when trying to add the ntopng repo to a new 21.7.3_3 installation:

(I don't think I had ntopng installed on this OPNsense install before)

Code Select Expand

root@OPNsense:~ # pkg add https://packages.ntop.org/FreeBSD/FreeBSD:12:amd64/latest/ntop-1.0.txz
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
282266456064:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
282266456064:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /O=Digital Signature Trust Co./CN=DST Root CA X3
282266456064:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
pkg: https://packages.ntop.org/FreeBSD/FreeBSD:12:amd64/latest/ntop-1.0.txz: Authentication error
root@OPNsense:~ #

[Interfaces > Settings]

It turned out that the most important setting change to avoid total loss of network connectivity was:

• In Interfaces > Settings set VLAN Hardware Filtering to Disable VLAN Hardware Filtering

One comment: I highly recommend rebooting after disabling VLAN hardware filtering. I gathered from past experience (not sure) that a reboot would be required to apply that setting.

Oder auch per Split DNS:

adguard anweisen, anfragen aus dem zweiten LAN direkt an unbound weiterzuleiten. Via settings -> Client settings -> client per ip net/24 definieren
- "use global settings" abwählen
- kein blocking
- unbound:5353 als upstream

Just guessing: old android version? Then it likely doesn't know the new letsencrypt root certificate