Messages

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

Maybe new problem: Since yesterday, my Suricata instance (on 21.7.3_3) no longer updates the rules - neither the cron job nor a manual "Download & update rules" does anything.

I added a few rule categories yesterday and "enabled" and "saved" them. Since then -> downloads don't work.

--

EDIT: The issue was the "OPNsense-App-detect/test" rule. Once I disabled that, the rules would download again.

The ACME plugin sftp automation only permits certificate-based login, not password-based. So you need to set up a ssh certificate login at your target box (guides are available via google).

Attention: The ssh certificate/key you need it not the general OPNsense ssh one, but the specific one for the ACME plugin, found at  /var/etc/acme-client/sftp-config/id.rsa.pub (thanks to https://forum.opnsense.org/index.php?topic=20437.0!).

https://sslbl.abuse.ch/blacklist/ states:

In addition, SSLBL provides a more performant Suricata ruleset that uses tls_cert_fingerprint instead of tls.fingerprint. Please use either the ruleset above (sslblacklist.rules) OR sslblacklist_tls_cert.rules from below. Do not use both of them at the same time.

...

In order to use the more perfomant Suricata ruleset avilable for download below, you must run Suricata 4.1.0 or newer.

https://sslbl.abuse.ch/blacklist/sslblacklist_tls_cert.rules

Would it be possible to replace the current SSLBL ruleset with the more performant TLS ruleset? Or add it as a custom ruleset?

(the "user defined" tab only seems to permit adding custom rules, not custom rulesets)

Bei cloudflare den proxy für eine unterdomain abgeschaltet, zB "wireguard.myTLD.de": no proxy (DNS Einstellungen) und das dann für wireguard verwendet.

Ansonsten: Tailscale anschauen, das müsste dank fremden relay servern auch ohne Offenlegung der eigenen WAN-IP funktionieren.

I've added "hw.pci.honor_msi_blacklist=0" made no real difference.

Apologies - that tunable us only relevant if you pass through a physical NIC to opnsense I believe, so likely would not have effect on vmxnet3 performance.