Messages

Hi,

I have Unbound running on my OPNSense and a public mailserver with spamassassin behind.

I noticed log messages on my mailserver like this:

Code Select Expand


Jun 11 06:16:23 net spamd[9635]: check: dns_block_rule URIBL_BLOCKED hit, creating /root/.spamassassin/dnsblock_multi.uribl.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny multi.uribl.com" to disable queries)
Jun 11 06:16:23 net spamd[9635]: check: dns_block_rule RCVD_IN_ZEN_BLOCKED_OPENDNS hit, creating /root/.spamassassin/dnsblock_zen.spamhaus.org (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny zen.spamhaus.org" to disable queries)
Jun 11 06:30:12 net spamd[9635]: check: dns_block_rule URIBL_BLOCKED hit, creating /root/.spamassassin/dnsblock_multi.uribl.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny multi.uribl.com" to disable queries)
Jun 11 08:00:35 net spamd[9635]: check: dns_block_rule RCVD_IN_VALIDITY_CERTIFIED_BLOCKED hit, creating /root/.spamassassin/dnsblock_sa-trusted.bondedsender.org (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-trusted.bondedsender.org" to disable queries)
Jun 11 08:00:35 net spamd[9635]: check: dns_block_rule RCVD_IN_VALIDITY_SAFE_BLOCKED hit, creating /root/.spamassassin/dnsblock_sa-accredit.habeas.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-accredit.habeas.com" to disable queries)
Jun 11 08:00:35 net spamd[9635]: check: dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating /root/.spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
All with different but similar error messages.
Initially I did not have unbound configured but used some default open DNS servers.

Doing a search for the above errors lead into "install a local resolver like unbound". So did I. Same result, just less frequent.

For those who have similar issues, here's the solution.

The root cause is the blacklist queries are coming from very high frequent nameservers like Google (1.1.1.1) or Quad (9.9.9.9) which I had configured as forwarder. And the blacklists saw the queries only from these IPs and blocked them due to high volume.
I noticed this by doing a dig command:

Code Select Expand

root@netp:/# dig @opnsense 2.0.0.127.multi.uribl.com txt +short
"127.0.0.1 -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP: 172.70.241.83]"

So this revealed a Cloudflare IP. But where did it come from?

In my Unbound I had configured forward servers. So my Unbound forwarded all queries to the high volume DNS servers, too.

Obviously using a local cache did not help here.

Finally I configured my Unbound to NOT use any forwarders - or use the local ISP DNS servers.
Once done, the above messages went away and I am back to proper spam protection.

Just in case it helps for some guys searching for the same issue.

/KNEBB

Moin,

ich habe das jetzt nicht geteste und bin mir auch nicht sicher, ob es funktioniert.

Wenn Du (ähnlich einer Failover-Lösung mit zwei WAN Anschlüssen) so konfigurierst, dass Du eine GatewayGruppe baust? Dann sind doch die NEtzwerkkarten definiert und dann ist es doch eigentlich egal, über welches GW er rausgeht. Der Core-Router routet ja dann an die jeweilige NAT-Ip zurück.

Nur als Idee....

/KNEBb

Moin,

hier läuft OPNSense auf einem ThomasKren LE-Server (Celeron J6412 @ 2.00GHz (4 cores, 4 threads)) mit 8G RAM.

Die Speicherauslastung leigt lt. Dashboard bei 48%, die CPU-Auslastung steigt nie über 40%.

Es läuft ein NGINX als Reverse-Proxy, der zwei Ports https:// (via LetsEncrypt) an zwei interne Server per http:// weiterleitet. Funktioniert auch wunderbar.

Ich habe nur mit den URLs Schwierigkeiten.

Im Ideallfall möchte ich für externe als auch interne Zugriffe die gleiche URL verwenden. Das ist natürlich aus zwei Gründen schwierig:
Zum Einen wegen der https:// bvs. http:// Problematik. Beide Anwendungen können kein https. :(
Zum Zweiten wegen den IPs- Ich kann den gleichen Namen intern auf die interne IP zeigen lassen, und extern auf die öffentliche. Nur doof wg. https...

Aktuell habe ich es so, dass ich intern den öffentlichen Namen auch auf die öffentliche IP zeigen lasse und die öffentliche https-URL verwende. D.h. ich greife von intern auf das WAN-Interface der OPNSense zu, diese betreibt den NGINX, der die Anfrage an den internen Server weiterleitet und die Antwort läuft dann ebenfalls wieder via OPNSense/NGINX.
Grundsätzlich funktioniert das, aber die Performanz läßt im Vergleich zum direkten Zugriif doch zu wünschen übrig. Ich vermute, dass das (auch) am NGINX liegt, deshalb die Frage, ob es Optimierungen gibt, so dass die Geschichte etwas schneller vonstatten geht?

danke& Grüße

/KNEBB

Jo, Dein "Modem" ist vermutlich ein Speedport, oder?

Der gibt auf seinem LAN Interface eine IP raus. So wie es aussieht aus dem 192.168.19.0er Netzbereich.

Du darfst also Dein WAN-Interface auf DHCP umstellen und NICHT PPPoE!

Dann sollte das klappen.

/KNEBB

Moin,

ich habe das nun anders gelöst.

Der Nginx macht weiterhin nur https, ohne Umleitung.

Statt dessen habe ich dem internen DNS gesagt, dass der lokale Hostname auf die externe, öffentliche IP zeigt (und nicht auf die interne).

Jetzt kann der Client vom lokalen Netz auf die öffentliche IP des Routers zugreifen mit der gleichen URL wie von Außen. Funktioniert!

Einziger Nachteil: Es geht jetzt auch intern IMMER über die OPNSesnse, aber das wäre es ja auch im anderen Falle gegangen.,

/KNEBB

Hey,

cool& Danke für den Erfahrungsbericht. Ich finde es toll, wieviel Energie Du da reinsteckst  :)

Fazit für mich ist hier aber: "Wer billig kauft, kauft zweimal!", gerade mit den ganzen Dingern, die aus Fernost kommen, habe ich ganz schlechte Erfahrungen gemacht.

Für mich kommen solche Systeme nicht in frage, hier läuft aktuell ein LES v4 von Thomas Krenn, kostet auch nicht viel mehr. Ja, hat nur drei NICs, aber dafür bekommst Du vom Hersteller sogar garantiert, dass das Teil mit OPNSense funktioniert!

Die werden max. handwarm von außen, die CPU-Temperatur ist ca. 68°.
Sind "nur" 8G RAM drinnen, das reicht aber. (kann man aber mit bis zu 32G kaufen)
Was läuft da alles drauf?

• Wireguard statische Verbindugn zur jeweils anderen Kiste
• Wireguard für mac. 4 RoadWarrior
• Unbound
• nginx Reverse Proxy mit LetsEncrypt
• ISC DHCPv4
• LLDP
• ntp
• 5 Netze, via VLAN getrennt

Funktioneirt einwandfrei!

/KNEBB

[Kann ich dem NGINX irgendwie beibringen, dass er bei der Weiterleitung auf HTTPS:// den richtigen Port mitgibt?]

Moin,

aktuell läuft nginx hier als revese Proxy für eine interne Anwendung. Die Anwendung kann kein TSL/SSL/HTTPS!

Nginx ist für Anfragen aus dem Internet davorgeschaltet, nimmt eingehende HTTPS:// Anfragen (via LetsEncrypt Zertifikat) entgegen, entschlüsselt diese und leitet sie problemlos an die interne Anwendung weiter. Funktioniert soweit sehr gut.

Nun wollte ich gerne, dass die Clients, die diese Anwendung nutzen, sowohl von intern als auch extern die gleiche URL nutzen können. DNS soweit kein Problem, das funktioniert. Der Hostname zeigt im Internet auf meine öffentliche IP und intern auf den Server der Anwendung.

Nur habe ich jetzt das Problem mit https:// vs. http://. Intern kann ich kein https:// verwenden, von außen will ich kein unverschlüsseltes http://.

Ich habe nun bei NGINX den Schalter "Nur HTTP" aktiviert. Klappt auch, eingehende (unverschlüsselte) Anfragen werden an https:// weitergeleitet. Nur dummerweise ohne Angabe des Ports. Der umgeleitete https://-Verkehr versucht es also auf dem üblichen 443. Das ist aber nicht der Port, auf dem die Anwendung läuft.

Kann ich dem NGINX irgendwie beibringen, dass er bei der Weiterleitung auf HTTPS:// den richtigen Port mitgibt?

Danke für Ideen!

/KNEBB

WTF?????


I just did (again!) a

Code Select Expand

wg-quick down wg0

followed by

Code Select Expand

ifup wg0
while having a tcpdump running for troubleshoot purposes.

What should I say? Out of sudden it went up and the VPN connection is established.  :o

Hi,

I had Wireguard configured for a while and it was running stable and fine. Now I realized one of my clients (Debian10) lost VPN connection for some reason. So I tried to get it back up but it does not work.

At first I relized it was trying to connect to the wrong IP address (I changed the OPNSense WAN interface to fibre with static IP). But even using the correct OPNSense public IP (no NAT, no port forwarding needed) does not bring up the interface.

Do you guys have some idea how to troubleshoot the WG-connetion and why it does not come up?

I already did enable debug logging on the DEbian system through:

Code Select Expand

echo "module wireguard +p" | sudo tee /sys/kernel/debug/dynamic_debug/control

but using

Code Select Expand

dmesg -wT does not show any further details.

I disabled an re-enabled WG on my OPNSense. No change.
I checked the logs from WG but it does not bring any lights in there:

Code Select Expand

2024-04-04T15:36:27 Notice wireguard wireguard instance RemoteAccess (wg2) started
2024-04-04T15:36:27 Notice wireguard /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: ROUTING: keeping inet default route to xx.yyy.zz.www
2024-04-04T15:36:27 Notice wireguard /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: ROUTING: configuring inet default gateway on wan
2024-04-04T15:36:27 Notice wireguard /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: ROUTING: entering configure using 'opt2'
2024-04-04T15:36:27 Notice wireguard wireguard instance RemoteAccess (wg2) can not reconfigure without stopping it first.


On the client I can do a

Code Select Expand

wg:

Code Select Expand

root@debian:~# wg
interface: wg0

No further details.

I even rebooted the client several times but no chance to get the wg0 interface up and running.


How can I check more in detail what is going on here?

Thanks a lot!

/KNEBB

Moin,
kann ich (wenn ja, wie?) mit Unbound unterschiedliche Views einrichten?

Also sollen z.B. Anfragen aus dem 5er Netz eine Domainweiterleitung bekommen, Anfragen aus dem 10er Netz aber nicht.

Ich habe nur sowas wie Sperrlisten und Zugriffslisten gefunden, aber das scheint nur pauschal zu erlauben bzw. verbieten.

Tipps?

/KNEBB

Ok, dann werde ich das noch etwas beobachten und das eingerichtete für 05:03 deaktivieren.

hi.
reset all your rules to default!

It is unsure what device is having problems with DNS resolution.
The OPNSense itself? Show the output of the Interfaces -> Diagnostics part.

Or your local devices having problems?
Then check their configuration. Which dns do they use? Do you have DHCP enabled? Which dns does it provide?

On your devices use ping, nslookup (Win) or dig, host on Linux or Mac.
What does these tools say? Can you ping the IP of OPNSense?

/KNEBB

Stimmt, ich habe zwei davon. Aber jede erstellt um 01:09 das zweite , nicht programmierte, Backup.  :-[

Moin,

ich habe mir auf meinen OPNSense Boxen ein regelmäßiges Backup auf Nextcloud eingerichtet. Das funktioniert auch wunderbar.
Siehe Anhang: Eingestellt auf 05:03 Uhr täglich. Klappt auch, ich sehe die xml-Dateien im entsprechenden Nextcloud-Account. Allerdings sehe ich da noch ein weiteres Backup. Täglich um 01:09 Uhr.

Jetzt frage ich mich, wo das herkommt? Im Cron der UI ist nichts weiter eingeerichtet, auf Anhieb konnte ich auch via Konsole (/etc/crontab) nichts dieser Art feststellen...

Wo kommt das her?

Tipps?

Danke!

/KNEBB

Moin,

ich muss das nochmal ausgraben. Das funktionierte mit einem Interface recht gut.
Ich hatte die ganze Zeit an der einen Kiste das WLAN an, es gab eine IP und im Unbound auch einen dazu passenden DNS Namen.
Nun habe ich aber das Ethernet-Interface aktiviert und das WLAN deaktiviert.
Das WLAN Interface hatte die .153 bekommen, das Ethernet bekam jetzt die .154. Nur der Namen zeigt weiterhin auf die .153. Seit Tagen.
Es gibt keinen Lease mehr für die .153, der Unbound sagt dennoch weiterhin, dass der DNS NAme auf der 153 liegt.

[Update] Habe den Unbound Dienst jetzt einmal gestoppt und neu gestartet, jetzt zeigt er auf das Ethernet Interface.

Das ist alles irgendwie nicht so richtig toll :\

Grüße

/KNEBB