"Recent posts
#1
German - Deutsch / Re: Problem: guce.yahoo.com wi...
Last post by patient0 - Today at 09:39:48 PMQuote from: feofan69 on Today at 09:01:33 PMDNS‑Abfrage über Unbound (drill guce.yahoo.com @127.0.0.1) → liefert NXDOMAINMachst Du diese Anfrage auf der Sense oder auf dem Klient? Wenn auf dem Klient, dann mal mit 'drill guce.yahoo.com @<OPNsense IP>' versuchen
#2
German - Deutsch / Re: Problem: guce.yahoo.com wi...
Last post by feofan69 - Today at 09:26:25 PMJa.
Da wird aber diese Seite nicht geblockt. Da habe ich sogar als "Allowlist Domains" eingetragen. Und in Reporting von ubound steht "PASS"
Da wird aber diese Seite nicht geblockt. Da habe ich sogar als "Allowlist Domains" eingetragen. Und in Reporting von ubound steht "PASS"
#3
German - Deutsch / Re: Problem: guce.yahoo.com wi...
Last post by Patrick M. Hausen - Today at 09:21:00 PMBlockliste(n) aktiv?
#4
German - Deutsch / Problem: guce.yahoo.com wird v...
Last post by feofan69 - Today at 09:01:33 PMHallo zusammen,
ich habe ein Problem mit der DNS‑Auflösung der Domain guce.yahoo.com.
Die Seite wird bei mir nicht aufgelöst.
Meine aktuelle Konfiguration:
Unbound ist als Resolver aktiv
Als Upstream‑DNS‑Server sind 1.1.1.1 und 8.8.8.8 eingetragen
DNSSEC Support ist aktiviert
Blocklist ist aktiviert
Ich bin mir unsicher, wie ich in diesem Fall am besten bei der Fehlersuche vorgehen soll.
Folgendes habe ich bisher getestet:
DNS‑Abfrage über Unbound (drill guce.yahoo.com @127.0.0.1) → liefert NXDOMAIN
DNS‑Abfrage über Cloudflare (drill guce.yahoo.com @1.1.1.1) → liefert die korrekten CNAME‑ und A‑Records
Hat jemand eine Idee, wie ich weiter vorgehen kann oder woran es liegen könnte?
Vielen Dank!
ich habe ein Problem mit der DNS‑Auflösung der Domain guce.yahoo.com.
Die Seite wird bei mir nicht aufgelöst.
Meine aktuelle Konfiguration:
Unbound ist als Resolver aktiv
Als Upstream‑DNS‑Server sind 1.1.1.1 und 8.8.8.8 eingetragen
DNSSEC Support ist aktiviert
Blocklist ist aktiviert
Ich bin mir unsicher, wie ich in diesem Fall am besten bei der Fehlersuche vorgehen soll.
Folgendes habe ich bisher getestet:
DNS‑Abfrage über Unbound (drill guce.yahoo.com @127.0.0.1) → liefert NXDOMAIN
DNS‑Abfrage über Cloudflare (drill guce.yahoo.com @1.1.1.1) → liefert die korrekten CNAME‑ und A‑Records
Hat jemand eine Idee, wie ich weiter vorgehen kann oder woran es liegen könnte?
Vielen Dank!
#5
26.1, 26,4 Series / WireGuard does not start after...
Last post by Lucid1010 - Today at 07:14:16 PMYou cannot view this attachment.
You cannot view this attachment.
An error occurs on the WireGuard peer configured for selective routing, and it does not start after boot. If the service is restarted manually, it works correctly.
You cannot view this attachment.
An error occurs on the WireGuard peer configured for selective routing, and it does not start after boot. If the service is restarted manually, it works correctly.
#6
Intrusion Detection and Prevention / Re: Performance tuning for IPS...
Last post by Seimus - Today at 06:56:19 PMSome tunables are specific those per NIC. So you need to know what nic you use for example if you have ax than tunables with igc will not do anything.
If a tunable is not anymore available in FBSD, than in the UI it will be flagged and you will see a message next to the tunable that is unknown or something like that.
Regards,
S.
If a tunable is not anymore available in FBSD, than in the UI it will be flagged and you will see a message next to the tunable that is unknown or something like that.
Regards,
S.
#7
General Discussion / Re: software cost of opnsense ...
Last post by sopex - Today at 06:12:56 PMYou can always just buy a license if you plan to use it longish term. No? At around 4 months, you break even.
But I believe it as the automatic table mentions $0.05/hour + Azure infrastructure costs
But I believe it as the automatic table mentions $0.05/hour + Azure infrastructure costs
#8
26.1, 26,4 Series / Re: Been driving me mad STAFF ...
Last post by Orionrise - Today at 06:11:27 PMUpdate after a day of further testing — fault persists, but I've ruled out several more things.
1. Firmware — both ends now fully current.
Patched OPNsense to the latest 26.1.9 and rebooted. Confirmed "no updates available on the selected mirror." Also checked the switch (UniFi USW-Pro-Max-16): on the latest firmware (7.4.1), nothing pending. So both the firewall and the switch are fully up to date, and the STAFF DNS fault is unchanged after patching.
2. Tag-change diagnostic — it's NOT tag-specific.
On the theory that something might be keyed to VLAN tag 20 specifically, I moved STAFF off tag 20 onto an unused tag (25) — changed it on both the OPNsense VLAN device and the matching UniFi network, so both ends matched.
Result: the STAFF client leased correctly on the new tag (got 192.168.20.50, gateway/DNS 192.168.20.1, fresh lease from the firewall — so DHCP flows fine on tag 25), but DNS to the gateway failed identically. nslookup google.com (to 192.168.20.1) timed out exactly as before, while nslookup google.com 1.1.1.1 (forcing an external resolver) resolved fine.
So the fault follows the STAFF interface onto a completely different tag. It is not the tag number, and combined with the earlier full delete/recreate of the interface, it's not a corrupted interface either. I've since reverted STAFF back to tag 20.
3. Where that leaves it.
To summarise everything ruled out now: firmware (both ends current), VLAN tag number, interface recreate, switch config and health (trunk is tagged-only, native VLAN None, port health clean), no gateway attached to any VLAN interface, and the STAFF interface is configured identically to MGMT (which works) apart from IP and tag. Both ride the same igc0 parent. DHCP and external-resolver DNS work through STAFF; only unicast DNS to the firewall's own STAFF IP fails, with no pf verdict logged.
Still completely stuck and very happy to provide pfctl output, full config, or further captures. Thanks all for the input so far.
1. Firmware — both ends now fully current.
Patched OPNsense to the latest 26.1.9 and rebooted. Confirmed "no updates available on the selected mirror." Also checked the switch (UniFi USW-Pro-Max-16): on the latest firmware (7.4.1), nothing pending. So both the firewall and the switch are fully up to date, and the STAFF DNS fault is unchanged after patching.
2. Tag-change diagnostic — it's NOT tag-specific.
On the theory that something might be keyed to VLAN tag 20 specifically, I moved STAFF off tag 20 onto an unused tag (25) — changed it on both the OPNsense VLAN device and the matching UniFi network, so both ends matched.
Result: the STAFF client leased correctly on the new tag (got 192.168.20.50, gateway/DNS 192.168.20.1, fresh lease from the firewall — so DHCP flows fine on tag 25), but DNS to the gateway failed identically. nslookup google.com (to 192.168.20.1) timed out exactly as before, while nslookup google.com 1.1.1.1 (forcing an external resolver) resolved fine.
So the fault follows the STAFF interface onto a completely different tag. It is not the tag number, and combined with the earlier full delete/recreate of the interface, it's not a corrupted interface either. I've since reverted STAFF back to tag 20.
3. Where that leaves it.
To summarise everything ruled out now: firmware (both ends current), VLAN tag number, interface recreate, switch config and health (trunk is tagged-only, native VLAN None, port health clean), no gateway attached to any VLAN interface, and the STAFF interface is configured identically to MGMT (which works) apart from IP and tag. Both ride the same igc0 parent. DHCP and external-resolver DNS work through STAFF; only unicast DNS to the firewall's own STAFF IP fails, with no pf verdict logged.
Still completely stuck and very happy to provide pfctl output, full config, or further captures. Thanks all for the input so far.
#9
26.1, 26,4 Series / Re: CVE-2026-45257
Last post by viragomann - Today at 06:10:38 PMAhh. Thank you!
I searched the release notes for "kernel", but didn't find anything regarding this.
I searched the release notes for "kernel", but didn't find anything regarding this.
#10
26.1, 26,4 Series / Re: CVE-2026-45257
Last post by sopex - Today at 06:06:24 PMQuote from: franco on Today at 05:18:39 PMNo, these are not our CVEs.
I meant something along the lines of
"This business release is based on the OPNsense 26.1.9 community version with additional security and reliability improvements." because this person probably got a bit overwhelmed with all the improvements on the new version.
We are in a CVE apocalypse ofcourse no need to micromanage each security fix :)
