Messages

Bumping this - same issue here.

Also, suricata still throws alerts for ET_info although I removed (disabled) that ruleset ..

Ntopng should be able to meet OP's requirements?

In the meantime, you can also have suricataog events as JSON and alert yourself per email through monit (monitoring the JSON file). There is documentation floating around. I could also dig up the config later tonight if needed.

Unfortunately, no - would be great to get this to work somehow!

This has been fixed in 22.1: https://github.com/opnsense/core/issues/5396

Easiest is to use Adguard Home (from the community repo) in place of pihole.

Adguard Home can do all that pihole can, including EDNS, and you can run it all on one box.

"Chaining" pihole or AGH to unbound does not make sense if you want to use EDNS: EDNS is only relevant if you forward queries, not if you run a full resolver (which is standard behaviour for unbound).

AGH can do split DNS and EDNS and caching, so you could use that to (1) forward local queries to unbound and (2) everything else directly to an upstream resolver with EDNS.

Note that EDNS breaks your privacy, though.

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